> > > FWIW, I back Pouls opinion. What's so special about sysctls that
> > > makes them even need the description field in the first place - let
> > > alone actually compiling it in ?
> >
> > What's special about them is that they are the presentation form of
> > kernel tunable values. They're fronted directly to the user.
>
> I don't see what the difference is between the use of sysctl and the
> use of say kbdcontrol or mixer.
That's fairly obvious.
> If I want to find out how to use the
> stuff that mixer changes, I ``man mixer''. Sysctl tweaks the way the
> kernel behaves. If I want information, I ``man sysctl''.
That's because what mixer and vidcontrol do is directly related to the
programs; they derive no metainformation from the kernel. OTOH, sysctl
is just a framework for manipulating data using metadata derived from
the kernel.
> The point is that the sysctl documentation should be found in the
> same place as the rest of the system documentation.
Since it's quite clear you really haven't grasped the core of the
problem, I'll present you with a simple example, and you can explain to
me how you propose to deal with it.
I have a driver for a new peripheral. It's from a vendor that doesn't
want to distribute source code, so the driver comes as a KLD module.
The driver has a number of tuning options, which are exposed via the
sysctl MIB.
Please explain how I am to find documentation for these tuning options
in the system manpages. Suggest how your approach is better than, for
example, being able to directly ascertain what it is that the tuning
options do using the same tool that I plan to use to adjust them.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message