cvs commit: src/sys/kern sched_4bsd.c

Scott Long scottl at
Mon May 1 19:36:26 UTC 2006

Alfred Perlstein wrote:
> * Scott Long <scottl at> [060427 10:00] wrote:
>>Well, sysctl's are a second class API.  The ease by they can be changed, 
>>as well as the completely uncontrolled nature that they are developed 
>>in, means that we really start to hamstring ourselves if we declare them
>>as a first class API.  What we should do instead is define a subset of
>>the sysctl tree that is stable and guaranteed to exist, and declare that
>>the rest are transient and therefore not part of the API.  Doing this by
>>popular vote is impractical, what we need is someone to sit down and 
>>audit what is there now and make appropriate recommendations.  sysctls 
>>that are used by libkvm are a good candidate, for example, but random
>>driver sysctls might not be.
> 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


More information about the cvs-src mailing list