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 <[EMAIL PROTECTED]> 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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
