Configure.help is complete
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help.
This does not, of course, mean the job of maintaining Configure.help is done; symbols will be added and dropped in the future (there are a handful of new ones in ac5, all now documented), and some existing entries could stand to be rewritten and expanded. But we have passed a milestone -- maintainance will now be a matter of keeping the boat bailed rather than trying to ignore a hole in the side.
Thanks to all the contributors who helped put together the over 550 entries necessary to catch up, too many to name here. The result is available at:
http://www.tuxedo.org/~esr/cml2/Configure.help.gz
Though carried on the CML2 project page, it can be used with CML1 and is current with respect to both Linus's tree and Alan's.
I now have two requests of Linus and Alan:
1. Please pick up this work now. It is a really substantial improvement on what you have in your trees, incorporating it cannot break anything, and you'll help prevent unnecessary hassles due to clashing patches in the future.
2. Please make a policy of rejecting patches that add new configuration symbols without also adding an explanatory Configure.help entry -- and please *announce* that you will do so. We can raise our standards now, and for the sake of having a well-documentated kernel and configuration system I submit that we ought to.
Signature · 5 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc
Quoted 5 lines · Eric S. Raymond
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help.
Would it be great to have a similar documentation for those hundreds of "files" under /proc ?. Something like:
/proc/sys/dev/raid/speed_limit_min
Subsystem: RAID
Module: md.o
Configuration Option: Multi-device support (RAID and LVM) -> Multiple devices driver support (RAID and LVM) -> RAID support
Type: positive integer ¿32-bit? long
Units: kilobytes per second
Related ioctls: /proc/sys/dev/raid/speed_limit_max
Short description: minumun guaranteed array reconstruction speed (in KB/s).
Description: minimun guaranteed array reconstruction speed for RAID-0, RAID-5 and the ones derived from them. When the array is reconstructing, this parameter sets the minimun reconstruction speed of the array, borrowing I/O time from applications if needed. Don't set this parameter too high or your system will be very little responsive when the array is reconstructing (give applications I/O some room :).
Is this something reasonable to ?.
Regards.
--
José Luis Domingo López
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)
jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk
José Luis Domingo López <[email protected]>:
Quoted 2 lines
Would it be great to have a similar documentation for those hundreds of "files" under /proc ?.
Yes, this would be wonderful. Are you volunteering to write it?
Signature · 7 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787
Quoted 5 lines
José Luis Domingo López <[email protected]>:
Quoted 2 lines
Would it be great to have a similar documentation for those hundreds of "files" under /proc ?.
Yes, this would be wonderful. Are you volunteering to write it?
Some of it is documented
Quoted 6 lines · Eric S. Raymond
José Luis Domingo López <[email protected]>:
Quoted 2 lines
Would it be great to have a similar documentation for those hundreds of "files" under /proc ?.
Yes, this would be wonderful. Are you volunteering to write it?
I'm not skilled enough to write even simple C or PERL programs, but maybe I could try improving linux kernel documentation. Not sure about the procedure to take nor the available time I'll have. But I'm willing to help where I can.
Would be nice to know whether there is some sense in documenting the whole /proc, just the part of ot that will stay in 2.5.x or continue with what we have rught now.
I'll check the mentioned program to see if there is the information I need. Stay tuned :)
Regards.
--
José Luis Domingo López
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)
jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk
Quoted 11 lines · José Luis Domingo López
Quoted 5 lines · Eric S. Raymond
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help.
Would it be great to have a similar documentation for those hundreds of "files" under /proc ?. Something like:
<snip>
Powertweak has descriptions for most of the usable /proc entries, in XML format but the descriptions are easily extractable. Maybe it's a good idea to make the powertweak set complete instead / share the set with the kernel docs.
Greetings,
Arjan van de Ven
Quoted 10 lines · Arjan van de Ven
Quoted 9 lines · JosИ Luis Domingo LСpez
Quoted 5 lines · Eric S. Raymond
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help.
Quoted 8 lines
Quoted 2 lines
Would it be great to have a similar documentation for those hundreds of "files" under /proc ?. Something like:
<snip>
Powertweak has descriptions for most of the usable /proc entries, in XML format but the descriptions are easily extractable. Maybe it's a good idea to make the powertweak set complete instead / share the set with the kernel docs.
We should start removing the crap from procfs in 2.5. Documenting shit is a good step, but taking it out would be better.
Alexander Viro wrote:
...snip...
Quoted 4 lines
We should start removing the crap from procfs in 2.5. Documenting shit is a good step, but taking it out would be better.
Not to open a what may be can of worms but ...
What's wrong with procfs?
It allows a general interface to the kernel that does not require new syscalls/ioctls and can be accessed from user space without specifically compiled programs. You can use shell scripts, java, command line etc.
Cheers,
Phil
------------------------------------------------------
Philip R. Auld, Ph.D. Technical Staff
Egenera Corp. [email protected]
165 Forest St, Marlboro, MA 01752 (508)786-9444
Quoted 5 lines · Phil Auld
Alexander Viro wrote:
...snip...
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
We should start removing the crap from procfs in 2.5. Documenting shit is a good step, but taking it out would be better.
Not to open a what may be can of worms but ...
What's wrong with procfs?
Imho, a procfs should be for process-information, nothing else. The procfs in its current form, while useful, is something horrible that should be taken out on the backyard and shot using slugs.
Ehrmmm. No, but seriously, the non-process stuff should be separate from the procfs. Maybe call it kernfs or whatever.
Quoted 3 lines
It allows a general interface to the kernel that does not require new syscalls/ioctls and can be accessed from user space without specifically compiled programs. You can use shell scripts, java, command line etc.
Yes, and it's also totally non standardised.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </
Quoted 8 lines · David Weinehall
Quoted 3 lines
Not to open a what may be can of worms but ...
What's wrong with procfs?
Imho, a procfs should be for process-information, nothing else. The procfs in its current form, while useful, is something horrible that should be taken out on the backyard and shot using slugs.
Quoted 8 lines
Ehrmmm. No, but seriously, the non-process stuff should be separate from the procfs. Maybe call it kernfs or whatever.
Quoted 3 lines
It allows a general interface to the kernel that does not require new syscalls/ioctls and can be accessed from user space without specifically compiled programs. You can use shell scripts, java, command line etc.
Yes, and it's also totally non standardised.
It clearly fills a need, though, and has the distinct side benefit of cutting down on the proliferation of ioctls. Sure, it's non-standard and a mess. But it's semi-documented, easy to use, and v. general. What's the preferred alternative, to state the first question another way? For any single small project/driver, creating a new fs simply isn't going to happen.
Signature · 1 line
/Jonathan Lundell.
Quoted 4 lines · Jonathan Lundell
Quoted 4 lines
Quoted 3 lines
It allows a general interface to the kernel that does not require new syscalls/ioctls and can be accessed from user space without specifically compiled programs. You can use shell scripts, java, command line etc.
Quoted 10 lines
Quoted 1 line
Yes, and it's also totally non standardised.
It clearly fills a need, though, and has the distinct side benefit of cutting down on the proliferation of ioctls. Sure, it's non-standard and a mess. But it's semi-documented, easy to use, and v. general. What's the preferred alternative, to state the first question another way? For any single small project/driver, creating a new fs simply isn't going to happen.
Signature · 1 line
/Jonathan Lundell.
If I understand Al Viro correctly we'll get per driver filesystems in 2.5 (based on ramfs) which you can union-mount on /proc (possibly using autofs) to get the current /proc tree.
Happy Hacking.
Signature · 1 line
Linux 2.4.5-ac6 #1 Fri Jun 1 17:12:42 CEST 2001
Quoted 2 lines · On Thu, 31 May 2001 19:24:54 +0200 Eric S. Raymond <[email protected]> wrote:
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the
Congratulations!
Could you please change Portugese to Portuguese in one place?
Regards,
Nerijus