cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf f

[Constantine A. Murenin]

On 16/10/2007 18:09, John Baldwin wrote:

> On Tuesday 16 October 2007 05:46:18 pm Constantine A. Murenin wrote:
> 
>>On 16/10/2007, John Baldwin <jhb at freebsd.org> wrote:
>>
>>>On Tuesday 16 October 2007 12:33:11 pm Alexander Leidinger wrote:
>>>
>>>>Constantine asked for review several times on -current. He got some
>>>>reviews several times for commits to perforce. He incorporated
>>>>suggestions from those reviews, or explained why it is like it is and
>>>>why he can not switch (with no replies with suggestions how to solve
>>>>the problems he sees with the suggestions). Now you come and ask why
>>>>nobody pointed out some flaws before (without telling us which
>>>>technical flaws you talk about).
>>>
>>>At least from my point of view this is not quite accurate as pretty much 
> 
> all
> 
>>>my feedback to the p4 commits was ignored with basically "Well, I don't 
> 
> like
> 
>>>doing it that way".  Specifically, with regards to creating dynamic sysctl
>>>trees, Constantine feels that sysctl_add_oid(9) is a hack rather than
>>>recognizing that this is a feature of FreeBSD's sysctl system despite
>>>repeated e-mails on the subject.
>>
>>Dear John,
>>
>>I have specifically addressed this concern of yours just several weeks ago.
>>
>>Please see the following message, which you've never replied to:
>>
>>http://lists.freebsd.org/pipermail/p4-projects/2007-September/021121.html
>>
>>I've used the documented parts of the FreeBSD's sysctl interface to
>>preserve 100% userland compatibility with OpenBSD.
> 
> 
> FreeBSD already provides an interface for creating dynamic sysctl trees that 
> is simpler than having to simulate a pseudo-tree via the .oid_handler 
> routine.  In some cases (such as kern.proc) FreeBSD still uses a function 
> handler rather than giving each process its own sysctl node.  However, in 
> other cases (generally more recent ones, and ones not as large/performance 
> impacting) such as dev.* or the recent proposal to give ifnet's their own 
> nodes under 'net.if' or the like, sysctl_add_oid(9) is used.

Which one is simpler is questionable.  Take one more look at the number 
of different macros that are available in the sysctl(9) and friends, and 
then compare with four functions of the sensors framework:

* sensor_attach(9) to attach a sensor to a sensordev tree
* sensordev_install(9) to register the sensordev tree with sysctl(9)
and the same with the "de" prefix

sensordev_install(9) acts similarly to the sysctl(9) ctx concept, but is 
geared towards the sensors approach

If you want to make sure you don't attract any new contributors, then 
certainly the bunch of the sysctl(9) macros are simpler.  ;)


> As to the process of walking sysctl trees being undocumented, it is simply 
> missing a wrapper routine ala sysctlbyname(3) and a manpage.  You could 
> easily provide one and thus provide a facility for enumerating many different 
> things than having several one-off oid_handler routines to enumerate 
> subtrees.  However, it is not some "backdoor" hack interface anymore than 
> sysctlbyname(3) is.  They are both equally hackish or non-hackish (depending 
> on your point of view).

This interface is about having a special tree for the hardware sensors, 
with special rules regarding the namespace.  What you suggest is that I 
try to abandon this, but then why do you need this framework to start with?

Cheers,
Constantine.