--DBIVS5p969aUjpLe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 09, 2004 at 04:08:09PM -0400, Matthew Orgass wrote:
> On 2004-04-09 wrstuden@NetBSD.org wrote:
>=20
> > What you propose means going back to having the info in two places, and
> > revisiting all of the issues we had before.
>=20
>   You do not need to compile the info into sysctl to have sysctl report
> it.  Provide a simple text file that looks something like this:
> foo.bar:
> Short description (one line)
> Long description
>=20
> foo.stuff.*:
> Short/long description of what nodes under foo.stuff mean
>=20
> foo.stuff.*.a:
> Description of the a node for each node under foo.suff
>=20
>   Install this file in a directory in SYSCTLDOC or such and sysctl can
> load the files and use them to describe existing nodes.  You can even
> write a simple script to generate the equivalent section of the man page.
> Something is seriously wrong if you can't tell what a sysctl node means
> with basic regular expressions before it is actually created.

The problem is that we don't really know where something's going to be=20
until it's there. Thus pre-made docs don't work very well.

> > > >i'd like to point out, again, that this is an option.
> > >
> > > As was already pointed out, "this is an option" is not an interesting
> > > point. It is by essence something that users will become very aware o=
f,
> > > and it is thus not a feature that can just come and go depending on t=
he
> > > available amount of memory of the machine and the mood or habits of t=
he
> > > person compiling the kernels for it.
> >
> > Oh, come on! :-) If users become aware of this and they decide they want
> > it, that means they feel it is more important than the X k of memory it
> > costs. I'm accepting Andrew's analysis that as we add more descriptions=
 we
> > may grow from the ~5k noted so far.
>=20
>   "If you want sysctl descriptions, include option X or grep the source."
>=20
>   5k and growing is a high cost for mindless repetition like the example
> below.  Actual documentation would take more space, and should be
> available.  I think the idea of having sysctl able to document the nodes
> is a good idea, but it should be actual documentation and it should be in
> userland.

I think that example was one of the more mindless ones. I think there are=
=20
a number of ones that aren't as clear. Like kern.tkstat.rawcc or=20
kern.memlock_range or net.inet.tcp.cwm or net.inet6.ip6.keepfaith. They=20
are ones I wasn't immediately clear on. :-)

> > > Another thing I pointed out is that if we do this with sysctl, why not
> > > do it with event counters, or with filesystems (there aren't that many
> > > after all), or with system calls? I must say that I much more often
> > > need to know what a system call does than a sysctl variable. And they
> > > can also come and go through lkms.
> >
> > Actually, we kinda have done it with file systems. Way back when, you
> > picked a file system for mounting by number. Now you pick it by name.
>=20
>   Sysctl nodes already have names.  Names as identifiers make sense
> because it is much easier to generate a unique name in isolation than it
> is to generate a unique small integer, and you get a small bit of self
> documentation as well or at least a memory jog.  Anything more should be
> in userland.

Well, we disagree. I'll agree we don't want much more, but the little bit=
=20
we're talking about seems fine to me.

Take care,

Bill

--DBIVS5p969aUjpLe
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAdzgOWz+3JHUci9cRAtNAAJ9IFSa3HJ31OQIPvBt0EipBqn0RFwCePUS5
GVktFFVpLlxY0tgXnfqPpSk=
=kGAq
-----END PGP SIGNATURE-----

--DBIVS5p969aUjpLe--