Remaining undocumented Configure.help symbols

Remaining undocumented Configure.help symbols

[Eric S. Raymond]

With the help of a number of contributors, Steven Cole and I have
managed to cut the list of undocumented configuration symbols from the
previous 55 to 10.  The three *_NET_SCH_* symbols that didn't appear
in the previous listing have popped up because my cross-referencer was
fooled by some old comments in Configure.help.

Networking:

CONFIG_NET_CLS_POLICE
CONFIG_NET_CLS_TCINDEX
CONFIG_NET_SCH_INGRESS

ARM port:

CONFIG_SA1100_SHERMAN

PPC port:

CONFIG_EST8260
CONFIG_BLK_DEV_MPC8xx_IDE
CONFIG_IRQ_ALL_CPUS
CONFIG_USE_MDIO

CRIS port:

CONFIG_ETRAX_FLASH_BUSWIDTH
CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C

As before, if you know enough about any of these configuration options to
write a help entry, please send it to me.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself 
a reputation as a dangerous citizen these days is to go about 
repeating the very phrases which our founding fathers used in the 
great struggle for independence.
	-- Attributed to Charles Austin Beard (1874-1948)

Re: Remaining undocumented Configure.help symbols

[Harald Welte]

On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote:

> CONFIG_NET_CLS_TCINDEX

  If you say Y here, you will be able to classify outgoing packets 
  according to the tc_index field of the skb. You will want this 
  feature if you want to implement Differentiates Services useing
  sch_dsmark. If unsure, say Y.

  This code is also available as a module called cls_tcindex.o ( = code
  which can be inserted in and removed from the running kernel
  whenever you want). If you want to compile it as a module, say MM
  here and read Documentation/modules.txt

> CONFIG_NET_SCH_INGRESS

  If you say Y here, you will be able to police incoming bandwidth
  and drop packets when this bandwidth exceeds your desired rate.
  If unsure, say Y.

  This code is also available as a module called cls_tcindex.o ( = code
  which can be inserted in and removed from the running kernel
  whenever you want). If you want to compile it as a module, say MM
  here and read Documentation/modules.txt

> As before, if you know enough about any of these configuration options to
> write a help entry, please send it to me.

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: Remaining undocumented Configure.help symbols

[Eric S. Raymond]

Harald Welte <laforge@gnumonks.org>:
> On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote:
> 
> > CONFIG_NET_CLS_TCINDEX
> 
>   If you say Y here, you will be able to classify outgoing packets 
>   according to the tc_index field of the skb. You will want this 
>   feature if you want to implement Differentiates Services useing
>   sch_dsmark. If unsure, say Y.
> 
>   This code is also available as a module called cls_tcindex.o ( = code
>   which can be inserted in and removed from the running kernel
>   whenever you want). If you want to compile it as a module, say MM
>   here and read Documentation/modules.txt

Looks good.
 
> > CONFIG_NET_SCH_INGRESS
> 
>   If you say Y here, you will be able to police incoming bandwidth
>   and drop packets when this bandwidth exceeds your desired rate.
>   If unsure, say Y.
> 
>   This code is also available as a module called cls_tcindex.o ( = code
>   which can be inserted in and removed from the running kernel
>   whenever you want). If you want to compile it as a module, say MM
>   here and read Documentation/modules.txt

I'm going to assume that the cls_tcindex.o in the second entry is a 
cut'n'paste error and should read sch_ingress.o.

Should the CLS_POLICE entry, then, read like this?

Traffic policing (needed for in/egress)
CONFIG_NET_CLS_POLICE
   Say Y to support traffic policing (bandwidth limits).  Needed for ingress
   and egress rate limiting.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances ..
	-- IRS Strategic Plan, (May 1984)

Re: Remaining undocumented Configure.help symbols

[Jim Treadway]

On Wed, 30 May 2001, Eric S. Raymond wrote:

> Harald Welte <laforge@gnumonks.org>:
> > On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote:
> >
> > > CONFIG_NET_CLS_TCINDEX
> >
> >   If you say Y here, you will be able to classify outgoing packets
> >   according to the tc_index field of the skb. You will want this
> >   feature if you want to implement Differentiates Services useing
> >   sch_dsmark. If unsure, say Y.

Change "useing" to "using". ;)

Change "Differentiates" to "Differentiated" (at least according to
./net/sched/sch_dsmark.c).

> >   This code is also available as a module called cls_tcindex.o ( = code
> >   which can be inserted in and removed from the running kernel
> >   whenever you want). If you want to compile it as a module, say MM

Shouldn't this be "say M" (and not "say MM")?

