Subject: Re: CVS commit: src/sys/kern
To: Andrew Brown <email@example.com>
From: Aymeric Vincent <firstname.lastname@example.org>
Date: 04/09/2004 18:19:24
Andrew Brown wrote:
> 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
> 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?
Maybe comparing suffixes of the paths is sufficient to take care of the
fact that some variables may be added at different places in the
Besides this, the documentation can be made available in some form of
database at the very moment the lkm is loaded, and as was suggested
this can even be done automatically by using a new section of the
> 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 of,
and it is thus not a feature that can just come and go depending on the
available amount of memory of the machine and the mood or habits of the
person compiling the kernels for it.
> /* SYSCTL_DESCR: kern.securelevel: System security level */
Why not? I would even not mind at all to see semantically equivalent
text appended to a man page or any other form of database, instead of
right inside the kernel source.
Another point is that most variables are already very often
self-documenting and unless you are going to add big descriptions the
user will not win much. The example you give is particularly
well-chosen in that respect.
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.
The kernel is not the right place for documentation, and maybe giving
reasons for that drowns this simple statement.
I'm sorry that I have to go; I hope I made my points clear enough.