Le Wed, 2 Jul 2003 15:51:26 -0600
Joel Baker a ecrit :
> So, as part of the ongoing project, I'm looking at creating local
> patches that enable the vendor.<vendor>.* sysctl hierarchy. This does
> leave a question, however, as to what the best way to work with this is;
> sys/sysctl.h only defines 'vendor', and does not give any hint as to
> where the proper place for vendor-tree values might be stored, or where
> the support code for them belongs.

It doesn't belong anywhere, there is no support for it. The switch
statement in sys/kern/kern_sysctl.c:sys___sysctl returns EOPNOTSUPP for
CTL_VENDOR.

> Granted, I can certainly come up with a place (sys/vendor.h comes to
> mind, at least for the includes), but I was wondering if anyone could
> offer advice on what the *correct* place would be.
> 
> It also appears that the only sane value for #define VENDOR_<foo> would
> be '1' (rather than, say, an IANA enterprise OID), since it appears to
> be linked to a static table definition. Is this correct?

While working on the NVidia kernel patch, I discovered how painful it is
to add a sysctl hierarchy in NetBSD.

Each OID must have its own function to cycle through leaves or subtrees,
which makes it unpractical to have a complex tree of values.

Besides, the sysctl binary must be compiled for a given kernel and cannot
discover itself the names and numbers of sysctl variables.

Basically, our sysctl subsystem is outdated and mostly unextendable.

I had some ideas to make things better, while not going to the extreme
opposite as did FreeBSD, because their subsystem is almost as unbearable
as NetBSD.

The first one was, instead of only declaring CTL_XXX and XXX_VALUE defines
and write a function for every single subtree, to declare full structs
that reference each other in a way that makes it possible for a single
function to handle a whole subtree, with some quirks for some values that
need special management.

I started coding something, but the kern subtree has a lot of variables
that need special treatment and then I lost my code in an unfortunate
attempt to get a fresh kernel source tree.

That way it was (a bit) easier to add sysctl entries, but the sysctl
binary still needed to be built for a given version of the kernel.

The other idea, which I still haven't explored yet is to extend the first
one by providing a way for the sysctl binary to list the available names
of a hierarchy. By reserving (or allocating) space for the vendor subtree
or any other OID, it would be then possible for LKMs or kernel extensions
to easily register some new OIDs.

I don't know what ideas or comments other people might have, but if anyone
thinks it's worth the coding, I'd be more than happy to start coding.

At least I think *something* should be done.

-- 
Quentin Garnier - cube@cubidou.net
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.