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

On Fri, Apr 09, 2004 at 06:19:24PM +0200, Aymeric Vincent wrote:

[snip, out of order]
> The kernel is not the right place for documentation, and maybe giving=20
> reasons for that drowns this simple statement.

Yes & no. I agree that the threshold for what should be in the kernel is=20
higher than what can sit around in userland. But that doesn't mean we=20
can't/shouldn't have informational or "documentation" in the kernel, I=20
think it means we should have a good reason for what we have.

If we have a good reason for the sysctl docs in the kernel, I think they=20
should stay there.

> Andrew Brown wrote:
>=20
> >On Fri, Apr 09, 2004 at 01:51:39PM +0200, Aymeric Vincent wrote:
> >>
> >>This feature does not need to be in the kernel: it can be in=20
> >>sysctl(8).
> >
> >not really.  how is sysctl(8) to learn what new things are when they
> >randomly appear?  and if something disappears later, only to reappear
> >somewhere else (ie, at a different mib entry), how is sysctl(8) to
> >know how to apply the description?
>=20
> Maybe comparing suffixes of the paths is sufficient to take care of the=
=20
> fact that some variables may be added at different places in the=20
> hierarchy?
> Besides this, the documentation can be made available in some form of=20
> database at the very moment the lkm is loaded, and as was suggested=20
> this can even be done automatically by using a new section of the=20
> module object.

Well, I have a few concerns with that. The general theme is that what you=
=20
propose goes against the main spirit of Andrew's recent changes to sysctl.
In the past, sysctl has had half its MIB in the kernel, and half in=20
userland. That lead to a lot of inflexability and errors. The kernel and=20
all of userland (sysctl(8) and all sysctl-using programs) had to be in=20
sync. By moving the name->OID conversion into the kernel, we centralize=20
control of the hierarchy. Things won't get out of sync.

What you propose means going back to having the info in two places, and=20
revisiting all of the issues we had before.

1) We still have to load the text into the live kernel, as we don't always
have the booted-kernel available to userland after boot. So we don't=20
really save any kvm. Maybe we could play tricks with making the area=20
pagable, but that's it.

2) suffix comparison seems like a form of guessing. Among other things, it=
=20
means we really want the tail components to be unique (so we don't get=20
false matches). That in turn defeats an advantage of a hierarchical=20
structure; that you only have to think about name collisions in a smaller=
=20
space.

I mean it could be we can make suffix comparison work, but we'll have to=20
work harder for it. And as uses for sysctl grow, we'll have more worries.

3) The parallel-database idea (db that parallels kernel actuality) would=20
need work, in my mind. We may go with it eventually, but a) we'll need=20
some userland daemon (I think), and b) we'll need some synchronization=20
ability. It's not clear to me that such an implementation will be less=20
code than what we have now.

> >i'd like to point out, again, that this is an option.
>=20
> As was already pointed out, "this is an option" is not an interesting=20
> point. It is by essence something that users will become very aware of,=
=20
> and it is thus not a feature that can just come and go depending on the=
=20
> available amount of memory of the machine and the mood or habits of the=
=20
> person compiling the kernels for it.

Oh, come on! :-) If users become aware of this and they decide they want=20
it, that means they feel it is more important than the X k of memory it=20
costs. I'm accepting Andrew's analysis that as we add more descriptions we=
=20
may grow from the ~5k noted so far.

> >        /* SYSCTL_DESCR: kern.securelevel: System security level */
>=20
> Why not? I would even not mind at all to see semantically equivalent=20
> text appended to a man page or any other form of database, instead of=20
> right inside the kernel source.
>=20
> Another point is that most variables are already very often=20
> self-documenting and unless you are going to add big descriptions the=20
> user will not win much. The example you give is particularly=20
> well-chosen in that respect.
>=20
> Another thing I pointed out is that if we do this with sysctl, why not=20
> do it with event counters, or with filesystems (there aren't that many=20
> after all), or with system calls? I must say that I much more often=20
> need to know what a system call does than a sysctl variable. And they=20
> can also come and go through lkms.

Actually, we kinda have done it with file systems. Way back when, you=20
picked a file system for mounting by number. Now you pick it by name.

Your question about syscalls is, I think, an open question for ktrace. I=20
think a way for ktrace to ask what a syscall is is important. But that's a=
=20
different thread. :-)

Take care,

Bill

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

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

iD8DBQFAdvAxWz+3JHUci9cRAnhcAKCICLK3VbuNGVkjzViFYTME3QK4sQCfctQo
mTZvaz4b4OPp8s/vZQ6D7rA=
=f4JI
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--