cvs commit: src/sys/kern sched_4bsd.c

[Robert Watson]

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, 
and debug.net.inet.temporary_thingy.

Robert N M Watson