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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