> >   here and read Documentation/modules.txt
>
> Looks good.
>
> > > CONFIG_NET_SCH_INGRESS
> >
> >   If you say Y here, you will be able to police incoming bandwidth
> >   and drop packets when this bandwidth exceeds your desired rate.
> >   If unsure, say Y.
> >
> >   This code is also available as a module called cls_tcindex.o ( = code
> >   which can be inserted in and removed from the running kernel
> >   whenever you want). If you want to compile it as a module, say MM

Shouldn't this be "say M"?

> >   here and read Documentation/modules.txt

Re: Remaining undocumented Configure.help symbols

[Jim Freeman]

The verbiage in these entries seems 'make config' / text-interaction
-centric.  Granted, that's likely the context most kernel builders will
use, but it would seem fair to at least consider a broader audience
who may be using more gui-ish tools wrapped around extant content.

For instance, a click-a-node-to-choose-an-option-gui or click-a-box-to
-choose-an-option-set-and-optionally-drill-down-to-details-gui would
probably (when asked) present the Configure.help entry for a given
option, but the  "If you say Y here ... If unsure say Y"  wording would
not be apropos in such a presentation context.  

Something akin to "Select this option to enable classification of egress
traffic based on ..." might serve differing presentation modes more
adequately.

...jfree
========
On Wed, May 30, 2001 at 06:20:12PM -0400, Eric S. Raymond wrote:
> Harald Welte <laforge@gnumonks.org>:
> > On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote:
> > 
> > > CONFIG_NET_CLS_TCINDEX
> > 
> >   If you say Y here, you will be able to classify outgoing packets 
> >   according to the tc_index field of the skb. You will want this 
> >   feature if you want to implement Differentiates Services useing
> >   sch_dsmark. If unsure, say Y.
> > 
> >   This code is also available as a module called cls_tcindex.o ( = code
> >   which can be inserted in and removed from the running kernel
> >   whenever you want). If you want to compile it as a module, say MM
> >   here and read Documentation/modules.txt
> 
> Looks good.
>  
> > > CONFIG_NET_SCH_INGRESS
> > 
> >   If you say Y here, you will be able to police incoming bandwidth
> >   and drop packets when this bandwidth exceeds your desired rate.
> >   If unsure, say Y.
> > 
> >   This code is also available as a module called cls_tcindex.o ( = code
> >   which can be inserted in and removed from the running kernel
> >   whenever you want). If you want to compile it as a module, say MM
> >   here and read Documentation/modules.txt
> 
> I'm going to assume that the cls_tcindex.o in the second entry is a 
> cut'n'paste error and should read sch_ingress.o.
> 
> Should the CLS_POLICE entry, then, read like this?
> 
> Traffic policing (needed for in/egress)
> CONFIG_NET_CLS_POLICE
>    Say Y to support traffic policing (bandwidth limits).  Needed for ingress
>    and egress rate limiting.

Re: [kbuild-devel] Re: Remaining undocumented Configure.help symbols

[Eric S. Raymond]

Jim Freeman <jfree@sovereign.org>:
> The verbiage in these entries seems 'make config' / text-interaction
> -centric.  Granted, that's likely the context most kernel builders will
> use, but it would seem fair to at least consider a broader audience
> who may be using more gui-ish tools wrapped around extant content.

This is a general problem with almost all the existing entries, and
will have to await a future editing pass for solution.  For now I think
it's more important to have consistent cues that users can recognize,
even if they're not literally appropriate.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

It is the assumption of this book that a work of art is a gift, not a
commodity.  Or, to state the modern case with more precision, that works of
art exist simultaneously in two "economies," a market economy and a gift
economy.  Only one of these is essential, however: a work of art can survive
without the market, but where there is no gift there is no art.
	-- Lewis Hyde, The Gift: Imagination and the Erotic Life of Property

Re: [kbuild-devel] Re: Remaining undocumented Configure.help symbols

[Jim Freeman]

On Thu, May 31, 2001 at 07:10:55PM -0400, Eric S. Raymond wrote:
> Jim Freeman <jfree@sovereign.org>:
> > The verbiage in these entries seems 'make config' / text-interaction
> > -centric.  Granted, that's likely the context most kernel builders will
> > use, but it would seem fair to at least consider a broader audience
> > who may be using more gui-ish tools wrapped around extant content.
> 
> This is a general problem with almost all the existing entries, and
> will have to await a future editing pass for solution.  For now I think
> it's more important to have consistent cues that users can recognize,
> even if they're not literally appropriate.

Agreed - in the meantime, just wanted to have the issue acknowledged
and put on the roadmap.