cvs commit: src/sys/kern sched_4bsd.c

[Brooks Davis]

On Thu, Apr 27, 2006 at 10:58:53AM -0600, Scott Long wrote:
> Brooks Davis wrote:
> >On Thu, Apr 27, 2006 at 12:20:26PM +0200, Pawel Jakub Dawidek wrote:
> >
> >>On Wed, Apr 26, 2006 at 07:42:39PM +0000, John-Mark Gurney wrote:
> >>+> jmg         2006-04-26 19:42:38 UTC
> >>+> 
> >>+>   FreeBSD src repository
> >>+> 
> >>+>   Modified files:
> >>+>     sys/kern             sched_4bsd.c 
> >>+>   Log:
> >>+>   move remaining sysctl into the kern.sched tree...
> >>[...]
> >>+> -SYSCTL_INT(_kern, OID_AUTO, ccpu, CTLFLAG_RD, &ccpu, 0, "");
> >>+> +SYSCTL_INT(_kern_sched, OID_AUTO, ccpu, CTLFLAG_RD, &ccpu, 0, "");
> >>[...]
> >>
> >>Too fast.
> >>
> >># grep -r kern.ccpu /usr/src/
> >
> >
> >We should retain the old location as well under COMPAT_FREEBSD[456].  It
> >doesn't cost anything and we should treat the sysctl tree like any other
> >API to the extent possible.
> 
> 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 agree we don't want to be too restrictive here, but for cases like
this where there's effectively no cost I think we should at least try
to retain compatibility under #ifs.  If we break that compatibility at
some later date due to actually changing the data or because something
else needs to use that location in the tree, that's probably OK.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060427/d71f53f1/attachment.pgp