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 
>> 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?

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 
hierarchy?
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 
module object.

> 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.

Regards,
  Aymeric