Configure.help is complete

Configure.help is complete

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

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

Re: Configure.help is complete

[Alan Cox]

> José Luis Domingo López <jldomingo@crosswinds.net>:
> > 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

Re: Configure.help is complete

[Eric S. Raymond]

José Luis Domingo López <jldomingo@crosswinds.net>:
> 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?
-- 
		<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 

Re: Configure.help is complete

[Arjan van de Ven]

José Luis Domingo López wrote:
> 
> On Thursday, 31 May 2001, at 13:24:54 -0400,
> Eric S. Raymond 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
> > 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

Re: Configure.help is complete

[Alexander Viro]

On Thu, 31 May 2001, Arjan van de Ven wrote:

> JosИ Luis Domingo LСpez wrote:
> > 
> > On Thursday, 31 May 2001, at 13:24:54 -0400,
> > Eric S. Raymond 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
> > > 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.

We should start removing the crap from procfs in 2.5. Documenting shit is
a good step, but taking it out would be better.

Re: Configure.help is complete

[BH]

Great work, its nice to see none, or fewer No help availables in the kernel 
configuration.
Some quick glances:

Linux Kernel v2.4.5-ac5 Configuration
CML1

Bottom of IDE, ATA and ATAPI Block devices;

< > Support Promise software RAID (NEW)   -> Help
There is no help available for this kernel option.

The Help for '[ ]   IGNORE word93 Validation BITS' isn't much help either, 
although I safely say N and move on.

Between SCSI and IEEE 1394;
Fusion MPT device support  --->     doesn't lead anywhere.

Re: Configure.help is complete

[José Luis Domingo López]

On Thursday, 31 May 2001, at 13:24:54 -0400,
Eric S. Raymond 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
> 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

Re: Configure.help is complete

[Arjan van de Ven]

BH wrote:
> 
> Great work, its nice to see none, or fewer No help availables in the kernel
> configuration.
> Some quick glances:
> 
> Linux Kernel v2.4.5-ac5 Configuration
> CML1
> 
> Bottom of IDE, ATA and ATAPI Block devices;
> 
> < > Support Promise software RAID (NEW)   -> Help
> There is no help available for this kernel option.

How about
"Say "Y" or "M" if you have a Promise Fasttrak (tm) Raid controller
and want linux to use the softwarraid feature of this card.
This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names.

If you have a Promise Fasttrak(tm) card but do not use the BIOS provided
raid feature, say "N".

Re: Configure.help is complete

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> > Linux Kernel v2.4.5-ac5 Configuration
> > CML1
> > 
> > Bottom of IDE, ATA and ATAPI Block devices;
> > 
> > < > Support Promise software RAID (NEW)   -> Help
> > There is no help available for this kernel option.
> 
> How about
> "Say "Y" or "M" if you have a Promise Fasttrak (tm) Raid controller
> and want linux to use the softwarraid feature of this card.
> This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names.
> 
> If you have a Promise Fasttrak(tm) card but do not use the BIOS provided
> raid feature, say "N".

Um, tell me what the symbol name and prompt for this is, please?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

[President Clinton] boasts about 186,000 people denied firearms under
the Brady Law rules.  The Brady Law has been in force for three years.  In
that time, they have prosecuted seven people and put three of them in
prison.  You know, the President has entertained more felons than that at
fundraising coffees in the White House, for Pete's sake."
	-- Charlton Heston, FOX News Sunday, 18 May 1997

Re: Configure.help is complete

[Alan Cox]

> Between SCSI and IEEE 1394;
> Fusion MPT device support  --->     doesn't lead anywhere.

It does for me.. fusion requires scsi and experimental

Re: Configure.help is complete

[Nerijus Baliunas]

On Thu, 31 May 2001 19:24:54 +0200 Eric S. Raymond <esr@thyrsus.com> 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

Re: Configure.help is complete

[José Luis Domingo López]

On Thursday, 31 May 2001, at 14:23:21 -0400,
Eric S. Raymond wrote:

> José Luis Domingo López <jldomingo@crosswinds.net>:
> > 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

Re: Configure.help is complete

[Phil Auld]

Alexander Viro wrote:

...snip...

> 
> 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.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: Configure.help is complete

[David Weinehall]

On Fri, Jun 01, 2001 at 08:43:58AM -0400, Phil Auld wrote:
> Alexander Viro wrote:
> 
> ...snip...
> 
> > 
> > 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.

> 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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Configure.help is complete

[Jonathan Lundell]

At 2:59 PM +0200 2001-06-01, David Weinehall wrote:
>  > 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.
>
>>  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.
-- 
/Jonathan Lundell.

Re: Configure.help is complete

[Remi Turk]

On Fri, Jun 01, 2001 at 08:45:17AM -0700, Jonathan Lundell wrote:
> >>  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.
> -- 
> /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.

-- 
Linux 2.4.5-ac6 #1 Fri Jun 1 17:12:42 CEST 2001