cvs commit: src/sys/kern sched_4bsd.c
rwatson at FreeBSD.org
Tue May 2 11:10:36 UTC 2006
On Mon, 1 May 2006, Scott Long wrote:
>> I think that sysctls should rarely be changed, it really hurts application
>> developers that will try to build low level system management software.
>> Even device drivers should be careful, it would suck for a vendor's binary
>> code to break for a utility that you are dependant on just because someone
>> didn't like the spelling of a sysctl.
> Right, that's why I was saying that certain parts of the tree should be
> considered part of the API, just like syscalls, and treated with care, and
> other parts of the tree should be allowed to be more flexible, and
> advertised that way. I'd hate to add a sysctl to one of my drivers that is
> only intended as a debugging knob, and have some application developer think
> that it was something that was useful for his application to use. I find
> that a lot of sysctls are added as a cheap means to make debugging
> information available at runtime; this doesn't mean that they should be
> treated as a first class API that can never again be changed or removed.
> And if the popular opinion is against this, then I challenge them to develop
> an alternate developer-friendly interface that can be used instead. Should
> FreeBSD change its stance against pseudofilesystems and use them for this
> information like Linux does?
I don't see changing the mechanism fixing the name space policy issue.
Renaming vm.foo.bar isn't really very different from remaining
/proc/vm/foo/bar, because the application is broken both ways. :-)
In my sysctl(9) man page, I've tried to identify to sysctl authors that they
need to be sensitive to name space issues, but nothing trumps common sense
(don't change things without a good reason, and if you do change things,
expect to deal with the results).
With regard to debugging information -- in the past, we've stuffed some
debugging information into debug.*. Maybe we need to actually mirror the
normal structure into debug.* for debugging things. I.e., net.inet.foo.bar,
Robert N M Watson
More information about the cvs-src