CML2 design philosophy heads-up

CML2 design philosophy heads-up

[Eric S. Raymond]

I've said before on these lists that one of the purposes of CML2's single-apex
tree design is to move the configuration dialog away from low-level platform-
specific questions towards higher-level questions about policy or intentions.

Or to put another way: away from hardware, towards capabilities.

As a concrete example, the CML2 rulesfile master for the m68k port
tree now has a section that looks like this:

# These were separate questions in CML1.  They enable on-board peripheral
# controllers in single-board computers.
derive MVME147_NET from MVME147 & NET_ETHERNET
derive MVME147_SCC from MVME147 & SERIAL
derive MVME147_SCSI from MVME147 & SCSI
derive MVME16x_NET from MVME16x & NET_ETHERNET
derive MVME16x_SCC from MVME16x & SERIAL
derive MVME16x_SCSI from MVME16x & SCSI
derive BVME6000_NET from BVME6000 & NET_ETHERNET
derive BVME6000_SCC from BVME6000 & SERIAL
derive BVME6000_SCSI from BVME6000 & SCSI

# These were separate questions in CML1
derive MAC_SCC from MAC & SERIAL
derive MAC_SCSI from MAC & SCSI
derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI

If it isn't obvious, the intent is that if you specify (say) both 
MVME147 (a machine type) and SERIAL (a capability) you automatically 
get the specific driver support under MVME147_SCC.

This is different from the CML1 approach, which generally involved
explicitly specifying each driver with mutual dependencies described 
(if at all) in Configure.help.

I've created a number of derivations of this kind recently.  I'm not
going out of my way to do this, but what I am trying to do is reduce
the number of symbols undocumented in Configure.help to zero (I've got
it down to 243 from 547 when I started).  When I can eliminate the
need for a configuration question and associated help by writing this
kind of formula, I'm doing so.

This note is a heads-up.  If others with a stake in the configuration
system (port managers, etc.) have objections to moving further in this
direction, I need to hear about it, and about what you think we should
be doing instead.
-- 
		<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: CML2 design philosophy heads-up

[Alan Cox]

> # These were separate questions in CML1
> derive MAC_SCC from MAC & SERIAL
> derive MAC_SCSI from MAC & SCSI
> derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI

Not all Mac's use the SCC if they have serial
Not all Mac's use the same SCSI controller

Alan

Re: CML2 design philosophy heads-up

[Tom Rini]

On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote:
> > # These were separate questions in CML1
> > derive MAC_SCC from MAC & SERIAL
> > derive MAC_SCSI from MAC & SCSI
> > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI
> 
> Not all Mac's use the SCC if they have serial
> Not all Mac's use the same SCSI controller

Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but
I never did get Linux up and running on the m68ks I had..

But Alan's point is a good one.  There are _lots_ of cases you can't get away
with things like this, unless you get very fine grained.  In fact, it would
be much eaiser to do this seperately from the kernel.  Ie another, 
possibly/probably _not_ inkernel config tool which asks what machine you
have, picks lots of sane defaults and setups a kernel config for you.  This
is _sort of_ what PPC does right now with the large number of 'default 
configs' (arch/ppc/configs).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: CML2 design philosophy heads-up

[Alan Cox]

> > Not all Mac's use the same SCSI controller
> 
> Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but
> I never did get Linux up and running on the m68ks I had..

68K macs use the 53C80 and 53C9x controllers

> But Alan's point is a good one.  There are _lots_ of cases you can't get away
> with things like this, unless you get very fine grained.  In fact, it would
> be much eaiser to do this seperately from the kernel.  Ie another, 

There are also a lot of config options that are implied by your setup in
an embedded enviromment but which you dont actually want because you didnt
wire them

Second guessing is not ideal. As a 'make the default config nice' trick - great

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> There are also a lot of config options that are implied by your setup in
> an embedded enviromment but which you dont actually want because you didnt
> wire them

Well, then, you don't specify the guard capability!  If your MV147 isn't 
wired for serial, then leave SERIAL off.  The point of the derivation 
is exactly to let you do that.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes
the law places the whole apparatus of judges, police, prisons and
gendarmes at the service of the plunderers, and treats the victim --
when he defends himself -- as a criminal.
	-- Frederic Bastiat, "The Law"

Re: CML2 design philosophy heads-up

[Helge Hafting]

Alan Cox wrote:

> > But Alan's point is a good one.  There are _lots_ of cases you can't get away
> > with things like this, unless you get very fine grained.  In fact, it would
> > be much eaiser to do this seperately from the kernel.  Ie another,
> 
> There are also a lot of config options that are implied by your setup in
> an embedded enviromment but which you dont actually want because you didnt
> wire them
> 
> Second guessing is not ideal. As a 'make the default config nice' trick - great

This is easy without changing CML2.  Make another config option
for auto-enabling hardware you "probably have"

Rules of the form "X86 and PARPORT implies PARPORT_PC" can then
be transformed to "X86 and PARPORT and PROBABLE_HARDWARE implies
PARPORT_PC"

Those who want a nice & easy config may then turn PROBABLE_HARDWARE on.
Those who want tricks like using only nonstandard (hi-performance?)
serial
ports on their pc and save memory on skipping drivers for the built-in
stuff can do so by turning the probable setting off.

Helge Hafting

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote:
> > > # These were separate questions in CML1
> > > derive MAC_SCC from MAC & SERIAL
> > > derive MAC_SCSI from MAC & SCSI
> > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI
> > 
> > Not all Mac's use the SCC if they have serial
> > Not all Mac's use the same SCSI controller
> 
> Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but
> I never did get Linux up and running on the m68ks I had..

Exactly.  In fact we can be more specific -- the "Macintoshes" in
question are the old-fashioned NuBus-based 68k toaster boxes, not the
more recent designs with a PCI bus.  Relevant stuff in the
Configure.help implies that MAC_SCC and MAC_SCSI enable support for
the on-board hardware built into those puppies.
 
> But Alan's point is a good one.  There are _lots_ of cases you can't get away
> with things like this, unless you get very fine grained.  In fact, it would
> be much eaiser to do this seperately from the kernel.  Ie another, 
> possibly/probably _not_ inkernel config tool which asks what machine you
> have, picks lots of sane defaults and setups a kernel config for you.  This
> is _sort of_ what PPC does right now with the large number of 'default 
> configs' (arch/ppc/configs).

You're really talking about a different issue here,  autoconfiguration
rather than static dependencies.  Giacomo Catenazzi is working on that.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Let us hope our weapons are never needed --but do not forget what 
the common people knew when they demanded the Bill of Rights: An 
armed citizenry is the first defense, the best defense, and the 
final defense against tyranny.
   If guns are outlawed, only the government will have guns. Only 
the police, the secret police, the military, the hired servants of 
our rulers.  Only the government -- and a few outlaws.  I intend to 
be among the outlaws.
        -- Edward Abbey, "Abbey's Road", 1979

Re: CML2 design philosophy heads-up

[Tom Rini]

On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote:
> Tom Rini <trini@kernel.crashing.org>:
[snip]
> Exactly.  In fact we can be more specific -- the "Macintoshes" in
> question are the old-fashioned NuBus-based 68k toaster boxes, not the
> more recent designs with a PCI bus.  Relevant stuff in the
> Configure.help implies that MAC_SCC and MAC_SCSI enable support for
> the on-board hardware built into those puppies.
>  
> > But Alan's point is a good one.  There are _lots_ of cases you can't get away
> > with things like this, unless you get very fine grained.  In fact, it would
> > be much eaiser to do this seperately from the kernel.  Ie another, 
> > possibly/probably _not_ inkernel config tool which asks what machine you
> > have, picks lots of sane defaults and setups a kernel config for you.  This
> > is _sort of_ what PPC does right now with the large number of 'default 
> > configs' (arch/ppc/configs).
> 
> You're really talking about a different issue here,  autoconfiguration
> rather than static dependencies.  Giacomo Catenazzi is working on that.

Only sort-of.  There are some cases where you can get away with that.  
Probably.  eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
always (right?)  On other arches (someone brought this up before) it could
be PC, it could be something else.  My point is there are only some cases
where you can get away with asking for serial and knowing the driver.  I've
given this some thought before, and at least on PPC, you can at best segment
off some drivers as depending on family X, but family X doesn't mean you
have part Y.  The other thing to keep in mind is I'm sure there's lots of
unintentionally correct bits.  In short, please be very careful when you
change a symbol from a question to a derive.  You're bound to piss off 
someone :)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> Only sort-of.  There are some cases where you can get away with that.  
> Probably.  eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
> always (right?)

Yes.  So the right answer there isn't to use a derivation but to say:

require X86 and PARPORT implies PARPORT_PC
unless X86==n suppress PARPORT_PC

which forces PARPORT_PC==y and makes the question invisible on X86 machines,
but leaves the question visible on all others.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The real point of audits is to instill fear, not to extract revenue;
the IRS aims at winning through intimidation and (thereby) getting
maximum voluntary compliance
	-- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980

Re: CML2 design philosophy heads-up

[David Weinehall]

On Mon, May 07, 2001 at 09:56:18PM -0400, Eric S. Raymond wrote:
> Tom Rini <trini@kernel.crashing.org>:
> > Only sort-of.  There are some cases where you can get away with
> > that.  Probably.  eg If you ask for PARPORT, on x86 that means yes
> > to PARPORT_PC, always (right?)
> 
> Yes.  So the right answer there isn't to use a derivation but to say:
> 
> require X86 and PARPORT implies PARPORT_PC
> unless X86==n suppress PARPORT_PC
> 
> which forces PARPORT_PC==y and makes the question invisible on X86
> machines, but leaves the question visible on all others.

Yes, but there are quite a lot of people who don't want
parport/serial/whatever compiled into their kernels at all,
eventhough they have an x86. Think low-memory systems or similar.


/David
  _                                                                 _
 // 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: CML2 design philosophy heads-up

[Eric S. Raymond]

David Weinehall <tao@acc.umu.se>:
> > require X86 and PARPORT implies PARPORT_PC
> > unless X86==n suppress PARPORT_PC
> > 
> > which forces PARPORT_PC==y and makes the question invisible on X86
> > machines, but leaves the question visible on all others.
> 
> Yes, but there are quite a lot of people who don't want
> parport/serial/whatever compiled into their kernels at all,
> eventhough they have an x86. Think low-memory systems or similar.

That's OK.  Neither of these constraints says PARPORT must be compiled in.
Look at the conditionals carefully.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"...The Bill of Rights is a literal and absolute document. The First
Amendment doesn't say you have a right to speak out unless the
government has a 'compelling interest' in censoring the Internet. The
Second Amendment doesn't say you have the right to keep and bear arms
until some madman plants a bomb. The Fourth Amendment doesn't say you
have the right to be secure from search and seizure unless some FBI
agent thinks you fit the profile of a terrorist. The government has no
right to interfere with any of these freedoms under any circumstances."
	-- Harry Browne, 1996 USA presidential candidate, Libertarian Party

Re: CML2 design philosophy heads-up

[Jamie Lokier]

Eric S. Raymond wrote:
> Tom Rini <trini@kernel.crashing.org>:
> > Only sort-of.  There are some cases where you can get away with that.  
> > Probably.  eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
> > always (right?)
> 
> Yes.  So the right answer there isn't to use a derivation but to say:
> 
> require X86 and PARPORT implies PARPORT_PC
> unless X86==n suppress PARPORT_PC
> 
> which forces PARPORT_PC==y and makes the question invisible on X86 machines,
> but leaves the question visible on all others.

Which is unfortunately wrong if you want the parport subsystem on x86
but won't be using the parport_pc driver with it.  I.e. you'll be using
some other driver which isn't part of the kernel tree.  Perhaps a
modified version of parport_pc, perhaps something else.

The default should be PARPORT_PC==y, but it's actually valid for some
applications to _require_ PARPORT_PC==n or PARPORT_PC==m.

-- Jamie

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jamie Lokier <lk@tantalophile.demon.co.uk>:
> Which is unfortunately wrong if you want the parport subsystem on x86
> but won't be using the parport_pc driver with it.  I.e. you'll be using
> some other driver which isn't part of the kernel tree.  Perhaps a
> modified version of parport_pc, perhaps something else.

If you're integrating drivers that aren't in the kernel tree, you can and
should patch the CML2 rulebase to compensate.  So your patch for
the modified driver should comment out the PARPORT_PC==PARPORT 
requirement.  Problem solved.

More generally, arguments of the form "Non-mainline custom hack X
could invalidate constraint Y, therefore we can't have Y in the
rulebase" are dangerous -- I suspect you could reduce your set of
constraints to nil very quickly that way, and thus badly screw over
the 99% of people who just want to build a more or less stock kernel.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The abortion rights and gun control debates are twin aspects of a deeper
question --- does an individual ever have the right to make decisions
that are literally life-or-death?  And if not the individual, who does?

Re: CML2 design philosophy heads-up

[Rogier Wolff]

Eric S. Raymond wrote:
> More generally, arguments of the form "Non-mainline custom hack X
> could invalidate constraint Y, therefore we can't have Y in the
> rulebase" are dangerous -- I suspect you could reduce your set of
> constraints to nil very quickly that way, and thus badly screw over
> the 99% of people who just want to build a more or less stock kernel.

Eric, 

Still being able to use the "tool" is useful! So I want a "don't mess
with me" mode where I'd get more control than 99% of the lusers....

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> I've said before on these lists that one of the purposes of
Eric> CML2's single-apex tree design is to move the configuration
Eric> dialog away from low-level platform- specific questions towards
Eric> higher-level questions about policy or intentions.

Eric> Or to put another way: away from hardware, towards capabilities.

Eric> As a concrete example, the CML2 rulesfile master for the m68k
Eric> port tree now has a section that looks like this:

Eric> # These were separate questions in CML1.  They enable on-board
Eric> peripheral # controllers in single-board computers.  derive
Eric> MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from
Eric> MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive
Eric> MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from
Eric> MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive
Eric> BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC
Eric> from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI

Not all cards have all features, not all users wants to enable all
features.

Eric> # These were separate questions in CML1 derive MAC_SCC from MAC
Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from
Eric> (SUN3 | SUN3X) & SCSI

As Alan already pointed out thats assumption is invalid.

Eric> This is different from the CML1 approach, which generally
Eric> involved explicitly specifying each driver with mutual
Eric> dependencies described (if at all) in Configure.help.

Yes and it should stay like that. If Richard had wanted all those
features enabled per default when an MVME setting was selected, he
would have done it in the config.in file, which is perfectly valid to
do so today.

Eric> This note is a heads-up.  If others with a stake in the
Eric> configuration system (port managers, etc.) have objections to
Eric> moving further in this direction, I need to hear about it, and
Eric> about what you think we should be doing instead.  -- <a
Eric> href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Yes I have objections. I thought I had made this clear a long time
ago: Go play with another port and leave the m68k port alone.

Thank you
Jes

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jes Sorensen <jes@sunsite.dk>:
> Not all cards have all features, not all users wants to enable all
> features.

Yes, I understand that.  You're not reading the derivations correctly.
Let's take an example:

derive MVME147_SCSI from MVME147 & SCSI

This doesn't turn on MVME147_SCSI on every MVME147 board.  It turns
on MVME147_SCSI when both MVME147 *and SCCI* are on.  So to suppress
MVME147_SCSI, one just leaves SCCI off.

All these derived symbols will still be controllable.  The difference
is that instead of being controlled by a low-level hardware-oriented
question they're controlled by a capability or subsystem symbol like
SCSI, NET_ETHERNET, or SERIAL.

> Eric> # These were separate questions in CML1 derive MAC_SCC from MAC
> Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from
> Eric> (SUN3 | SUN3X) & SCSI
> 
> As Alan already pointed out thats assumption is invalid.

I'm in touch with Ray Knight directly and will fix this as he requests.
 
> Yes I have objections. I thought I had made this clear a long time
> ago: Go play with another port and leave the m68k port alone.

Does this mean you'll take over maintaining the CML2 rules files
for the m68k port, so I don't have to?  That would be wonderful.

Reasoned objections can change my behavior.  Grunting territorial
challenges at me will not.  You have two options: (1) persuade Linus
that the whole CML2 thing is a bad idea and should be dropped, or (2)
work with me to correct any errors I have made and improve the system.
Growling at me and hoping I go away won't work, not when I've invested
a year's effort in this project.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

As with the Christian religion, the worst advertisement for Socialism
is its adherents.
	-- George Orwell 

Re: CML2 design philosophy heads-up

[Pavel Machek]

Hi!

> > Not all cards have all features, not all users wants to enable all
> > features.
> 
> Yes, I understand that.  You're not reading the derivations correctly.
> Let's take an example:
> 
> derive MVME147_SCSI from MVME147 & SCSI
> 
> This doesn't turn on MVME147_SCSI on every MVME147 board.  It turns
> on MVME147_SCSI when both MVME147 *and SCCI* are on.  So to suppress
> MVME147_SCSI, one just leaves SCCI off.

And If I want scsi-on-atapi emulation but not vme147_scsi?

You are right that your solution is right most of the time, but there
always will be nasty corner cases like that.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Pavel Machek <pavel@suse.cz>:
> And If I want scsi-on-atapi emulation but not vme147_scsi?

Help me understand this case, please.  What is scsi-on-atapi?
Is SCSI on when you enable it?  And is it a realistic case for an SBC?

The CML2 constraint language is very flexible.  I can make it do the
right thing, if I know what the right thing is.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491

Re: CML2 design philosophy heads-up

[Keith Owens]

On Thu, 17 May 2001 03:26:36 -0400, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>Pavel Machek <pavel@suse.cz>:
>> And If I want scsi-on-atapi emulation but not vme147_scsi?
>
>Help me understand this case, please.  What is scsi-on-atapi?
>Is SCSI on when you enable it?  And is it a realistic case for an SBC?

SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI.  You have the SCSI mid
layer code but no SCSI hardware drivers.  It is a realistic case for an
embedded CD-RW appliance.

BTW, there is a bug in the current setting of CONFIG_BLK_DEV_IDESCSI.
Starting with CONFIG_SCSI unset, you can set BLK_DEV_IDESCSI to y and
later set SCSI to n and get a mess, even with make oldconfig.  I am
discussing the fix with Andre Hendrick, expect BLK_DEV_IDESCSI to move
to the SCSI menu.

Re: CML2 design philosophy heads-up

[Michael Meissner]

On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote:
> On Thu, 17 May 2001 03:26:36 -0400, 
> "Eric S. Raymond" <esr@thyrsus.com> wrote:
> >Pavel Machek <pavel@suse.cz>:
> >> And If I want scsi-on-atapi emulation but not vme147_scsi?
> >
> >Help me understand this case, please.  What is scsi-on-atapi?
> >Is SCSI on when you enable it?  And is it a realistic case for an SBC?
> 
> SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI.  You have the SCSI mid
> layer code but no SCSI hardware drivers.  It is a realistic case for an
> embedded CD-RW appliance.

Or alternatively, you want to enable SCSI code, with no hardware driver,
because you are going to build pcmcia, which builds the scsi drivers only if
CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi
card into your pcmcia slot.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: CML2 design philosophy heads-up

[Tom Rini]

On Thu, May 17, 2001 at 05:35:49AM -0400, Michael Meissner wrote:
> On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote:
> > On Thu, 17 May 2001 03:26:36 -0400, 
> > "Eric S. Raymond" <esr@thyrsus.com> wrote:
> > >Pavel Machek <pavel@suse.cz>:
> > >> And If I want scsi-on-atapi emulation but not vme147_scsi?
> > >
> > >Help me understand this case, please.  What is scsi-on-atapi?
> > >Is SCSI on when you enable it?  And is it a realistic case for an SBC?
> > 
> > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI.  You have the SCSI mid
> > layer code but no SCSI hardware drivers.  It is a realistic case for an
> > embedded CD-RW appliance.
> 
> Or alternatively, you want to enable SCSI code, with no hardware driver,
> because you are going to build pcmcia, which builds the scsi drivers only if
> CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi
> card into your pcmcia slot.

Both of these 'problems' assume that you can have IDE or PCMCIA on these
particular boxes.  Does anyone know if that's actually true?

What eric is trying to do, can work, if done very carefully, and in very 
limited cases as well.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI.  You have the SCSI mid
> > > layer code but no SCSI hardware drivers.  It is a realistic case for an
> > > embedded CD-RW appliance.
> > 
> > Or alternatively, you want to enable SCSI code, with no hardware driver,
> > because you are going to build pcmcia, which builds the scsi drivers only
> > if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or
> > 1480 scsi card into your pcmcia slot.
> 
> Both of these 'problems' assume that you can have IDE or PCMCIA on these
> particular boxes.  Does anyone know if that's actually true?

The answer is: no, you can't.  

I found a feature list for the MVME147 on the web at
<http://www.mcg.mot.com/cfm/templates/article.cfm?PageID=1095>.  It
confirmed what thought I remembered from the Motorola site; no PCMCIA,
no IDE/ATAPI.  As a matter of fact neither of these technologies
existed yet when the board was being designed in the mid-1980s.

(The article I found is kind of interesting.  It's a dissection of the
MVME147's design and history...narrated in first person.)

In any case, if this *had* been a problem, the right fix IMO would have
been to split the SCSI symbol into SCSI and SCSI_DRIVERS and have
constraints that would make SCSI and the presence of any SCSI card 
imply SCSI_DRIVERS.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
	-- Albert Einstein, "My First Impression of the U.S.A.", 1921

Re: CML2 design philosophy heads-up

[Alan Cox]

> > Both of these 'problems' assume that you can have IDE or PCMCIA on these
> > particular boxes.  Does anyone know if that's actually true?
> 
> The answer is: no, you can't.  
> 
> I found a feature list for the MVME147 on the web at
> <http://www.mcg.mot.com/cfm/templates/article.cfm?PageID=1095>.  It
> confirmed what thought I remembered from the Motorola site; no PCMCIA,
> no IDE/ATAPI.  As a matter of fact neither of these technologies
> existed yet when the board was being designed in the mid-1980s.

I was under the impression the MVME had VME bus. So you can hang IDE off it
and other gunge. Its also a reference design so you may find MVME147 like
boards..

Alan

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> I was under the impression the MVME had VME bus. So you can hang IDE off it
> and other gunge. Its also a reference design so you may find MVME147 like
> boards..

Urk.  Alan is right, I misinterpreted the original question.  There is
no on-board support for IDE or PCMCIA, but you could plug in an IDE
daughterboard with an IDE drive or a PCMCIA slot.  This would be a
pretty damn perverse thing to do, however -- there are newer, less
expensive, faster, and generally better SBCs that have IDE/ATAPI and
PCMCIA built in.  On top of that, VMEbus SBCs aren't normally used for
consumer devices -- their market is basically industrial-control
applications with a side of scientific instrumentation.

That being the case, we do face a question of design
philosophy, expressed as a policy question about how to design
rulesets.  Actually two questions:

1. When we have a platform symbol for a reference design like MVME147, do 
   we stick to its spec sheet or consider it representative of all derivatives
   (which may have other facilities)?

I know my answer to this one, which I will implement unless there's
strong consensus otherwise.  I go for explicitness.  If we're going to
support MVME147 derivatives and variants in the ruleset, they get
their own platform symbols.

2. How much extra tsuris should we accept in order to handle
   perverse edge cases like this one?  There are three ways we
   can cope:

   (a) Back off the capability approach.  That is, accept that 
       people doing configuration are going to explicitly and 
       exhaustively specify low-level hardware.

   (b) Add complexity to the ruleset.  Split SCSI into SCSI_MIDLEVEL and 
       SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied
       whenever a SCSI card is configured, etc.

   (c) Decide not to support this case and document the fact in the
       rulesfile.  If you're going put gunge on the VME bus that replaces
       the SBC's on-board facilities, you can hand-hack your own configs.

I don't want to do (a); it conflicts with my design objective of
simplifying configuration enough that Aunt Tillie can do it.  I won't 
do that unless I see a strong consensus that it's the only Right Thing.

The larger question in choosing between (b) and (c) is one of the usual ones
in programming -- that is, generality vs. maintainability.  Is it ever 
acceptable for the configuration system to deliberately punt an edge case
like this one in order to keep from having a combinatorial-complexity
explosion in the ruleset?

I know what my sense of taste and proportion says.  But I'm not going
to impose my vision on everybody.  If you have an opinion, I'd like
to hear it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Whether the authorities be invaders or merely local tyrants, the
effect of such [gun control] laws is to place the individual at the 
mercy of the state, unable to resist.
        -- Robert Anson Heinlein, 1949

Re: CML2 design philosophy heads-up

[David Lang]

if you punt in case C you should then have a mode where all dependancies
are ignored and all options are presented to the person ding the config.
This is FAR better then forcing them to hand-hack the config file.

possibly split the rules file into two parts.

part 1. absolute requirements (i.e. if you select a SCSI controller you
MUST select SCSI)

part 2. simplifications (i.e. if x86 and printer then x86_printer)

tehn have a mode where the part 2 rules are not evaluated to handle the
corner cases.

David Lang


 On Fri, 18 May 2001, Eric S.
Raymond wrote:

> Date: Fri, 18 May 2001 10:53:53 -0400
> From: Eric S. Raymond <esr@thyrsus.com>
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Tom Rini <trini@kernel.crashing.org>,
>      Michael Meissner <meissner@spectacle-pond.org>,
>      Keith Owens <kaos@ocs.com.au>, CML2 <linux-kernel@vger.kernel.org>,
>      kbuild-devel@lists.sourceforge.net
> Subject: Re: CML2 design philosophy heads-up
>
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > I was under the impression the MVME had VME bus. So you can hang IDE off it
> > and other gunge. Its also a reference design so you may find MVME147 like
> > boards..
>
> Urk.  Alan is right, I misinterpreted the original question.  There is
> no on-board support for IDE or PCMCIA, but you could plug in an IDE
> daughterboard with an IDE drive or a PCMCIA slot.  This would be a
> pretty damn perverse thing to do, however -- there are newer, less
> expensive, faster, and generally better SBCs that have IDE/ATAPI and
> PCMCIA built in.  On top of that, VMEbus SBCs aren't normally used for
> consumer devices -- their market is basically industrial-control
> applications with a side of scientific instrumentation.
>
> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets.  Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
>    we stick to its spec sheet or consider it representative of all derivatives
>    (which may have other facilities)?
>
> I know my answer to this one, which I will implement unless there's
> strong consensus otherwise.  I go for explicitness.  If we're going to
> support MVME147 derivatives and variants in the ruleset, they get
> their own platform symbols.
>
> 2. How much extra tsuris should we accept in order to handle
>    perverse edge cases like this one?  There are three ways we
>    can cope:
>
>    (a) Back off the capability approach.  That is, accept that
>        people doing configuration are going to explicitly and
>        exhaustively specify low-level hardware.
>
>    (b) Add complexity to the ruleset.  Split SCSI into SCSI_MIDLEVEL and
>        SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied
>        whenever a SCSI card is configured, etc.
>
>    (c) Decide not to support this case and document the fact in the
>        rulesfile.  If you're going put gunge on the VME bus that replaces
>        the SBC's on-board facilities, you can hand-hack your own configs.
>
> I don't want to do (a); it conflicts with my design objective of
> simplifying configuration enough that Aunt Tillie can do it.  I won't
> do that unless I see a strong consensus that it's the only Right Thing.
>
> The larger question in choosing between (b) and (c) is one of the usual ones
> in programming -- that is, generality vs. maintainability.  Is it ever
> acceptable for the configuration system to deliberately punt an edge case
> like this one in order to keep from having a combinatorial-complexity
> explosion in the ruleset?
>
> I know what my sense of taste and proportion says.  But I'm not going
> to impose my vision on everybody.  If you have an opinion, I'd like
> to hear it.
> --
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> Whether the authorities be invaders or merely local tyrants, the
> effect of such [gun control] laws is to place the individual at the
> mercy of the state, unable to resist.
>         -- Robert Anson Heinlein, 1949
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: CML2 design philosophy heads-up

[Keith Owens]

cc trimmed back to mailing lists only.

On Fri, 18 May 2001 10:53:53 -0400, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>   (a) Back off the capability approach.  That is, accept that 
>       people doing configuration are going to explicitly and 
>       exhaustively specify low-level hardware.

No, you loose one of the nicer features of CML2.

>   (b) Add complexity to the ruleset.  Split SCSI into SCSI_MIDLEVEL and 
>       SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied
>       whenever a SCSI card is configured, etc.

As a specific case this needs doing anyway, to handle SCSI emulation
over IDE, irrespective of the board type.  It needs mid layer but no
SCSI driver and can be done on a PC right now.

As a general question, I prefer selecting machine type foo to mean just
that, you get the devices supported by foo.

>   (c) Decide not to support this case and document the fact in the
>       rulesfile.  If you're going put gunge on the VME bus that replaces
>       the SBC's on-board facilities, you can hand-hack your own configs.

In general this is the best option, if you create a non-standard
configuration for machine foo then it is your problem, not everybody
else's.

Re: CML2 design philosophy heads-up

[Arjan van de Ven]

Keith Owens wrote:

> >   (c) Decide not to support this case and document the fact in the
> >       rulesfile.  If you're going put gunge on the VME bus that replaces
> >       the SBC's on-board facilities, you can hand-hack your own configs.
> 
> In general this is the best option, if you create a non-standard
> configuration for machine foo then it is your problem, not everybody
> else's.

If you use a standard configuration, you can use a precompiled 
kernel as well.

Sorry I don't buy this. The point of the kernel configuration 
is to also allow non-standard configurations. Think about it:
the standard pc (PC99 or whatever it is called this year) doesn't
have a PS/2 port, only USB. So we can remove even the question 
from the config system, no? 

Greetings,
   Arjan van de Ven

Re: CML2 design philosophy heads-up

[Alan Cox]

> >   (c) Decide not to support this case and document the fact in the
> >       rulesfile.  If you're going put gunge on the VME bus that replaces
> >       the SBC's on-board facilities, you can hand-hack your own configs.
> 
> In general this is the best option, if you create a non-standard
> configuration for machine foo then it is your problem, not everybody
> else's.

Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets
this whole discussion wouldn't be needed. 

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > In general this is the best option, if you create a non-standard
> > configuration for machine foo then it is your problem, not everybody
> > else's.
> 
> Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets
> this whole discussion wouldn't be needed. 

I think you're confusing a couple of different issues here, Alan.  Even 
supposing CML2 could parse CML1 rulesets, the design question about how
configuration *should* work (that is, what kind of user experience we 
want to create and who we optimize ruleset design for) wouldn't go away.

I'm raising these questions now because CML2's capabilities invite 
thinking about them.  But they're independent of the underlying language.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
	-- Lazarus Long 

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> I think you're confusing a couple of different issues here, Alan.  Even 
> supposing CML2 could parse CML1 rulesets, the design question about how
> configuration *should* work (that is, what kind of user experience we 
> want to create and who we optimize ruleset design for) wouldn't go away.

It would. Because people who like the old config would continue to use the 
old tools

Alan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > I think you're confusing a couple of different issues here, Alan.  Even 
> > supposing CML2 could parse CML1 rulesets, the design question about how
> > configuration *should* work (that is, what kind of user experience we 
> > want to create and who we optimize ruleset design for) wouldn't go away.
> 
> It would. Because people who like the old config would continue to use the 
> old tools

Excuse me?

Alan, it sounds very much like you just said something stupid.  This
seems sufficiently unlikely that I am shaking my head in disbelief and
fingernailing wax out of both ears (and if you think doing both those
things at once is easy try it sometime :-)).

Do you really believe that anyone is going to maintain the CML1 tools
for as long as a nanosecond after they get dropped out of the kernel tree?

Even supposing somebody were loony enough to do that, how would preserving
an old interface in amber do anything to explore new UI possibilities?

Perhaps I'm just unusually dense this morning.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse.  Oppose the War On Some Drugs!

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
> Alan, it sounds very much like you just said something stupid.  This
> seems sufficiently unlikely that I am shaking my head in disbelief and
> fingernailing wax out of both ears (and if you think doing both those
> things at once is easy try it sometime :-)).
> 
> Do you really believe that anyone is going to maintain the CML1 tools
> for as long as a nanosecond after they get dropped out of the kernel tree?

I _will_ continue to maintain mconfig (after mec stopped even before cml2).

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

"Eric S. Raymond" wrote:
> > It would. Because people who like the old config would continue to use the
> > old tools
> 
> Excuse me?

> Do you really believe that anyone is going to maintain the CML1 tools
> for as long as a nanosecond after they get dropped out of the kernel tree?

I hereby volunteer to maintain at least make oldconfig and make config, 
and perhaps make menuconfig.

 
> Even supposing somebody were loony enough to do that, how would preserving
> an old interface in amber do anything to explore new UI possibilities?

kernel != GUI

There are plenty of UI kernel configurators out there. Good ones. Bad
ones. 
LOOK AT THEM. FIX THEM if you don't like them. But PLEASE don't even
think
about taking the current, very useful for advanced users, tools away
without
offering something of at least the same capabilities.

 
> Perhaps I'm just unusually dense this morning.

Given the rest of this thread, unusual is not the word that comes to my
mind
(sorry, open door and you asked for it)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> I hereby volunteer to maintain at least make oldconfig and make config, 
> and perhaps make menuconfig.

That's the easy part; the CML1 config code may be ugly and broken, but
at least it's relatively stable.  What you'd also have to do is maintain an
entire CML1 ruleset in parallel with the canonical CML2 one.  That's 
the hard part.

I've been keeping the CML2 ruleset synced with CML1 for a year now. 
It's been an ugly, nasty, horrible job -- *much* nastier, by an order
of magnitude, than designing and writing the CML2 engine.  Going the
other direction would be worse.  "Like chewing razor blades" is the
simile that leaps to mind.

(And no, dropping back to CML1 format for the masters wouldn't be an
option; it doesn't have the semantic strength to enable CML2's new
capabilities.)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Certainly one of the chief guarantees of freedom under any government,
no matter how popular and respected, is the right of the citizens to
keep and bear arms.  [...] the right of the citizens to bear arms is
just one guarantee against arbitrary government and one more safeguard
against a tyranny which now appears remote in America, but which
historically has proved to be always possible.
        -- Hubert H. Humphrey, 1960

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

On Fri, May 18, 2001 at 01:17:07PM -0400, Eric S. Raymond wrote:
> It's been an ugly, nasty, horrible job -- *much* nastier, by an order
> of magnitude, than designing and writing the CML2 engine.  Going the
> other direction would be worse.  "Like chewing razor blades" is the
> simile that leaps to mind.

And you hope this will not be razorblades if Linus decides he likes CML2 ?

 
> (And no, dropping back to CML1 format for the masters wouldn't be an
> option; it doesn't have the semantic strength to enable CML2's new
> capabilities.)

Right now, it's now a dropping back. You seem to take for granted that CML2
and your python2 frontend to it are 2.5.0 material. I don't right now.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> Right now, it's now a dropping back. You seem to take for granted that CML2
> and your python2 frontend to it are 2.5.0 material. I don't right now.

Linus is free to change his mind.  Perhaps he will.  But the last word I heard
from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe.  That's the
assumption I'm operating on.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

An armed society is a polite society.  Manners are good when one 
may have to back up his acts with his life.
        -- Robert A. Heinlein, "Beyond This Horizon", 1942

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Ben Ford]

Arjan van de Ven wrote:

>"Eric S. Raymond" wrote:
>
>>
>>an old interface in amber do anything to explore new UI possibilities?
>>
>
>kernel != GUI
>

UI != GUI

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> Do you really believe that anyone is going to maintain the CML1 tools
> for as long as a nanosecond after they get dropped out of the kernel tree?

Do you really believe anyone would be dumb enough to delete them out of spite
or to further your political machinations if they could both handle the same
configuration language.

CML1 has had no official maintainer for about 4 years. People contribute bits
and it works. So as it stands there would be no reason to remove it.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Do you really believe anyone would be dumb enough to delete them out of spite
> or to further your political machinations if they could both handle the same
> configuration language.

That's a big "if" which I don't think is ever going to happen.  The
CML1 and CML2 languages are nowhere near semantically equivalent.  I
know them both intimately, and bridging the gap is a much harder
problem than you seem prepared to realize.

They look closer together than they are, because you can superficially
map individual features between them (CML2 derivations look like CML1
defines, for example).  The big difference is subtler, and has to do with
the difference between a control language and a constraint language.  As
a result, there are things you can easily do in CML2 that you can't 
practically speaking do in CML1.

For CML1 and CML2 to handle the same language, we would either have
to live with the CML1 language's limitations or retrofit the old tools
to speak CML2 language.  The chance of the latter happening is, I think
we can agree, effectively zero.

I know you've talked about parsing CML1 into constraints with
backtracking.  Maybe you're smart enough to do that.  I'm not.  I
tried that route early on.  I predict that if you do, you'll
experience a great deal of suffering, acquire a valuable education,
and get no good result.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> For CML1 and CML2 to handle the same language, we would either have
> to live with the CML1 language's limitations or retrofit the old tools
> to speak CML2 language.  The chance of the latter happening is, I think
> we can agree, effectively zero.

Being able to turn CML2 into CML1 might be the more useful exercise.

Alan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Being able to turn CML2 into CML1 might be the more useful exercise.

That's...not a completely crazy idea.  Hmmm...

It might be possible to take a CML2 rulebase and generate a sort of stupid
jackleg CML1 translation of it.  The resulting config.in would be huge
and nasty, and would only work in forward sequence with no side-effect
computation, but you just might be able to get the old tools to parse it.

Again there's a technical problem with derivations.   Probably solvable.

But the real question is whether the old tools have enough value to be
worth the effort.  What problem are you trying to solve here?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

This would be the best of all possible worlds, if there were
no religion in it.
	-- John Adams, in a letter to Thomas Jefferson.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> But the real question is whether the old tools have enough value to be
> worth the effort.  What problem are you trying to solve here?

Im just playing with ideas and writing a CML1 parser for amusement while I
ponder single pass computation of the entire dependancy graph from a CML1
rule base 8)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Aaron Lehmann]

On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
> Even supposing somebody were loony enough to do that, how would preserving
> an old interface in amber do anything to explore new UI possibilities?

I don't know about the rest of the world, but I _much_ prefer the old
menuconfig to CML2's menuconfig. While I haven't spent much time playing
with CML2, I'm familiar with cml1's tools and see no reason why they
need changes, which IMHO (so far) are detrimental.

That's not even to mention python issues, speed, or anything else.

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Keith" == Keith Owens <kaos@ocs.com.au> writes:

Keith> cc trimmed back to mailing lists only.  On Fri, 18 May 2001
Keith> 10:53:53 -0400, "Eric S. Raymond" <esr@thyrsus.com> wrote:
>> (a) Back off the capability approach.  That is, accept that people
>> doing configuration are going to explicitly and exhaustively
>> specify low-level hardware.

Keith> No, you loose one of the nicer features of CML2.

No, explicit selection *must* be available as an option.

Jes

Re: CML2 design philosophy heads-up

[Arjan van de Ven]

>    (a) Back off the capability approach.  That is, accept that
>        people doing configuration are going to explicitly and
>        exhaustively specify low-level hardware.

<snip>

 
> I don't want to do (a); it conflicts with my design objective of
> simplifying configuration enough that Aunt Tillie can do it.  I won't
> do that unless I see a strong consensus that it's the only Right Thing.

Aunt Tillie doesn't even know what a kernel is, nor does she want to. I
think 
it's fair to assume that people who configure and compile their own
kernel 
(as opposed to using the distribution supplied ones) know what they are
doing.

Or at least make something like a "Expert level" question as first
question, so 
that people who DO know what they are doing can select the options they
want.
Going from "make config" (which has a scary interface for novice users,
agreed)
to "vi" is NOT progress.

Greetings,
   Arjan van de Ven

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> Aunt Tillie doesn't even know what a kernel is, nor does she want
> to. I think it's fair to assume that people who configure and
> compile their own kernel (as opposed to using the distribution
> supplied ones) know what they are doing.

I'd like to break these assumptions.  Or at the very least see how far
they can be bent.  I know this sounds crazy to a lot of hackers, but 
I think there's a certain amount of unhelpful elitism and self-puffery
in the "kernels are hard to configure and they *should* be hard to 
configure* attitude.  Let's give Aunt Tillie a chance to surprise us.

> Or at least make something like a "Expert level" question as first
> question, so that people who DO know what they are doing can select
> the options they want.

Already in the plan -- in fact the EXPERT symbol exists in CML2 now.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

It is proper to take alarm at the first experiment on our
liberties. We hold this prudent jealousy to be the first duty of
citizens and one of the noblest characteristics of the late
Revolution. The freemen of America did not wait till usurped power had
strengthened itself by exercise and entangled the question in
precedents. They saw all the consequences in the principle, and they
avoided the consequences by denying the principle. We revere this
lesson too much ... to forget it
	-- James Madison.

Re: CML2 design philosophy heads-up

[Charles Cazabon]

Eric S. Raymond <esr@thyrsus.com> wrote:
> Arjan van de Ven <arjanv@redhat.com>:
> > Aunt Tillie doesn't even know what a kernel is, nor does she want
> > to. I think it's fair to assume that people who configure and
> > compile their own kernel (as opposed to using the distribution
> > supplied ones) know what they are doing.
> 
> I'd like to break these assumptions.  Or at the very least see how far
> they can be bent.  I know this sounds crazy to a lot of hackers, but 
> I think there's a certain amount of unhelpful elitism and self-puffery
> in the "kernels are hard to configure and they *should* be hard to 
> configure* attitude.  Let's give Aunt Tillie a chance to surprise us.

Whether this is desirable or not is debatable.  The big question is:  why on
earth would Aunt Tillie _want_ to compile a kernel at all, let alone
re-configure one?  If she's using Linux, she's installing her distribution's
pre-compiled kernel, and has no need for anything else.

Simplifying the configuration interface so that "anyone" can use it seems like
a waste of effort.  If there's an interested novice out there who wants to
learn how to configure a kernel, they'll be sufficiently interested to invest
an hour or two in learning how the whole process works.  Make it as simple as
it needs to be, and no simpler.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------

Re: CML2 design philosophy heads-up

[David Lang]

why is it that so many people seem to think that it's a good thing to only
use precompiled kernels from the distro?

a kernel tuned for a particular machine can boot faster and run faster
then a 'stock' kernel.

unless you want to replace the kernel compile config options with a
similar sized menu to select between precompiled kernels with the correct
options (never mind what that will do to the size of the distros to ship
so many kernels)


David Lang

 On Fri, 18 May 2001, Charles Cazabon wrote:

> Date: Fri, 18 May 2001 09:34:14 -0600
> From: Charles Cazabon <linux-kernel@discworld.dyndns.org>
> To: linux-kernel@vger.kernel.org
> Subject: Re: CML2 design philosophy heads-up
>
> Eric S. Raymond <esr@thyrsus.com> wrote:
> > Arjan van de Ven <arjanv@redhat.com>:
> > > Aunt Tillie doesn't even know what a kernel is, nor does she want
> > > to. I think it's fair to assume that people who configure and
> > > compile their own kernel (as opposed to using the distribution
> > > supplied ones) know what they are doing.
> >
> > I'd like to break these assumptions.  Or at the very least see how far
> > they can be bent.  I know this sounds crazy to a lot of hackers, but
> > I think there's a certain amount of unhelpful elitism and self-puffery
> > in the "kernels are hard to configure and they *should* be hard to
> > configure* attitude.  Let's give Aunt Tillie a chance to surprise us.
>
> Whether this is desirable or not is debatable.  The big question is:  why on
> earth would Aunt Tillie _want_ to compile a kernel at all, let alone
> re-configure one?  If she's using Linux, she's installing her distribution's
> pre-compiled kernel, and has no need for anything else.
>
> Simplifying the configuration interface so that "anyone" can use it seems like
> a waste of effort.  If there's an interested novice out there who wants to
> learn how to configure a kernel, they'll be sufficiently interested to invest
> an hour or two in learning how the whole process works.  Make it as simple as
> it needs to be, and no simpler.
>
> Charles
> --
> -----------------------------------------------------------------------
> Charles Cazabon                            <linux@discworld.dyndns.org>
> GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
> Any opinions expressed are just that -- my opinions.
> -----------------------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: CML2 design philosophy heads-up

[Charles Cazabon]

David Lang <david.lang@digitalinsight.com> wrote:

> > Whether this is desirable or not is debatable.  The big question is:  why
> > on earth would Aunt Tillie _want_ to compile a kernel at all, let alone
> > re-configure one?  If she's using Linux, she's installing her
> > distribution's pre-compiled kernel, and has no need for anything else.

> why is it that so many people seem to think that it's a good thing to only
> use precompiled kernels from the distro?  a kernel tuned for a particular
> machine can boot faster and run faster then a 'stock' kernel.

I'm not saying it's a good thing.  I'm saying that the 5% performance increase
that results is not something that the average "I just want to use the system"
will even notice, let alone care about.

> unless you want to replace the kernel compile config options with a
> similar sized menu to select between precompiled kernels with the correct
> options (never mind what that will do to the size of the distros to ship
> so many kernels)

They don't need to ship a mass of kernels.  Modern distributions probably
don't need to worry about shipping three or four modular kernels.  Any user
who cares about the minor performance benefits of a custom-configured kernel
is going to reconfigure and recompile regardless of how dumbed-down the
interface is.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------

Re: CML2 design philosophy heads-up

[Alan Cox]

> Simplifying the configuration interface so that "anyone" can use it seems like
> a waste of effort.  If there's an interested novice out there who wants to
> learn how to configure a kernel, they'll be sufficiently interested to invest
> an hour or two in learning how the whole process works.  Make it as simple as
> it needs to be, and no simpler.

Having a simple interface is good. Being guided by probable correct choices 
helps many people, but it needs to support a simple interface as well as a real
one if the two conflict in design goals

Re: CML2 design philosophy heads-up

[Ben Ford]

Charles Cazabon wrote:

>Eric S. Raymond <esr@thyrsus.com> wrote:
>
>>Arjan van de Ven <arjanv@redhat.com>:
>>
>>>Aunt Tillie doesn't even know what a kernel is, nor does she want
>>>to. I think it's fair to assume that people who configure and
>>>compile their own kernel (as opposed to using the distribution
>>>supplied ones) know what they are doing.
>>>
>>I'd like to break these assumptions.  Or at the very least see how far
>>they can be bent.  I know this sounds crazy to a lot of hackers, but 
>>I think there's a certain amount of unhelpful elitism and self-puffery
>>in the "kernels are hard to configure and they *should* be hard to 
>>configure* attitude.  Let's give Aunt Tillie a chance to surprise us.
>>
>
>Whether this is desirable or not is debatable.  The big question is:  why on
>earth would Aunt Tillie _want_ to compile a kernel at all, let alone
>re-configure one?  If she's using Linux, she's installing her distribution's
>pre-compiled kernel, and has no need for anything else.
>
>Simplifying the configuration interface so that "anyone" can use it seems like
>a waste of effort.  If there's an interested novice out there who wants to
>learn how to configure a kernel, they'll be sufficiently interested to invest
>an hour or two in learning how the whole process works.  Make it as simple as
>it needs to be, and no simpler.
>
>Charles
>
Because, for example, a kernel compile can be a part of the standard 
install now, and you will end up with a kernel built specifically for 
your machine that doesn't print 50 initialization failed messages on boot.

Libranet (Debian offshoot) does that already.  It is the only distro 
that I know of that does this.  This also makes it about a thousand 
times easier for distributions.  They don't have to write huge (have you 
ever looked at Redhat scripts??) init scripts to cover every single 
possibility and load any module you might need.  It's built into the 
kernel, the way it should be!

And you can also now run a kernel built for your shiny new Athlon, not 
the old piece of shit that was hot stuff in '92.

-b

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: CML2 design philosophy heads-up

[Pete Zaitcev]

>[about Aunt Tullie]
> Because, for example, a kernel compile can be a part of the standard 
> install now, and you will end up with a kernel built specifically for 
> your machine that doesn't print 50 initialization failed messages on boot.
>[...]
> And you can also now run a kernel built for your shiny new Athlon, not 
> the old piece of shit that was hot stuff in '92.

It is way too easy to crush your example, by pointing out that
Red Hat ships and automatically installs an Athlon-optimized kernel.

However, the argument above is wrong even if Red Hat did not.
We are talking about CML2 and interaction with Aunt Tullie.
This has nothing to do with automated rebuild at install time.

-- Pete

Re: CML2 design philosophy heads-up

[Ben Ford]

Pete Zaitcev wrote:

>>[about Aunt Tullie]
>>Because, for example, a kernel compile can be a part of the standard 
>>install now, and you will end up with a kernel built specifically for 
>>your machine that doesn't print 50 initialization failed messages on boot.
>>[...]
>>And you can also now run a kernel built for your shiny new Athlon, not 
>>the old piece of shit that was hot stuff in '92.
>>
>
>It is way too easy to crush your example, by pointing out that
>Red Hat ships and automatically installs an Athlon-optimized kernel.
>
>However, the argument above is wrong even if Red Hat did not.
>We are talking about CML2 and interaction with Aunt Tullie.
>This has nothing to do with automated rebuild at install time.
>
>-- Pete
>

First off, the lady's name was Tillie ;)

Second, how many kernels does Redhat ship in order to have one for 
386/486/586/k6/Athlon . . . .
Quite a pain in the ass.  And look at how much shit has to be built in 
in order to get a kernel that works for everybody!  People bitch at 
Microsoft for doing it, then turn around and do the same thing.

And nobody said anything about an automated rebuild.

I said a custom kernel build at install time.  I said nothing about 
having it automated.  I wouldn't trust an automated build anyways, 
especially if it came from Redhat.  With the philosophy ESR is aiming 
at, it would be all to easy to ask the user if they'd like to build a 
custom kernel, then present them with Eric's interface.  And that has 
everything to do with interaction with good ole Aunt Tillie.

-b

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: CML2 design philosophy heads-up

[Arjan van de Ven]

In article <3B064690.2040803@kalifornia.com> you wrote:
> Second, how many kernels does Redhat ship in order to have one for 
> 386/486/586/k6/Athlon . . . .

We build a lot of them :)

> Quite a pain in the ass.  And look at how much shit has to be built in 
> in order to get a kernel that works for everybody!  People bitch at 
> Microsoft for doing it, then turn around and do the same thing.

MODULES

> I said a custom kernel build at install time.  I said nothing about 
> having it automated.  I wouldn't trust an automated build anyways, 
> especially if it came from Redhat.  With the philosophy ESR is aiming 
> at, it would be all to easy to ask the user if they'd like to build a 
> custom kernel, then present them with Eric's interface.  And that has 
> everything to do with interaction with good ole Aunt Tillie.

There is one important point here: NOBODY objects to having a simple
interface. KDE people made one, ESR is cloning their idea, fine with me. 

I and several others object to TAKING AWAY the "advanced" tool that _does_
allow me to build a kernel for "my freak hardware". 

ESR's method is incompatible with that. He wants to not even ask the
questions that he considers weird for a particular machine. So if I connect
a cdromdrive to my iPAQ, I'll have to resort to vi/emacs. That's not
progress. 

There is a distinction between "true dependencies" on a sourcecode level (eg
the PDC202xx IDE driver requires the core IDE code to be built in) and
dependencies/requirements/auto-selects on an "Aunt Tillie" level (eg I have
a Dell Machine type FOO -> IDE + proper controller are selected and VooDoo7
3D cards are asked / looked up in PCI config space).

The current Config.in system is not much more than making the true
dependencies explicit. AND that is enough for some of the GUI kernel config
tools out there to make an Aunt Tillie level config program. Yes they need
to add extra information. Some of that can even be extracted from the PCI
tables in the driver-sourcecode. Taking away the true dependency information
and replacing it by things that are likely/unlikely is bad. It will work for
95% of the PC's out there, sure. 

There's freak hardware. People build freak kernels. Heck, when I build the
Red Hat Linux kernel, ESR would call that a freak kernel. Because it
supports hardware combinations that are VERY unlikely. The kernel both
supports ISA NIC's and 8way SMP servers. Yes you're a freak if you put a ISA
NIC in your 8way server. But YES the Red Hat kernel needs both, although
it's unlikely you need both on the same machine.

Greetings,
   Arjan van de Ven

Re: CML2 design philosophy heads-up

[Alan Cox]

> Second, how many kernels does Redhat ship in order to have one for 
> 386/486/586/k6/Athlon . . . .
> Quite a pain in the ass.  And look at how much shit has to be built in 
> in order to get a kernel that works for everybody!  People bitch at 
> Microsoft for doing it, then turn around and do the same thing.

No people bitch at microsoft for precisely the opposite - not including a
way to build fully optimised setups for each cpu type - not including all the
stuff that is needed (try a generic win2k install on a vaio one day)

I think you have your facts backwards

Alan

Re: CML2 design philosophy heads-up

[Ben Ford]

Alan Cox wrote:

>>Second, how many kernels does Redhat ship in order to have one for 
>>386/486/586/k6/Athlon . . . .
>>Quite a pain in the ass.  And look at how much shit has to be built in 
>>in order to get a kernel that works for everybody!  People bitch at 
>>Microsoft for doing it, then turn around and do the same thing.
>>
>
>No people bitch at microsoft for precisely the opposite - not including a
>way to build fully optimised setups for each cpu type - not including all the
>stuff that is needed (try a generic win2k install on a vaio one day)
>
>I think you have your facts backwards
>
>Alan
>

No, my point was, if I don't have SCSI or RAID on this box, I don't want 
them to be built into the kernel!

In other words, "stuff I don't need, just like Microsoft".

-b

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: CML2 design philosophy heads-up

[Alan Cox]

> No, my point was, if I don't have SCSI or RAID on this box, I don't want 
> them to be built into the kernel!

They arent built into the kernel. I still think you have your facts confused

Re: CML2 design philosophy heads-up

[Arjan van de Ven]

On Fri, May 18, 2001 at 11:26:25AM -0400, Eric S. Raymond wrote:
> I'd like to break these assumptions.  Or at the very least see how far
> they can be bent.  I know this sounds crazy to a lot of hackers, but 
> I think there's a certain amount of unhelpful elitism and self-puffery
> in the "kernels are hard to configure and they *should* be hard to 
> configure* attitude.  Let's give Aunt Tillie a chance to surprise us.

Don't get me wrong. I'm NOT opposed to having a config tool everyone and
their aunt can use. I'm opposed to that tool taking away the options expert
users have to do what they know is right for them.

Thankfully, decent tools for novice users already exists, in the KDE project
for example. And if the tool is missing a few things, please improve it
instead of forking a new tool with the same goal.

Greetings,
  Arjan van de Ven

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> Don't get me wrong. I'm NOT opposed to having a config tool everyone and
> their aunt can use. I'm opposed to that tool taking away the options expert
> users have to do what they know is right for them.

I'll take that as a vote for (b), to handle even perverse configurations 
even if it means adding a lot of complexity to the ruleset.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

...the Federal Judiciary...an irresponsible body, working like gravity
by night and by day, gaining a little today and a little tomorrow, and
advancing its noiseless step like a thief over the field of
jurisdiction until all shall be usurped from the States; and the
government of all be consolidated into one.

Re: CML2 design philosophy heads-up

[Arjan van de Ven]

"Eric S. Raymond" wrote:
> 
> Arjan van de Ven <arjanv@redhat.com>:
> > Don't get me wrong. I'm NOT opposed to having a config tool everyone and
> > their aunt can use. I'm opposed to that tool taking away the options expert
> > users have to do what they know is right for them.
> 
> I'll take that as a vote for (b), to handle even perverse configurations
> even if it means adding a lot of complexity to the ruleset.

In my opinion, no configuration that is actually physically possible
is perverse. 

So if you go for (a) you can take this as a vote of NOOOOOO PLEASE LINUS
DON'T

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Arjan van de Ven <arjanv@redhat.com>:
> In my opinion, no configuration that is actually physically possible
> is perverse. 

Noted.  And a very pithy statement of the position.  Thanks.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

I do not find in orthodox Christianity one redeeming feature.
	-- Thomas Jefferson

Re: CML2 design philosophy heads-up

[David Woodhouse]

esr@thyrsus.com said:
>  I'll take that as a vote for (b), to handle even perverse
> configurations  even if it means adding a lot of complexity to the
> ruleset.

As long as the ruleset is sufficient to represent the desired parts of the 
original behaviour of CML1, that should be fine.

Which means that it must be possible to individually select drivers which
aren't standard for your board. The dependencies in CML1 are (supposed to
be) absolute - the 'advisory' dependencies you're adding are arguably a
useful feature, but please don't make it possible to confuse the two, and
please do make sure it's possible to disable the latter form.

I'm one of the people who Jes has heard saying both 'I don't care' and 
'NO!'. The latter on the occasions when it seems you're going to be 
reducing the usablility of the existing system.

I am happiest when my interaction with the config system consists only of 
'cvs {commit,update} .config' 'pico .config' and 'make oldconfig'. I don't 
configure kernels for new boards very often - but on the occasions I do, 
it's often embedded boards based on a reference design, with irrelevant 
hardware omitted and some new stuff added in.

Having the capability to fix up CVS conflicts in 'make oldconfig' would be 
a random feature creep that I _would_ approve of :)

--
dwmw2

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
>                              The dependencies in CML1 are (supposed to
> be) absolute - the 'advisory' dependencies you're adding are arguably a
> useful feature, but please don't make it possible to confuse the two, and
> please do make sure it's possible to disable the latter form.

I don't understand this request.  I have no concept of `advisory' dependencies.
What are you talking about?   Is my documentation horribly unclear?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Both oligarch and tyrant mistrust the people, 
and therefore deprive them of arms."
	--Aristotle

Re: CML2 design philosophy heads-up

[Keith Owens]

On Sun, 20 May 2001 11:18:56 -0400, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>David Woodhouse <dwmw2@infradead.org>:
>>                              The dependencies in CML1 are (supposed to
>> be) absolute - the 'advisory' dependencies you're adding are arguably a
>> useful feature, but please don't make it possible to confuse the two, and
>> please do make sure it's possible to disable the latter form.
>
>I don't understand this request.  I have no concept of `advisory' dependencies.
>What are you talking about?   Is my documentation horribly unclear?

People read documentation?  No chance.

Some people have got it into their heads that the "Aunt Tillie" method
of configuration will be the only one allowed.  They do not realise
that this is the novice method, experts can still do what they like.
For dwm's "advisory dependencies", read novice mode, and of course it
can be overridden by people who know what they are doing.

Re: CML2 design philosophy heads-up

[David Woodhouse]

esr@thyrsus.com said:
> I don't understand this request.  I have no concept of `advisory'
> dependencies. What are you talking about?   Is my documentation
> horribly unclear? 

By 'dependency' I refer to the case where the value of one symbol is derived
entirely from, or the range of possible values is limited by, the value of
another symbol.

There are differing reasons for this, which should be treated entirely 
separately.

On one hand you have dependencies which are present to make life easier for 
Aunt Tillie, by refraining from confusing her with strange questions to 
which the answer is _probably_ 'no'. Like the question of whether she has 
an IDE controller on her MVME board.

One the other hand, you have the dependencies present in the existing CML1
configuration, which are _absolute_ dependencies - which specify for example
that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc.
These dependencies are there to prevent you from enabling combinations of
options which are utterly meaningless, and usually won't even compile.

The former type of dependency should^HMUST be optional. Those who know what
they're doing will want to turn them off. I see a lot of boards based on
some reference design or other but with a few tweaks and added or removed
devices - that's what the reference designs are there for; after all. 

By making a distinction between the two types of dependency in the
configuration language, you can pander to Aunt Tillie without actually
getting on the tits of those who don't wish to be arbitrarily restricted
from enabling support for the device they _know_ is present because they
just soldered it to the blinkin' circuit board. :)

--
dwmw2

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> On one hand you have dependencies which are present to make life easier for 
> Aunt Tillie, by refraining from confusing her with strange questions to 
> which the answer is _probably_ 'no'. Like the question of whether she has 
> an IDE controller on her MVME board.
> 
> One the other hand, you have the dependencies present in the existing CML1
> configuration, which are _absolute_ dependencies - which specify for example
> that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc.
> These dependencies are there to prevent you from enabling combinations of
> options which are utterly meaningless, and usually won't even compile.

There are no `advisory' dependencies in CML2.  They're all absolute.

What you call an `advisory' dependency would be simulated by having a 
policy symbol for Aunt Tillie mode and writing constraints like this:

require AUNT_TILLIE implies FOO >= BAR

This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING 
policy symbols, as hooks for doing things like this. 
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

>1. The Mac derivations were half-right.  The MAC_SCC one is good but Macs
>can have either of two different SCSI controllers.  I fixed that with help
>from Ray Knight, who maintains the 68K Mac port.

If I understand the "philosophy" correctly, it is still possible to specify
additional cards for those Macs which have PCI slots.  If so, absolutely
fine - I can shove my Adaptec 19160 into my G4 and have it work just as
well as it currently does in my Athlon.

One caveat though - not all Macs have SCSI controllers, and not all that do
even have one of the two standard ones.  The "Blue and White G3", the iMac,
the PowerBook G3 "Firewire" and later models on these lines all lack a
built-in SCSI controller, but many could have one added via PCI or CardBus
slots.  The PowerBooks 5300 and 190 (and possibly others) use some
non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know
how to drive.  However, in these situations, disabling the extra drivers is
usually not critical unless you're running low on space somewhere.  At that
point, you enable the "Are you insane?" module outlined below...

>3. The MVME derivations are correct *if* (and only if) you agree to ignore
>the possibility that somebody could want to ignore the onboard hardware,
>plug outboard disk or Ethernet cards into the VME-bus connector, and
>do something like running SCSI-over-ATAPI to the outboard device.
>(I missed these possibilities when I wrote the derivations.)

...and then someone else mentioned the possibility of f*x0r3d hardware.  In
this case, I would say this *isn't* a kernel-configuration issue but one of
being able to disable the drivers for the malfunctioning hardware.  If I
have a PCMCIA controller that reboots the machine as soon as the driver
tries to switch it on, I should be able to send a command-line parameter to
the kernel which tells it to switch it off *at run-time*.  And iff I'm
running with hardware which is so f*x0r3d that that isn't enough, I'd
either fix the hardware or hack the config files.  I don't see the problem.

I think the MVME derivations are *perfectly* sensible - if the reference
board and most (read: virtually all) derivatives have those features, turn
them on by all means.  To satisfy some others, you might want to say "Hey,
these guys might want to *explicitly turn off* some of this stuff" - so
provide an option under "Are you insane?" which presents all the "derived"
symbols and allows the hackers to manually turn stuff off.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 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+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Jonathan Morton <chromi@cyberspace.org>:
> One caveat though - not all Macs have SCSI controllers, and not all that do
> even have one of the two standard ones.

I know.  But these derivations are only for the old 68K macs, which don't
have PCI.  Closed issue.

> >3. The MVME derivations are correct *if* (and only if) you agree to ignore
> >the possibility that somebody could want to ignore the onboard hardware,
> >plug outboard disk or Ethernet cards into the VME-bus connector, and
> >do something like running SCSI-over-ATAPI to the outboard device.
> 
> ...and then someone else mentioned the possibility of f*x0r3d hardware.  In
> this case, I would say this *isn't* a kernel-configuration issue but one of
> being able to disable the drivers for the malfunctioning hardware.

But the other side is going to ask: suppose you're memory-limited
(quite likely on older SBCs) and don't want to pay the core cost of
drivers you won't use?  I don't really think we can duck this question
by talking about boot-time parameters.

> I think the MVME derivations are *perfectly* sensible - if the reference
> board and most (read: virtually all) derivatives have those features, turn
> them on by all means.

That's my gut feeling, too.  But a lot of people insist that the only right 
way is totally fine-grained control, even in weird edge cases like this one.

>                 To satisfy some others, you might want to say "Hey,
> these guys might want to *explicitly turn off* some of this stuff" - so
> provide an option under "Are you insane?" which presents all the "derived"
> symbols and allows the hackers to manually turn stuff off.

Interesting thought...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

I cannot undertake to lay my finger on that article of the
Constitution which grant[s] a right to Congress of expending, on
objects of benevolence, the money of their constituents.
	-- James Madison, 1794

Re: CML2 design philosophy heads-up

[David Woodhouse]

esr@thyrsus.com said:
> There are no `advisory' dependencies in CML2.  They're all absolute.
> What you call an `advisory' dependency would be simulated by having a
> policy symbol for Aunt Tillie mode and writing constraints like this:

> require AUNT_TILLIE implies FOO >= BAR

> This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING
> policy symbols, as hooks for doing things like this.  

Excellent. Then I apologise for not reading the documentation.

After the discussion of MAC and SCSI config options many moons ago in this
thread, I was left with the impression that the constraints which were 
being objected to were not dependent upon a NOVICE mode, but were 
unconditional.

Was this merely a mistake in the conversion of the ruleset? Do you have a 
policy that the default behaviour should be similar to that of CML1, or at 
least that such behaviour should be available through one of the 
modes? If not, please consider doing so.

--
dwmw2

Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Those of you who have become confused about the current argument over CML2
should read this...

David Woodhouse <dwmw2@infradead.org>:
> After the discussion of MAC and SCSI config options many moons ago in this
> thread, I was left with the impression that the constraints which were 
> being objected to were not dependent upon a NOVICE mode, but were 
> unconditional.
> 
> Was this merely a mistake in the conversion of the ruleset? Do you have a 
> policy that the default behaviour should be similar to that of CML1, or at 
> least that such behaviour should be available through one of the 
> modes? If not, please consider doing so.

They were unconditional.  It looks like a recap of history is in order.

Until very recently, like ten days ago, I had a policy of altering the
CML1 behavior as little as possible while I got CML2 up and running.
Some change had been inevitable because of the move to a single-apex 
menu tree, but I tried to hold that to a minimum.

But I have reached a point where the configurator codebase is stable
and works as a drop-in install on top of a stock kernel tree.  I'm
not even getting requests for UI tweaks any more.  So the CML2 engine is
essentially done (modulo the occasional minor bugfix).  

This made it time to start thinking about tuning the rulesfile to make
configuration easier.  At the same time, I was dealing with another
problem; missing entries in Configure.help.  When I got handed the 
maintainer's baton, there were 547 of these.  I have written outright 
over 300 new ones; Steven Cole and I have collected another 50 or so.

To reduce the problem further, I looked for symbols with missing
entries that I could turn into derivations, eliminating their
questions and the requirement for a help entry.  (A CML2 derivation is
like a CML1 define; it's a formula that sets a symbol from the value
of other symbols without user input.)

The first candidates I found were questions associated with built-in
SCSI and Ethernet on Macintoshes, on the Sun 3 and Sun3x, and with
built-in facilities on the MVME147 single-board computer.  So I wrote
derivations that looked like this:

# These were separate questions in CML1.  They enable on-board peripheral
# controllers in single-board computers.
derive MVME147_NET from MVME147 & NET_ETHERNET
derive MVME147_SCC from MVME147 & SERIAL
derive MVME147_SCSI from MVME147 & SCSI
derive MVME16x_NET from MVME16x & NET_ETHERNET
derive MVME16x_SCC from MVME16x & SERIAL
derive MVME16x_SCSI from MVME16x & SCSI
derive BVME6000_NET from BVME6000 & NET_ETHERNET
derive BVME6000_SCC from BVME6000 & SERIAL
derive BVME6000_SCSI from BVME6000 & SCSI

# These were separate questions in CML1
derive MAC_SCC from MAC & SERIAL
derive MAC_SCSI from MAC & SCSI
derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI

By doing this I killed two birds with one stone -- got rid of some holes
in Configure.help and (more importantly) moved the configuration experience
away from low-level, hardware-oriented questions towards where I think it
ought to be. That is, you specify a platform and the services you want and
the ruleset computes the low-level facilities to be linked in.

This represented a change in the design philosophy of the ruleset, not
something I wanted to do without input from the developers and port 
managers.  So I broadcast "CML2 design philosophy heads up".

After some back-and-forthing about the technical facts, several things
emerged:

1. The Mac derivations were half-right.  The MAC_SCC one is good but Macs 
can have either of two different SCSI controllers.  I fixed that with help
from Ray Knight, who maintains the 68K Mac port.

2. Nobody had a problem with the SUN3_SCSI derivation.

3. The MVME derivations are correct *if* (and only if) you agree to ignore
the possibility that somebody could want to ignore the onboard hardware,
plug outboard disk or Ethernet cards into the VME-bus connector, and
do something like running SCSI-over-ATAPI to the outboard device.
(I missed these possibilities when I wrote the derivations.)

I used case 3 to explore a touchy question about design philosophy, which
is really what caused all hell to break loose.  The question is this:
holding down configuration complexity is a good thing, but supporting
all hardware configurations that are conceivably possible is also a good 
thing.  How should we trade these good things off against one another?

The MVME situation is an almost perfect test case, because while
breaking the assumption behind that derivation is physically possible
it would be a rather perverse thing to do.  The VME147 is an old
design, dating from 1988; it's long since been superseded by MPCxxx
SBCs based on the PowerPC that have a better processor, lower power
consumption, and more on-board peripheral hardware.  IDE/ATAPI didn't
exist during most of its design lifetime, and the only way anyone is
ever going to hook an outboard device to one of these puppies again
is if some hacker pulls a dusty one off a shelf for some garage project.

So the real question here is whether it is ever acceptable to say that
a possible configuration is just silly and ruleset will ignore it, in
order to hold down ruleset complexity and simplify the user
experience.  The cost of deciding that the answer to that question is
"yes, sometimes" is that on rare occasions like this one you might
have to haul out a text editor to tweak something in your config.  But
the cost of deciding that the answer is "no" will be some pretty
serious complexity headaches both in the configuration user experience
and (down the road) in the maintainability of the ruleset.

So far, I have to say I'm disappointed in the quality of the debate.
Almoist nobody seems to want to think about this tradeoff globally, as a
systems design issue.  Instead, I'm hearing a lot of reflexive
chuntering that we have to do things a certain way because we've
always done them a certain way, and who am I to even dare *think*
about raising different possibilities?  
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93

Re: Background to the argument about CML2 design philosophy

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> The first candidates I found were questions associated with
Eric> built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and
Eric> Sun3x, and with built-in facilities on the MVME147 single-board
Eric> computer.  So I wrote derivations that looked like this:

[snip derive rules]

Eric> # These were separate questions in CML1 derive MAC_SCC from MAC
Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from
Eric> (SUN3 | SUN3X) & SCSI

Eric> By doing this I killed two birds with one stone -- got rid of
Eric> some holes in Configure.help and (more importantly) moved the
Eric> configuration experience away from low-level, hardware-oriented
Eric> questions towards where I think it ought to be. That is, you
Eric> specify a platform and the services you want and the ruleset
Eric> computes the low-level facilities to be linked in.

And you suddenly imposed decisions on people.

Wether or not you are an expert it is reasonable to expect that you
want to use modules just as it is just as reasonable to expect that
you do not. In some cases you want your Ethernet as a module in some
case you want the low level SCSI driver but not the SCSI mid
layer.

Eric> After some back-and-forthing about the technical facts, several
Eric> things emerged:

Eric> 1. The Mac derivations were half-right.  The MAC_SCC one is good
Eric> but Macs can have either of two different SCSI controllers.  I
Eric> fixed that with help from Ray Knight, who maintains the 68K Mac
Eric> port.

Eric> 2. Nobody had a problem with the SUN3_SCSI derivation.

Did you ever get an ACK on it or no answer?

Eric> 3. The MVME derivations are correct *if* (and only if) you agree
Eric> to ignore the possibility that somebody could want to ignore the
Eric> onboard hardware, plug outboard disk or Ethernet cards into the
Eric> VME-bus connector, and do something like running SCSI-over-ATAPI
Eric> to the outboard device.  (I missed these possibilities when I
Eric> wrote the derivations.)

Or wants to use modules. And yes Aunt Tillie might want to do so, if
the person who sold her her Linux CD provided a bunch of scripts for
packing up things in a specific way.

Eric> The MVME situation is an almost perfect test case, because while
Eric> breaking the assumption behind that derivation is physically
Eric> possible it would be a rather perverse thing to do.  The VME147
Eric> is an old design, dating from 1988; it's long since been
Eric> superseded by MPCxxx SBCs based on the PowerPC that have a
Eric> better processor, lower power consumption, and more on-board
Eric> peripheral hardware.  IDE/ATAPI didn't exist during most of its
Eric> design lifetime, and the only way anyone is ever going to hook
Eric> an outboard device to one of these puppies again is if some
Eric> hacker pulls a dusty one off a shelf for some garage project.

Bzzzzt wrong. The MVME cards are still heavily used in control systems
and similar places. It's the only place where m68k usage is not dying
for real.

Eric> So far, I have to say I'm disappointed in the quality of the
Eric> debate.  Almoist nobody seems to want to think about this
Eric> tradeoff globally, as a systems design issue.  Instead, I'm
Eric> hearing a lot of reflexive chuntering that we have to do things
Eric> a certain way because we've always done them a certain way, and
Eric> who am I to even dare *think* about raising different
Eric> possibilities?

So far the introduction of CML2 has been overly disppointing, from day
one it's been 'I have this great idea and since I think it's great,
you obviously have to think so as well'.

Now I take it the derived rules are still only enforced under the
'novice' option, though you haven't exactly made that clear in the
discussion (nor did you do so when you initially brought it up).

Jes

Re: Background to the argument about CML2 design philosophy

[Helge Hafting]

"Eric S. Raymond" wrote:

> 
> To reduce the problem further, I looked for symbols with missing
> entries that I could turn into derivations, eliminating their
> questions and the requirement for a help entry.  

Adding help entries is nice.  But please don't go around
making "unlikely" choices unconditional in order to avoid writing
help text.  Leaving the help blank for such questions
is better than eliminating the question.

[...]
> By doing this I killed two birds with one stone -- got rid of some holes
> in Configure.help and (more importantly) moved the configuration experience
> away from low-level, hardware-oriented questions towards where I think it
> ought to be. That is, you specify a platform and the services you want and
> the ruleset computes the low-level facilities to be linked in.
> 

> 3. The MVME derivations are correct *if* (and only if) you agree to ignore
> the possibility that somebody could want to ignore the onboard hardware,
> plug outboard disk or Ethernet cards into the VME-bus connector, and
> do something like running SCSI-over-ATAPI to the outboard device.
> (I missed these possibilities when I wrote the derivations.)
> 
> I used case 3 to explore a touchy question about design philosophy, which
> is really what caused all hell to break loose.  The question is this:
> holding down configuration complexity is a good thing, but supporting
> all hardware configurations that are conceivably possible is also a good
> thing.  How should we trade these good things off against one another?

I'd say support all possible configurations that is supposed to work.  
You never know what someone might want to make out of 
spare parts and dusty old things.  

Particularly, not compiling (or modularizing) the driver for a built-in 
device is always a valid way of saving memory.  I don't compile IDE on
my
home pc, because all my devices are scsi.  And the built-in floppy
controller is modularized because it is so rarely used.  Why give
it permanent unswappable memory?

Your trade-off considerations should be wether "odd but possible"
choices
belong in an EXPERT category or if they should be there for everybody.
Don't consider eliminating something that would work.  Of course you
don't have to worry too much about help texts for the expert stuff - let
the experts add that themselves if you don't want to write for
fringe cases.

> The MVME situation is an almost perfect test case, because while
> breaking the assumption behind that derivation is physically possible
> it would be a rather perverse thing to do.  The VME147 is an old
> design, dating from 1988; it's long since been superseded by MPCxxx
> SBCs based on the PowerPC that have a better processor, lower power
> consumption, and more on-board peripheral hardware.  IDE/ATAPI didn't
> exist during most of its design lifetime, and the only way anyone is
> ever going to hook an outboard device to one of these puppies again
> is if some hacker pulls a dusty one off a shelf for some garage project.

Hackers get things like this for free when companies get rid of them, 
then turns them into mp3 players or hobby device controllers.

> So the real question here is whether it is ever acceptable to say that
> a possible configuration is just silly and ruleset will ignore it, in
Maybe it is acceptable to say something is too silly.  You have to
come up with a better example though.  People may definitely want to 
not have a driver, or make a module instead of compiled-in.

And they may want to not use the built-in device because they
use something better.  Like a fast ethernet connected to 
that old vme box because the net they connect to
is fast even though the box may be too weak to really
take advantage of it.  Or wide scsi instead of the built-in thing.

> order to hold down ruleset complexity and simplify the user
> experience.  The cost of deciding that the answer to that question is

The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS 
option, and perhaps a HACKER option for the really strange 
but _theoretically_ ok stuff.

> "yes, sometimes" is that on rare occasions like this one you might
> have to haul out a text editor to tweak something in your config.  But
> the cost of deciding that the answer is "no" will be some pretty
> serious complexity headaches both in the configuration user experience
> and (down the road) in the maintainability of the ruleset.

If EXPERT options makes it too complex, consider having some rules
that are advisory only.  The debian packaging system has 
both absolute dependancies, and "suggestions".
Consider:
suggest MVME16x_SCC from MVME16x & SERIAL
which means that someone who turns on MVME16x_SCC and SERIAL
get MVME16x_SCC turned on when they do so.  
But the choice is visible and
it is possible for the user to turn it off at will.  Maybe shown in 
a different color or with some other hint that it is a defaulted
but overrideable thing.

Configuration gets simple for the vast amount of common cases,
but experts can do whatever they want.  
You could even have a user-interface option for not showing
such defaulted options.  That wouldn't complicate the rulebase,
it would be a UI-thing only.

Now you get both the simple rulebase and the nice user interface.
And satisfied experts.

Helge Hafting

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

>> order to hold down ruleset complexity and simplify the user
>> experience.  The cost of deciding that the answer to that question is
>
>The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS
>option, and perhaps a HACKER option for the really strange
>but _theoretically_ ok stuff.

Having now briefly looked at the language constructs first-hand, I can see
two ways to go about this:

1) Have a HACKER symbol which unsuppresses the "unusual" options, and
suppresses the "generalised" ones (like: "build all the sound drivers for
my hardware, as modules").  This is kinda how it would be implemented in
CML1, cf. EXPERIMENTAL.

2) Have a HACKERS submenu system which contains all the derivations that
could *possibly* be un-defaulted, and allow our intrepid hacker to
explicitly force each to a value or leave unset.  Leaving unset means the
derivation holds, forcing it to a value will explicitly enable or disable
the option along with any hard dependencies.  Head this submenu system with
a big banner that says "FOR EXPERTS ONLY", or suppress it using an
"Experts" switch.

Is there already a language construct to support the difference between a
"derivation" and a "dependency"?  Yes, it's the difference between "unless
FOO==n default BAR==y" and "require FOO!=n implies BAR==y" respectively (or
something to that effect, if my syntax is wrong flame gently please!).
With that in mind, the front-end UI could implement Option 2 easily, by
presenting a mode which automatically collects defaulted but otherwise
hidden symbols, and reveals them to the user when set to "hacker" mode.

I'm going to assume for now that CML2 saves two files - one storing a
relatively small number of symbols (which is strictly limited to those
explicitly set by the user), and one containing the full set for
consumption by the Makefiles.  If this is the case, then if a "hacker" type
switches something explicitly then it'll stay there even if the default
changes for that option in a future kernel.  Meanwhile, Aunt Tillie gets
the changed default option applied with no extra effort.  "make oldconfig"
might as well be a thing of the past for certain purposes, although it
should still be kept as a way of reminding people what the new options are.

Incidentally, in this scenario, if we have "enable driver for device FOOBAR
[NEW] [y/m/N]:" then pressing Return should *not* mark the symbol as
"explicitly set" but left alone because "user accepted the default".  If
they pressed "N", then that has the same effect but is saved explicitly for
future kernels, regardless of any defaults change for that option.

Hope this makes sense and I'm not being a stark raving loonie...

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 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+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Jonathan Morton <chromi@cyberspace.org>:
> I'm going to assume for now that CML2 saves two files - one storing a
> relatively small number of symbols (which is strictly limited to those
> explicitly set by the user), and one containing the full set for
> consumption by the Makefiles.

No, that's not the case.  Would it be too much to ask that you learn how
the existing language works brfore proposing improvements?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
	-- Albert Einstein, "My First Impression of the U.S.A.", 1921

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

chromi@cyberspace.org said:
>  Having now briefly looked at the language constructs first-hand, I
> can see two ways to go about this:

> 1) Have a HACKER symbol which unsuppresses the "unusual" options, and
> suppresses the "generalised" ones 

> 2) Have a HACKERS submenu system which contains all the derivations
> that could *possibly* be un-defaulted, and allow our intrepid hacker
> to explicitly force each to a value or leave unset.

I prefer the former, which is how it's already implemented in CML1.

But the discussion of this is entirely unrelated to the discussion of CML2, 
and changes along these lines must not be forced into the kernel with the 
CML2 patch.

If ESR is going to sneak policy changes into the kernel with the CML2 
mechanism patch, I'm sure we all have patches we'd like him to add to it 
too, because we don't want to have to justify them on their own. :)

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Alan Cox]

> > 2) Have a HACKERS submenu system which contains all the derivations
> > that could *possibly* be un-defaulted, and allow our intrepid hacker
> > to explicitly force each to a value or leave unset.
> 
> I prefer the former, which is how it's already implemented in CML1.

Its called Debugging in CML1 in -ac for a reason btw. Because its called 
debugging I get plenty of reports that start

"I dont know much about this but I turned on all the debugging options and now
 instead of hanging it says Oops 0xA5A5A5A5 ..."

which are a lot more useful. 

Names matter a lot 

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

>> > 2) Have a HACKERS submenu system which contains all the derivations
>> > that could *possibly* be un-defaulted, and allow our intrepid hacker
>> > to explicitly force each to a value or leave unset.
>>
>> I prefer the former, which is how it's already implemented in CML1.
>
>Its called Debugging in CML1 in -ac for a reason btw. Because its called
>debugging I get plenty of reports that start

I think "Debugging" and "HACKERS" go in separate categories.  "Debugging"
is for pinpointing problems in the *same* configuration, "HACKERS" is for
making *different* configurations.

Not that I really care what it's called, provided the concept gets thought
about.  If I select MAC68K and SCSI, it's perfectly reasonable for the two
"standard" SCSI drivers to be compiled-in for most people.  But if I run
into a PowerBook 190 or Quadra 840av (which, if I'm not much mistaken,
don't use the standard chipsets - and I happen to have access to both of
them), I might want to turn them off and turn on my own hacked-up driver.
Or I might want to turn off the one I'm not using, to save space on that
old spare 4Mb Classic II.

And in fact this is a non-issue at present - the SCSI rulesfile has "unless
MAC suppress MAC_SCSI SCSI_MAC_ESP" and NOTHING which forces MAC_SCSI and
SCS_MAC_ESP to "on" if I'm running a Mac.  As far as I can tell, both would
default to "off", and are merely hidden if I happen not to be running such
a machine.

For the moment, I'll be happy if the rulesfile remains similar in function
to CML1 but with the added intelligence CML2 brings with it by default.  If
in the future someone wants to add "Aunt Tillie" features, then sensible
defaults can easily be added and over-ridden.  I think I'd like CML2 to
remember which options are explicitly set and which ones I left alone (if
it doesn't do so already) - that will go a long way towards helping Aunt
Tillie in the long run.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 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+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

Thankyou for the clarification.

esr@thyrsus.com said:
>  I used case 3 to explore a touchy question about design philosophy,
> which is really what caused all hell to break loose.  The question is
> this: holding down configuration complexity is a good thing, but
> supporting all hardware configurations that are conceivably possible
> is also a good  thing.  How should we trade these good things off
> against one another? 

I think you already have the mechanism required to answer this - in NOVICE 
mode you disallow the strange choices, in EXPERT mode you allow them.

Embedded boards are a special case in this respect - people add all manner
of strange crap to the reference designs - believe me, I've seen the ways in
which they can fuck it up and yet still they manage to amaze me sometimes.

And because of the multitude of ways in which the monkeys who glue together
these boards can fuck it up, often you really really want to ignore the
on-board Ethernet, for example, and use the PCMCIA card you plugged in,
because they actually managed to route the PCMCIA interrupt to an IRQ line,
not a GPIO pin.


esr@thyrsus.com said:
> So the real question here is whether it is ever acceptable to say that
> a possible configuration is just silly and ruleset will ignore it, in
> order to hold down ruleset complexity and simplify the user
> experience.  The cost of deciding that the answer to that question is
> "yes, sometimes" is that on rare occasions like this one you might
> have to haul out a text editor to tweak something in your config.

As I said earlier, there are two main cases which should be considered
entirely separately. There are the cases which are insane, and which won't
ever work, or probably even compile. Those should be hard-coded off in the 
ruleset and it should not be possible to enable them without hacking.

For the cases where we just want to make life simpler for the users, the 
constraints should be dependent on the user mode. In NOVICE mode you hide 
them, in EXPERT mode you make them available.



The current (CML1) solution has problems, and it only provides real support 
for a small range of people at the hacker end of the spectrum.

Making CML2 useful for a far wider range of people is a laudable goal. But
please take care to ensure that the set of people for whom CML2 is useful is
a strict superset of those for whom CML1 was useful.

In particular, please don't strive to make Aunt Tillie happy on the one
occasion on which she configures her kernel at a cost of rendering CML2 less
useful for those for whom kernel configuration is an every-day task. Once 
weighted appropriately, that tradeoff is particularly easy to decide upon.

If you ever find yourself seriously suggesting that a developer would need
to ditch CML2 and hack the config files directly in order to compile support
for, for example, the DiskOnChip he just dropped into the DIL socket in his
Ethernet card, then I would suggest that you have made a wrong choice
somewhere down the road. Please backtrack and reconsider an earlier decision
before you're eaten by a grue.

We already have a distinction between config options which it's sensible to 
ask the user, and options for which you have to hack #defines in the source 
code. The options which I have put into drivers/mtd/Config.in are there 
because I _wanted_ the user to see them. The options which are hidden in 
the code are there because I made the opposite decision.

There is a reasonably well-defined boundary for such things already, and
it's found all over the kernel. Adding a new, higher boundary for Aunt
Tillie is just fine - but please don't _move_ the existing one that most of
us care about.

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> I think you already have the mechanism required to answer this - in NOVICE 
> mode you disallow the strange choices, in EXPERT mode you allow them.

That pushes the third button.  I'm nervous that if we go down this path
we will end up with a thicket of modes and a combinatorial explosion
in ruleset complexity, leading immediately to a user configuration
experience that is more complex than necessary, and eventually to an
unmaintainable mess in the rulesfiles.

In order to prevent that happening, I would like to have some recognized
criterion for configuration cases that are so perverse that it is a 
net loss to accept the additional complexity of handling them within the
configurator.

A lot of people (including, apparently, you) are saying there are no such
cases.  I wonder if you'll change your minds when you have to handle the
overhead yourselves?

Sigh...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Government is not reason, it is not eloquence, it is force; like fire, a
troublesome servant and a fearful master. Never for a moment should it be left
to irresponsible action."
	-- George Washington, in a speech of January 7, 1790

Re: Background to the argument about CML2 design philosophy

[Arjan van de Ven]

On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote:
> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a 
> net loss to accept the additional complexity of handling them within the
> configurator.

"It doesn't compile/link" would be a good one. "It requires subsystem FOO to
operate" is another (think about IDE DMA drivers and the IDE subsystem, or
NIC drivers vs CONFIG_NET)
 
> A lot of people (including, apparently, you) are saying there are no such
> cases.  I wonder if you'll change your minds when you have to handle the
> overhead yourselves?

Somehow the current overhead isn't that high. You might argue that the
current Config.in is broken given my definition. That is fixable with a day
of work; I've been doing so on a regular basis with the tooling I wrote for
automatic testing of this.

Maybe it would be possible to separate "hard" dependencies like the current
system has with the "soft" ones one needs for entry-level configtools. Or
maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones
and the newstyle info.


I liked the suggestion where the "automatic" derivations got turned into
manual ones for expert mode... 

I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my
Debian Potato playbox) so I don't know if that is actually possible, or that
it requires some redesign.

Greetings,
  Arjan van de Ven

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

arjanv@redhat.com said:
> Maybe it would be possible to separate "hard" dependencies like the
> current system has with the "soft" ones one needs for entry-level
> configtools.

Actually, the current system has both types. As well as the "hard" 
dependencies, we also have stuff like CONFIG_PARTITION_ADVANCED, 
CONFIG_CPU_ADVANCED, CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, 
etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too.

These things have already been set up in the way that developers prefer it. 

CML2 allows us to be more flexible than we were before, and that can be a
good thing when used in moderation. But please, for the sake of the sanity
of all concerned, do things one at a time. Provide for merging into 2.5 a set 
of rules which reproduce the existing CML1 behaviour in this respect. 

Eric, if you want to make further changes later to introduce new 'modes' for
kernel configuration, that's an entirely separate issue. Please don't
confuse the issue by trying to do it at the same time as introducing CML2.

CONFIG_AUNT_TILLIE does not require CML2.
CML2 does not require CONFIG_AUNT_TILLIE.

Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing
behaviour of config options to make that the default, until we've settled
the discussion about CML2.

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing
> behaviour of config options to make that the default, until we've settled
> the discussion about CML2.

What discussion is that?  Unless Linus has changed his mind and I don't 
know about it, CML2 is going in between 2.5.1 and 2.5.2.  The engine is
working.  Why is it not yet time to discuss ruleset design and modes?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

That the said Constitution shall never be construed to authorize
Congress to infringe the just liberty of the press or the rights of
conscience; or to prevent the people of the United states who are
peaceable citizens from keeping their own arms...
        -- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

esr@thyrsus.com said:
>  What discussion is that?  Unless Linus has changed his mind and I
> don't  know about it, CML2 is going in between 2.5.1 and 2.5.2. 

Because it is evidently confusing the issue. Perhaps because it sounds like 
you were intending to feed Linus large patches for 2.5.[12] which effect 
_both_ changes.

Have patience - let the less contentious part of CML2 go in first, and then
we can deal with the other stuff later, once CML2 has been accepted (however
grudgingly in some cases) by developers.

> The engine is working.  Why is it not yet time to discuss ruleset design
> and modes?

For a man who claims to hack social systems, that's an incredibly naïve 
question.

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> Because it is evidently confusing the issue. Perhaps because it sounds like 
> you were intending to feed Linus large patches for 2.5.[12] which effect 
> _both_ changes.

I'm going to give Linus the same installation kit the people working with CML2
have now.  That will include both the CML2 engine and the rulesfiles.
 
> Have patience - let the less contentious part of CML2 go in first, and then
> we can deal with the other stuff later, once CML2 has been accepted (however
> grudgingly in some cases) by developers.

I don't think there is a "less contentious" part.  The same people who bitched
about the engine are now bitching about the changes I'm contemplating in the
rulesfiles.  It seems clear to me that their attitude, in general, has little
to do with technical specifics of the engine or rulesets and everything to
do with resistance to change in general and fear of losing control and/or
hard-won implicit knowledge about the old system.

I can sympathize with their upset, but I don't intend to let it stop
me.  And since I'm going to have these people angry at me unless I
give up entirely, I figure I have little to lose by steaming ahead full.

> > The engine is working.  Why is it not yet time to discuss ruleset design
> > and modes?
> 
> For a man who claims to hack social systems, that's an incredibly naïve 
> question.

You think so, eh?  Heh.  Experience has taught me that sometimes
hacking social systems requires a certain amount of sheer
bloodymindedness.

See, I've already written off the chronic bellyachers.  Since I can't
please them without scrapping the whole plan, I'm going to ignore
them.  In particular, anybody who repeated "fsck Python..." after Linus
ruled that Python is not an issue and Greg Banks announced the C
implementation of CML2 has got a sufficiently severe case of
rectocranial insertion that they've defined themselves out of the
conversation.

Instead I'll take my cues from people like you and Ray Knight and Tom
Rini and Alan Cox and Martin Schwidefsky who are actually offering
help and constructive criticism.  (Arjan de Ven is trying but he's not
up to speed on the language yet.)  I trust you've noticed by now that
I *do* listen very carefully in that situation, and I follow up with
questions when I'm not sure what people are trying to tell me.  I'll
keep doing that.

Eventually the bellyachers may get a message about what kind of behavior
gains them influence and what kind loses them influence.  That's a
social-systems hack of a sort ;-).
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

I don't like the idea that the police department seems bent on keeping
a pool of unarmed victims available for the predations of the criminal
class.
         -- David Mohler, 1989, on being denied a carry permit in NYC

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

esr@thyrsus.com said:
> I don't think there is a "less contentious" part.  The same people who
> bitched about the engine are now bitching about the changes I'm
> contemplating in the rulesfiles.  It seems clear to me that their
> attitude, in general, has little to do with technical specifics of the
> engine or rulesets and everything to do with resistance to change in
> general and fear of losing control and/or hard-won implicit knowledge
> about the old system.

No. I didn't bitch (much) about CML2 - I'm fairly ambivalent. But I
absolutely object to _unconditionally_ dumbing down the config options, 
because it would hide options which I would frequently want to enable.

Introduce new novice modes if you wish - that seems sensible - but do not
reduce the functionality and flexibility of configuration which is currently
available. Any simplifications you make _must_ be dependent on the novice 
mode, and the default mode should allow the same choices as the current 
rules.

More importantly, do not attempt to force through this change in policy by
sneaking it into the 2.5.1 CML2 patch which introduces the new mechanism. 
The two are entirely orthogonal, and should remain separate.

esr@thyrsus.com said:
>  I'm going to give Linus the same installation kit the people working
> with CML2 have now.  That will include both the CML2 engine and the
> rulesfiles.

Fine. What I'm asking is that you ensure that the CML2 rulesfiles at the
time of the merge implement the dependencies present in the CML1 rulesfiles
immediately prior to the merge.

If you want to work on the change of policy right now, before CML2 is
merged, then go ahead and do it in CML1. It's not difficult. The first step
is to make CONFIG_*_ADVANCED depend on CONFIG_EXPERT, for example. Then get
those changes merged into 2.5 before you merge CML2 - and you still keep the
CML2 after the merge equivalent to the CML1 immediately before the merge.

Otherwise, have patience and do it after CML2 is merged.

All I'm asking is that you refrain from confusing the change in mechanism 
with the change in policy. That's not an unreasonable request, now is it?

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

stoffel@casc.com said:
> David> for the sake of the sanity of all concerned, do things one at a
> David> time. Provide for merging into 2.5 a set of rules which 
> David> reproduce the existing CML1 behaviour in this respect.

> Can you define what you mean here?  It's not really clear to me, and I
> suspect others.  

You appear to be responding to my email, yet you did not do me the courtesy 
of including me in the recipients. Should I assume you're asking this 
question of me directly, or was it a rhetorical question?

stoffel@casc.com said:
> I don't think he is introducing new modes, he's just trying to make
> sure that you can't create a .config which is broken. 

Good. You should be prevented from creating a .config which is broken, and 
the existing CML1 rules attempt to achieve this. CML2 should continue to do 
so, and indeed should do so more effectively and flexibly.

> - fear that CML2 won't let them make crazy configurations, such as an
>   8-way SMP box with ISA.  Can't see how CML2 would restrict this
>   choice myself.

I do not fear that CML2 itself will prevent these 'crazy' configurations.
That is why I said that the issue is entirely orthogonal to CML2.

However, it would obviously be possible to introduce new dependencies to the
rules files -- either CML1 or CML2 -- which do prevent such configurations.

What I fear is that such new, unwanted, dependencies may be introduced to
the kernel -- either by accident or by deception -- in the large patch which
introduces CML2 and converts the existing rules files. Subtle changes to 
the behaviour could easily go unnoticed in such a large patch.

I am asking that such a deception should not be attempted. The CML2 rules
introduced to 2.5.n should exactly represent the behaviour of the CML1 rules
in 2.5.(n-1). Changes to the policy represented within the rules files can
then be presented afterwards, and should be considered entirely separate to
the change in mechanism.

stoffel@casc.com said:
> If you run into a case where you have a config which would work, but
> CML2 doesn't let you, why don't you fix the grammar instead of saying
> CML2 is wrong? 

I think you are being overly defensive. I was not saying that CML2 is 
wrong. I said that I was ambivalent about CML2, and the point I'm talking 
about is entirely irrelevant to CML2 - except that I'm trying to make sure 
that the large CML2 patch is not used as a vehicle for sneaking other, more 
contentious, changes into the kernel. 

I want to discuss those changes _separately_ once the CML2 issue is
out of the way, because otherwise people just won't bother to read what I
said, and will assume I'm arguing against CML2 itself.

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

stoffel@casc.com said:
>  I don't agree with this, since the current CML1 scheme has wierd,
> unwanted and wrong dependencies already, which can't (or haven't) been
> found.   Since it would be put in during the 2.5.x branching, it's
> expected that things will/can/should break, so I don't think there
> will be any dire consequences.  

OK, I obviously don't expect the behaviour to be _exactly_ identical. If 
CML2 allows the authors' intent to be more closely adhered to, that's a good 
thing. But if the CML2 files exhibit behaviour which was clearly _not_ the 
intention of the original CML1, that is a change which should be made under 
separate cover.

> Such as what?  Do you have any examples here?  

The MAC/SCSI dependencies, which it seems were 'simplified' at the cost of
preventing certain combinations which were unlikely but valid, and which it
was possible to select with the original rules.

Also of course the whole class of dependencies which people are talking 
about introducing for the benefit of the hypothetical Aunt Tillie.

I don't know how many, if any, of this kind of changes are _actually_ made
in the current CML2 rules files - what I'm saying is that there _should_ be
none. Such large changes to the policy are entirely unrelated to CML2 
itself, and should be discussed separately. 

If your response to this is "But there are no such changes, you
misunderstood the MAC/SCSI dependency conversation and the Aunt Tillie stuff
was all hypothetical, what are you talking about?", then good - that's
precisely the answer I was after.

All I'm asking for is a clear agreement that within reason, the behaviour 
of the CML2 rules files immediately after CML2 is merged will match the 
intended behaviour of the CML1 rules prior to the merge.

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[John Stoffel]

David> You appear to be responding to my email, yet you did not do me
David> the courtesy of including me in the recipients. Should I assume
David> you're asking this question of me directly, or was it a
David> rhetorical question?

It was more of an attempt to cutdown on the number of recipients, not
any attempt to keep you out of the discussion.  This time, I've left
the recipients alone.

David> Good. You should be prevented from creating a .config which is
David> broken, and the existing CML1 rules attempt to achieve
David> this. 

We are in agreement here, though I doubt that the CML1 ruleset really
achieves this goal in any serious way.  It just doesn't have the power.

David> CML2 should continue to do so, and indeed should do so more
David> effectively and flexibly.

Agreed.

David> What I fear is that such new, unwanted, dependencies may be
David> introduced to the kernel -- either by accident or by deception
David> -- in the large patch which introduces CML2 and converts the
David> existing rules files. Subtle changes to the behaviour could
David> easily go unnoticed in such a large patch.

I don't agree with this, since the current CML1 scheme has wierd,
unwanted and wrong dependencies already, which can't (or haven't) been
found.   Since it would be put in during the 2.5.x branching, it's
expected that things will/can/should break, so I don't think there
will be any dire consequences.  

David> I think you are being overly defensive. I was not saying that
David> CML2 is wrong. I said that I was ambivalent about CML2, and the
David> point I'm talking about is entirely irrelevant to CML2 - except
David> that I'm trying to make sure that the large CML2 patch is not
David> used as a vehicle for sneaking other, more contentious, changes
David> into the kernel.

Such as what?  Do you have any examples here?  

David> I want to discuss those changes _separately_ once the CML2
David> issue is out of the way, because otherwise people just won't
David> bother to read what I said, and will assume I'm arguing against
David> CML2 itself.

This is the first time you have come out and explicitly *said* what
you are for and against in CML2.  People need to be clear about what
they are talking about.

As a general question for all readers, how many are against CML2 in
any shape or form?

How many are like David, and don't mind CML2, but are worried about
dependency issues?

How many think CML2 and it's dependencies will be a step forward in
kernel configuration?

Thanks,
John

Re: Background to the argument about CML2 design philosophy

[Nicolas Pitre]

On Sun, 20 May 2001, Eric S. Raymond wrote:

> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a
> net loss to accept the additional complexity of handling them within the
> configurator.

Simple:  That extreme perversion represent a kernel that wouldn't compile.
You can't have NFS support if you didn't select networking support, etc.
Such is the recognized basics.

Next, you can ask the question if you would have to modify the ruleset to
add a new driver to be able to use a feature.  Exemple: will you need to
write a new driver for a special IDE interface card and add it in the
ruleset before you could use IDE cdrom support on the MVME147 SBC?  If you
have to edit it anyway then it shouldn't be much pain to remove the
unconditionnal removal of IDE support for that target.

For all other combinations where a slight possibility might make you doubt
then the choice should remain at least in expert mode.

People might also want to remove support for subsystems on a specific target
even if the device comes soldered on it, just because they won't use it
anyway and they want to optimize their kernel size for better memory usage.

IMHO your design goal now is mainly about finding a way to describe rule
derivation related to the selected expertise mode, and only enforce the
strictly impossible combinations for expert mode, just like CML1 is doing
while removing obvious derivations for novice users.

Now you protest with:

> That pushes the third button.  I'm nervous that if we go down this path
> we will end up with a thicket of modes and a combinatorial explosion
> in ruleset complexity, leading immediately to a user configuration
> experience that is more complex than necessary, and eventually to an
> unmaintainable mess in the rulesfiles.

Eric: with this I think you know what everybody here is wishing for, and you
just perfectly stated your design constraint in achieving it.  You can't
avoid the "all semi-possible combination allowed" mode.  So let's switch to
the implementation discussion instead.


Nicolas

Re: Background to the argument about CML2 design philosophy

[John Stoffel]

David> Actually, the current system has both types. As well as the
David> "hard" dependencies, we also have stuff like
David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED,
David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED,
David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too.

David> These things have already been set up in the way that
David> developers prefer it.

     *some* developers prefer it.  Not all. 

David> CML2 allows us to be more flexible than we were before, and
David> that can be a good thing when used in moderation. But please,
David> for the sake of the sanity of all concerned, do things one at a
David> time. Provide for merging into 2.5 a set of rules which
David> reproduce the existing CML1 behaviour in this respect.

Can you define what you mean here?  It's not really clear to me, and I
suspect others.  

David> Eric, if you want to make further changes later to introduce
David> new 'modes' for kernel configuration, that's an entirely
David> separate issue. Please don't confuse the issue by trying to do
David> it at the same time as introducing CML2.

I don't think he is introducing new modes, he's just trying to make
sure that you can't create a .config which is broken.  Part of my
complaint early on was that it would just barf on a config it thought
wasn't legall, and just drop me to the 'vi' level.  I don't think this
is acceptable because you (CML2 or CMLxxxx) should be able to prompt
the user for a suggested fix.  

David> CONFIG_AUNT_TILLIE does not require CML2.

Correct.

David> CML2 does not require CONFIG_AUNT_TILLIE.

Correct.  And never has offered it either!

David> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the
David> existing behaviour of config options to make that the default,
David> until we've settled the discussion about CML2.

I think it comes down to people who just want one or more of:

- the existing interface of vi .config; make oldconfig

- fear that CML2 won't let them make crazy configurations, such as an
  8-way SMP box with ISA.  Can't see how CML2 would restrict this
  choice myself.

- Don't want to install python 2.x for a kernel upgrade.

- fear that some configuration corner case will be handled wrong for a
  strange (read not common) system config.  


All that CML2 does is enforce dependencies in the configuration
language.  You can't make a .config which conflicts.  Admittedly
there's nothing stopping you from hacking it with vi after the fact,
but why?

If you run into a case where you have a config which would work, but
CML2 doesn't let you, why don't you fix the grammar instead of saying
CML2 is wrong?  Let's not confuse these two issues as well.

John

Re: Background to the argument about CML2 design philosophy

[Keith Owens]

On Mon, 21 May 2001 16:38:34 -0400, 
John Stoffel <stoffel@casc.com> wrote:
>All that CML2 does is enforce dependencies in the configuration
>language.  You can't make a .config which conflicts.  Admittedly
>there's nothing stopping you from hacking it with vi after the fact,
>but why?

CML2 will not stop you hacking .config by hand.  But the 2.5 makefile
rewrite will, because we have had too many bug reports caused by people
who hand edited .config, did not revalidate it and generated invalid
kernels.  Yes, you can hand edit .config.  No, you cannot compile until
.config has been (re-)validated.

# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
        @echo Your .config is newer than include/linux/autoconf.h, this should not happen.
        @echo Always run make one of "{menu,old,x}config" after manually updating .config.
        @/bin/false

And before people complain: Don't create a config that violates the CML
rules, correct the CML rules, the Makefiles and the source so .config
is valid.  The kernel build requires a valid .config.

Re: Background to the argument about CML2 design philosophy

[Daniel Phillips]

On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>
> # Not a real dependency, this checks for hand editing of .config.
> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>         @echo Your .config is newer than include/linux/autoconf.h,
> this should not happen. @echo Always run make one of
> "{menu,old,x}config" after manually updating .config. @/bin/false

Ahem.  What is wrong with revalidating it automatically?  *Then* if there's a
problem, bother the user.

"No news is good news".

--
Daniel

Re: Background to the argument about CML2 design philosophy

[Keith Owens]

On Tue, 22 May 2001 11:24:54 +0200, 
Daniel Phillips <phillips@bonn-fries.net> wrote:
>On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>> # Not a real dependency, this checks for hand editing of .config.
>> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>>         @echo Your .config is newer than include/linux/autoconf.h,
>> this should not happen. @echo Always run make one of
>> "{menu,old,x}config" after manually updating .config. @/bin/false
>
>Ahem.  What is wrong with revalidating it automatically?  *Then* if there's a
>problem, bother the user.

Revalidate using which tool?  Did the user even mean to edit .config?
This is a case where the user has to decide what to do.

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

>If you run into a case where you have a config which would work, but
>CML2 doesn't let you, why don't you fix the grammar instead of saying
>CML2 is wrong?  Let's not confuse these two issues as well.

Strongly agree.  Especially since I'm pushing for an explicit recognition
of the difference between a hard dependancy and a soft derivation.  The
latter can be over-ridden safely by someone who knows what he's after.  The
former will cause a miscompile.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 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+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

esr@thyrsus.com said:
>  I'm nervous that if we go down this path we will end up with a
> thicket of modes and a combinatorial explosion in ruleset complexity,
> leading immediately to a user configuration experience that is more
> complex than necessary, and eventually to an unmaintainable mess in
> the rulesfiles.

Having too many such modes would be a horrible mess, I agree.

> In order to prevent that happening, I would like to have some
> recognized criterion for configuration cases that are so perverse that
> it is a  net loss to accept the additional complexity of handling them
> within the configurator.

> A lot of people (including, apparently, you) are saying there are no
> such cases.  I wonder if you'll change your minds when you have to
> handle the overhead yourselves? 

Of course there are such cases. The criterion is that the code does not 
compile or if it did, it could never be expected to work - like SCSI drivers
without SCSI generic, or PCI devices without CONFIG_PCI.

This is the major criterion which has defined the dependencies already in 
the config files.

You want to add a new mode which hides some of the more esoteric options. 
That's fine. So do so, and then we have two modes. It's still not an 
unmaintainable mess. 

If having even two modes is going to be too troublesome, then keep the one
we have. You can try to simplify it later by encouraging individual
maintainers to hide stuff behind CONFIG_*_ADVANCED options. But keep that
strictly separate from the CML2 discussion.

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Robert M. Love]

On 20 May 2001 16:47:00 -0400, Eric S. Raymond wrote:
> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a 
> net loss to accept the additional complexity of handling them within the
> configurator.
> 
> A lot of people (including, apparently, you) are saying there are no such
> cases.  I wonder if you'll change your minds when you have to handle the
> overhead yourselves?

I feel that there should *never ever* be a legit situation that the
configuration tool does not allow. Not ever. Two reasons:

First, I tend to trust the config tools (perhaps too much).  If they
tell me x implies y, or x implies not y, I will believe it.  I won't
think "hm, the code must be wrong, let me hand edit the config" (which
is something I don't want to have to do, anyhow).

Second, I like having a lean kernel.  Here is an example (I realize this
probably won't ever manifest into a real rule): INTEL_I815 implies
INTEL_RNG, DRM_I810, INTEL_AGP, I810_TCO, PCI, etc etc. -- I don't want
the RNG or TCO watchdog.  I don't use the on-board graphics.  Nor, if my
i815 model supported it, the sound.  There are people who want to
customize their kernel (hell, everyone at this level of the game).
There are people, like David, who have custom setups.  We need to
support this, without hacking the config (especially if I have to rehack
it after every make oldconfig!).

I like your design to abstract away low levels features to a more
general design.  This makes it easier for the novice, and more intuitive
for everyone.  But not at the expense of limiting possible cases.

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: Background to the argument about CML2 design philosophy

[Nicolas Pitre]

On 20 May 2001, Robert M. Love wrote:

> I feel that there should *never ever* be a legit situation that the
> configuration tool does not allow. Not ever. Two reasons:
>
> First, I tend to trust the config tools (perhaps too much).  If they
> tell me x implies y, or x implies not y, I will believe it.  I won't
> think "hm, the code must be wrong, let me hand edit the config" (which
> is something I don't want to have to do, anyhow).

Then just don't go as far as using it in "Expert (might be unsafe)" mode.
If you blindly trust the tool that much the intermediate mode might be what
you need.


Nicolas

Re: CML2 design philosophy heads-up

[Daniel Phillips]

On Friday 18 May 2001 17:11, Arjan van de Ven wrote:
> >    (a) Back off the capability approach.  That is, accept that
> >        people doing configuration are going to explicitly and
> >        exhaustively specify low-level hardware.
>
> <snip>
>
> > I don't want to do (a); it conflicts with my design objective of
> > simplifying configuration enough that Aunt Tillie can do it.  I
> > won't do that unless I see a strong consensus that it's the only
> > Right Thing.
>
> Aunt Tillie doesn't even know what a kernel is, nor does she want to.

A little presumptuous, no?  I do in fact know an 'Aunt Tillie' type who
configures her own kernel.  When she gets stuck she calls for help from
her son, who is a computer geek.

> I think it's fair to assume that people who configure and compile their own
> kernel (as opposed to using the distribution supplied ones) know what they
> are doing.

Not a fair assumption, if only because everybody does it for the first 
time.

> Or at least make something like a "Expert level" question as first question, so
> that people who DO know what they are doing can select the options they want.

Yes.  The hackneyed platitude that 'easy' and 'powerful' are mutually 
exclusive is a statistical observation, not a law of the universe.

--
Daniel

Re: CML2 design philosophy heads-up

[Alan Cox]

> 1. When we have a platform symbol for a reference design like MVME147, do 
>    we stick to its spec sheet or consider it representative of all derivatives
>    (which may have other facilities)?

At most it bounds the busses directly available. I've yet to see VME cardbus
adapters but its quite possible.

> I don't want to do (a); it conflicts with my design objective of
> simplifying configuration enough that Aunt Tillie can do it.  I won't 
> do that unless I see a strong consensus that it's the only Right Thing.

Its a good way of getting the defaults right. It may also be an appropriate
way of guiding presentation (eg putting the stuff the ruleset says you wont
have under a subcategory so you would see


		CPU type
		Devices
		blah
		blah
		Other Options
			IDE disk
			Cardbus

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > I don't want to do (a); it conflicts with my design objective of
> > simplifying configuration enough that Aunt Tillie can do it.  I won't 
> > do that unless I see a strong consensus that it's the only Right Thing.
> 
> Its a good way of getting the defaults right. It may also be an appropriate
> way of guiding presentation (eg putting the stuff the ruleset says you wont
> have under a subcategory so you would see
> 
> 
> 		CPU type
> 		Devices
> 		blah
> 		blah
> 		Other Options
> 			IDE disk
> 			Cardbus

I want to understand what you're driving at here and I don't get it.  What's
the referent of "Its"?  Are you saying you think Aunt Tillie's view of the
world should guide the presentation of options?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Are we at last brought to such a humiliating and debasing degradation,
that we cannot be trusted with arms for our own defence?  Where is the
difference between having our arms in our own possession and under our
own direction, and having them under the management of Congress?  If
our defence be the *real* object of having those arms, in whose hands
can they be trusted with more propriety, or equal safety to us, as in
our own hands?
        -- Patrick Henry, speech of June 9 1788

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > I don't want to do (a); it conflicts with my design objective of
> > > simplifying configuration enough that Aunt Tillie can do it.  I won't 
> > > do that unless I see a strong consensus that it's the only Right Thing.
> > 
> > Its a good way of getting the defaults right. It may also be an appropriate
> > way of guiding presentation (eg putting the stuff the ruleset says you wont
> > have under a subcategory so you would see
> > 
> > 
> > 		CPU type
> > 		Devices
> > 		blah
> > 		blah
> > 		Other Options
> > 			IDE disk
> > 			Cardbus
> 
> I want to understand what you're driving at here and I don't get it.  What's
> the referent of "Its"?  Are you saying you think Aunt Tillie's view of the
> world should guide the presentation of options?

Aunt Tillie shouldn't try to manually configure a kernel.

	Christoph

P.S. _please_ shorten your .sig
-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Michael Meissner]

On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> Aunt Tillie shouldn't try to manually configure a kernel.

Ummm, maybe Aunt Tillie wants to learn how to configure a kernel....  After
all, all of us at one point in time were newbies in terms of configuring
kernels, etc.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Arjan van de Ven]

Michael Meissner wrote:
> 
> On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > Aunt Tillie shouldn't try to manually configure a kernel.
> 
> Ummm, maybe Aunt Tillie wants to learn how to configure a kernel....  After
> all, all of us at one point in time were newbies in terms of configuring

And maybe she uses KDE and clicks kkernelconfigurator for the first
steps.
And if she wants to learn, she even might stumble on the HOWTO..

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Michael Meissner <meissner@spectacle-pond.org>:
> On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > Aunt Tillie shouldn't try to manually configure a kernel.
> 
> Ummm, maybe Aunt Tillie wants to learn how to configure a kernel....  After
> all, all of us at one point in time were newbies in terms of configuring
> kernels, etc.

And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
the one with the unicorn appliques and the pink scrunchies and the Back Street
Boys posters in her bedroom?

Dammit, if we're serious about empowering people with free software we can't
limit ourselves with the attitude that configuring kernels (or anything
else) is the sacred preserve of a geek elite.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The price of liberty is, always has been, and always will be blood.  The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty.  Are
you free? 
	-- Andrew Ford

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
> Michael Meissner <meissner@spectacle-pond.org>:
> > On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > > Aunt Tillie shouldn't try to manually configure a kernel.
> > 
> > Ummm, maybe Aunt Tillie wants to learn how to configure a kernel....  After
> > all, all of us at one point in time were newbies in terms of configuring
> > kernels, etc.
> 
> And if she doesn't, maybe her teenage daughter Muffy wants to learn.  You know,
> the one with the unicorn appliques and the pink scrunchies and the Back Street
> Boys posters in her bedroom?

That's ok as long as she doesn't add backstreet boys songtexts as long as your
signature to her mails.

On the other hand she should _really_ learn how to do it - like we all did.

> Dammit, if we're serious about empowering people with free software we can't
> limit ourselves with the attitude that configuring kernels (or anything
> else) is the sacred preserve of a geek elite.

I see _no_ reason to give up my control for people with an attitude that
configuring kernels will not need knowledge of what one is doing.

Your point is basically:

	Lets rewrite the kernel in VBA to make every word user
	capable of driver hacking.

That doesn't work.

	Christoph
--
Auch der Dumme hat manchmal einen gescheiten Gedanken.
Er merkt es nur nicht.  -- Danny Kaye

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> That's ok as long as she doesn't add backstreet boys songtexts as long as your
> signature to her mails.

I wouldn't worry. She'd be swimming to Cuba in search of asylum from the MPAA
if she did

> Your point is basically:
> 	Lets rewrite the kernel in VBA to make every word user
> 	capable of driver hacking.

I think thats a bit unfair. Changing the description language so drastically
is the big problem, not the tools or its UI. Its 'and Im forking the config
language from under every other config tool including the kde work and mconfig'

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

Christoph Hellwig wrote:


> That's ok as long as she doesn't add backstreet boys songtexts as long as your
> signature to her mails.


In fact, they aren't so long once you cut out the repetitions.

 
> On the other hand she should _really_ learn how to do it - like we all did.


Hey, nothing stops you from buying a used front panel and toggling in
Linux in octal.  Oughta work the first time, too.

 

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

Re: CML2 design philosophy heads-up

[Alan Cox]

> I want to understand what you're driving at here and I don't get it.  What's

What I am trying to say is that if you can infer probable configuration
categories that are relevant then instead of automatically filling the other
areas in and blocking changing them without using vi you can put the other
options as a submenu. That guides the less expert user and also helps rather
than hinders the expert

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> What I am trying to say is that if you can infer probable configuration
> categories that are relevant then instead of automatically filling the other
> areas in and blocking changing them without using vi you can put the other
> options as a submenu. That guides the less expert user and also helps rather
> than hinders the expert

OK, that's useful input.  Noted.

There's a bit of a technical problem with the distinction between 
derivations (which are like macros) and question symbols (which can
be suppressed or unsuppressed depending on their visibility predicate
But perhaps I can think up a solution to that one over lunch.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
	-- Lyndon Johnson, former President of the U.S.

Re: CML2 design philosophy heads-up

[Christer Weinigel]

Alan Cox wrote:
>At most it bounds the busses directly available. I've yet to see VME cardbus
>adapters but its quite possible.

You didn't try google did you?  *grin*

    http://www.ramix.com/products/busadapters/rm235m.html

  /Christer
-- 
"Just how much can I get away with and still go to heaven?"

Re: CML2 design philosophy heads-up

[Jonathan Morton]

>> Aunt Tillie doesn't even know what a kernel is, nor does she want
>> to. I think it's fair to assume that people who configure and
>> compile their own kernel (as opposed to using the distribution
>> supplied ones) know what they are doing.
>
>I'd like to break these assumptions.  Or at the very least see how far
>they can be bent.  I know this sounds crazy to a lot of hackers, but
>I think there's a certain amount of unhelpful elitism and self-puffery
>in the "kernels are hard to configure and they *should* be hard to
>configure* attitude.  Let's give Aunt Tillie a chance to surprise us.

Not everyone falls into the "expert user" and "Aunt Tillie" categories.
It's a *very* big grey area.  If some semi-computer-literate user (ie. some
friends of mine!) wants to upgrade their kernel so they have access to
newer hardware (such as a cheap USB webcam), it should be made as simple as
possible for them.  CML1 doesn't handle that very well, I'd like to see
it's replacement do better.

So, the first questions should be along the lines of "Do you have
(approximately) these kinds of standard configuration?" starting with "x86
PC", "Apple PowerMac" and other sensible defaults - followed by "none of
the above".  Then later on, things like "Do you have SCSI?" followed by
"What type of SCSI card(s)".  And under IDE configuration, we have "Do you
want IDE-SCSI emulation (useful for CD-writers and such)?" which turns on
SCSI without any of the card drivers.

The above strategy, if extended properly, would allow novice users to get
*something* which worked, more easily.  More advanced users could then
fiddle with settings they knew about, and experiment.  Those who *really*
know what they're up to can create a wholly customised setup by choosing
"none of the above", right at the beginning.

As for the language CML2 is written in, surely C would work just as well as
Python if the config-ruleset file is in a known format.  GCC is required
for the kernel to build, I don't see why anything else should be required
simply to configure it.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 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+(*)
-----END GEEK CODE BLOCK-----

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jonathan Morton <chromi@cyberspace.org>:
> Not everyone falls into the "expert user" and "Aunt Tillie" categories.
> It's a *very* big grey area.  If some semi-computer-literate user (ie. some
> friends of mine!) wants to upgrade their kernel so they have access to
> newer hardware (such as a cheap USB webcam), it should be made as simple as
> possible for them.  CML1 doesn't handle that very well, I'd like to see
> it's replacement do better.

Yes.  One of the reasons I keep Aunt Tillie in mind as a UI target is that
if I can design a configuration system that makes the task possible for her,
then I'll have one that makes it easy for this much larger class of 
intermediate-level users.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

In the absence of any evidence tending to show that possession 
or use of a 'shotgun having a barrel of less than eighteen inches 
in length' at this time has some reasonable relationship to the 
preservation or efficiency of a well regulated militia, we cannot 
say that the Second Amendment guarantees the right to keep and bear 
such an instrument. [...] The Militia comprised all males 
physically capable of acting in concert for the common defense.  
        -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939)

Re: CML2 design philosophy heads-up

[Mike Galbraith]

On Fri, 18 May 2001, Jonathan Morton wrote:

> As for the language CML2 is written in, surely C would work just as well as
> Python if the config-ruleset file is in a known format.  GCC is required
> for the kernel to build, I don't see why anything else should be required
> simply to configure it.

Menuconfig is fairly popular, and requires curses.. etc. etc.  There isn't
a configurator which doesn't require something more than gcc is there?

OTOH, python here says: Python 1.3 (Dec 19 1995)  [GCC 2.7.2]. I didn't
have it built at all during the years prior to 1995, so I'm sure you can
imagine how enthusiastic I am about upgrading that old turd ;-)

	-Mike

Re: CML2 design philosophy heads-up

[Alan Cox]

> Menuconfig is fairly popular, and requires curses.. etc. etc.  There isn't
> a configurator which doesn't require something more than gcc is there?

Configure only requires shell

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Kai Germaschewski]

On Fri, 18 May 2001, Eric S. Raymond wrote:

> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets.  Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
>    we stick to its spec sheet or consider it representative of all derivatives
>    (which may have other facilities)?
>
> I know my answer to this one, which I will implement unless there's
> strong consensus otherwise.  I go for explicitness.  If we're going to
> support MVME147 derivatives and variants in the ruleset, they get
> their own platform symbols.

I believe it's important two distinguish between two things here,
auto-configuration and normal configuration.

One should take care to not mix these things up. Of course I don't know
about the specific hardware there, but I believe selecting NVME147 will
give you arch specific code which will cope with general aspects of that
board, but also for derived designs. That makes sense, and no need to
introduce different config symbols at that level.
I'd call CONFIG symbols like that basic, and they should be described by a
ruleset which ensures that building the kernel will actually work, and
that you have a chance that it even runs. (Things like a SCSI driver
requires the SCSI midlayer, etc. which would normally lead to unresolved
symbols or the inability to load the driver module into the running kernel
later).

On the other hand, for some people it would be nice to say I've got the
reference board, build the right kernel. That's okay, but it should be
another option, and rules like that should be in a separate files, so they
don't clutter up the "basic" rulesets.

So, leave the flexibility to people who need, and on top of that you can
have a mechanism which allows easier configuration for people who don't
want to care about the details.

However, more important there would be some option like "build me a kernel
for the hardware I'm currently running on" (and let the user fine tune
afterwards).

--Kai

Re: CML2 design philosophy heads-up

[frank]

On Fri, 18 May 2001, Eric S. Raymond wrote:

> Tom Rini <trini@kernel.crashing.org>:
> > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI.  You have the SCSI mid
> > > > layer code but no SCSI hardware drivers.  It is a realistic case for an
> > > > embedded CD-RW appliance.
> > > 
> > > Or alternatively, you want to enable SCSI code, with no hardware driver,
> > > because you are going to build pcmcia, which builds the scsi drivers only
> > > if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or
> > > 1480 scsi card into your pcmcia slot.
> > 
> > Both of these 'problems' assume that you can have IDE or PCMCIA on these
> > particular boxes.  Does anyone know if that's actually true?
> 
> The answer is: no, you can't.  
> 
> I found a feature list for the MVME147 on the web at
> <http://www.mcg.mot.com/cfm/templates/article.cfm?PageID=1095>.  It
> confirmed what thought I remembered from the Motorola site; no PCMCIA,
> no IDE/ATAPI.  As a matter of fact neither of these technologies
> existed yet when the board was being designed in the mid-1980s.

But it is a VME board. That means you can put a SCSI controller on the VME
bus (and these do exist, I have one right here). 

Frank

> 
> (The article I found is kind of interesting.  It's a dissection of the
> MVME147's design and history...narrated in first person.)
> 
> In any case, if this *had* been a problem, the right fix IMO would have
> been to split the SCSI symbol into SCSI and SCSI_DRIVERS and have
> constraints that would make SCSI and the presence of any SCSI card 
> imply SCSI_DRIVERS.
> -- 
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> 
> The prestige of government has undoubtedly been lowered considerably
> by the Prohibition law. For nothing is more destructive of respect for
> the government and the law of the land than passing laws which cannot
> be enforced. It is an open secret that the dangerous increase of crime
> in this country is closely connected with this.
> 	-- Albert Einstein, "My First Impression of the U.S.A.", 1921
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

HI! I'm a .signature virus! cp me into your .signature file to help me spread!

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> Jes Sorensen <jes@sunsite.dk>:
Eric> # These were separate questions in CML1 derive MAC_SCC from MAC
Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from
Eric> (SUN3 | SUN3X) & SCSI
>>  As Alan already pointed out thats assumption is invalid.

Eric> I'm in touch with Ray Knight directly and will fix this as he
Eric> requests.

If Ray wants to fix things, it's just fine with me.
 
>> Yes I have objections. I thought I had made this clear a long time
>> ago: Go play with another port and leave the m68k port alone.

Eric> Does this mean you'll take over maintaining the CML2 rules files
Eric> for the m68k port, so I don't have to?  That would be wonderful.

For a start, so far there has been no reason whatsoever to change the
format of definitions.

Eric> Reasoned objections can change my behavior.  Grunting
Eric> territorial challenges at me will not.  You have two options:
Eric> (1) persuade Linus that the whole CML2 thing is a bad idea and
Eric> should be dropped, or (2) work with me to correct any errors I
Eric> have made and improve the system.  Growling at me and hoping I
Eric> go away won't work, not when I've invested a year's effort in
Eric> this project.

So far you have only been irritating developers for no reason. What I
asked you to do is to NOT change whatever config options developers
developers felt were necessary to introduce. If you want to change the
format of the config.in files go ahead. Messing around with the config
options themselves is *not* for you to do, nor are you to impose a
more restrictive space for people to work in.

Jes

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jes Sorensen <jes@sunsite.dk>:
> If Ray wants to fix things, it's just fine with me.

I have corrected the Mac dependencies as Ray directed.
  
> Eric> Does this mean you'll take over maintaining the CML2 rules files
> Eric> for the m68k port, so I don't have to?  That would be wonderful.
> 
> For a start, so far there has been no reason whatsoever to change the
> format of definitions.

The judgment of the kbuild team is unanimous that you are mistaken on this.
That's the five people (excluding me) who wrote and maintained the CML1 code.
*They* said that code had to go, Linus has concurred with their judgment, 
and the argument is over.

> So far you have only been irritating developers for no reason. What I
> asked you to do is to NOT change whatever config options developers
> developers felt were necessary to introduce. If you want to change the
> format of the config.in files go ahead. Messing around with the config
> options themselves is *not* for you to do, nor are you to impose a
> more restrictive space for people to work in.

If you persist in misunderstanding what I am doing, you are neither
going to be able to influence my behavior nor to persuade other people
that it is wrong.  Listen carefully, please:

1. The CML2 system neither changes the CONFIG_ symbol namespace nor 
   assumes any changes in it.  (Earlier versions did, but Greg Banks
   showed me how to avoid needing to.)

2. The ruleset changes I have made simplify the configuration process,
   but they do *not* in any way restrict the space of configurations 
   that are possible.  By design, every valid (consistent) configuration
   in CML1 can be generated in CML2.  I treat departures from that rule
   as rulesfile bugs and fix them (as I just did at Ray Knight's instruction).

3. I do not have (nor do I seek) the power to "impose" anything on anyone.

You really ought to give CML2 a technical evaluation yourself before you
flame me again.  Much of what you seem to think you know is not true.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"

Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:

Eric> Jes Sorensen <jes@sunsite.dk>:
>>  For a start, so far there has been no reason whatsoever to change
>> the format of definitions.

Eric> The judgment of the kbuild team is unanimous that you are
Eric> mistaken on this.  That's the five people (excluding me) who
Eric> wrote and maintained the CML1 code.  *They* said that code had
Eric> to go, Linus has concurred with their judgment, and the argument
Eric> is over.

Replacing the code does not require changing the style of the config
files. Thats a major problem with CML2, you introduce a new 'let me do
everything for you' tool that relies on a programming language that is
not being shipped by any major vendor nor does it look like they are
planning to do it anytime soon. And even if they start doing so, this
is a totally unreasonable requirement, you *must* to make it possible
to compile kernels on older distributions without requiring people to
update half of their system. On some architectures, the majority of
the users are still on glibc 2.0 and other old versions of
tools. Telling them to install an updated gcc for kernel compilation
is a necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python installation is not a
reasonable request. Nobody disagrees that the Makefiles needs a
redesign, however that doesn't mean everything else has to be
redisigned in a totally incompatible manner.

Eric> If you persist in misunderstanding what I am doing, you are
Eric> neither going to be able to influence my behavior nor to
Eric> persuade other people that it is wrong.  Listen carefully,
Eric> please:

Oh I don't, on the other hand I see you consistently ignoring the
needs and requirements of the users. So far I haven't heard a single
developer say something positive about CML2, the most positive I have
heard so far has been "whatever", "it's his choice", "I don't care",
"I want to hack". The majority are of the "NO!" and "you got to be
kiddin'".

Eric> 1. The CML2 system neither changes the CONFIG_ symbol namespace
Eric> nor assumes any changes in it.  (Earlier versions did, but Greg
Eric> Banks showed me how to avoid needing to.)

Let's just say you didn't exactly give peoiple a good impression with
the trolling around on how everybody had to change their option names 
and how important it was for the world.

Eric> 2. The ruleset changes I have made simplify the configuration
Eric> process, but they do *not* in any way restrict the space of
Eric> configurations that are possible.  By design, every valid
Eric> (consistent) configuration in CML1 can be generated in CML2.  I
Eric> treat departures from that rule as rulesfile bugs and fix them
Eric> (as I just did at Ray Knight's instruction).

What spawned this recent discussion was you wanting to remove config
options and automatically enable things instead of giving the users
the explicit choice to do so. Now you are trying to tell me that you
are not changing things?

Eric> 3. I do not have (nor do I seek) the power to "impose" anything
Eric> on anyone.

We'll let that one stand on display for a few minutes.

Eric> You really ought to give CML2 a technical evaluation yourself
Eric> before you flame me again.  Much of what you seem to think you
Eric> know is not true.

So far I have had to deal with a number of requests from you trying to
impose unreasonable changes on developers. Thats more than plenty for
me. I do not have Python2 installed and I do not plan to, if you
change CML2 to use a reasonable programming language I might give it a
try.

Jes

PS: And if you could start making your .signature rfc1855 compliant it
was be pleasant for all readers of this mailing list.

Re: CML2 design philosophy heads-up

[Justin Carlson]

On Fri, 18 May 2001, Jes Sorensen wrote:

> Oh I don't, on the other hand I see you consistently ignoring the
> needs and requirements of the users. So far I haven't heard a single
> developer say something positive about CML2, the most positive I have
> heard so far has been "whatever", "it's his choice", "I don't care",
> "I want to hack". The majority are of the "NO!" and "you got to be
> kiddin'".

Perhaps your hearing has gone more than a bit selective.  Please, allow
me to be the first to get through:

I think CML2 looks very interesting, and while it's not quite primetime yet,
it's definitely a movement in the right direction.  I'd even go sofar as to 
say I think CML2 is a GOOD THING.

Or perhaps you have a more selective definition of developer?

-Justin
carlson@sibyte.com

Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Jes Sorensen <jes@sunsite.dk>:
> Oh I don't, on the other hand I see you consistently ignoring the
> needs and requirements of the users.

<sarcasm>Oh, sure.  The CML2 NEWS file is ample proof of that.</sarcasm>

OK, Jes, you've just demonstrated that you're blind to facts and can't 
be reasoned with.  I'll continue listening to everybody else as I've
been doing, but I'll specifically ignore *you* until you lose the 
obstreperous attitude.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The whole of the Bill [of Rights] is a declaration of the right of the
people at large or considered as individuals...  It establishes some
rights of the individual as unalienable and which consequently, no
majority has a right to deprive them of.
         -- Albert Gallatin, Oct 7 1789

Re: CML2 design philosophy heads-up

[Alan Cox]

> OK, Jes, you've just demonstrated that you're blind to facts and can't 
> be reasoned with.  I'll continue listening to everybody else as I've
> been doing, but I'll specifically ignore *you* until you lose the 
> obstreperous attitude.

>From here it has me thinking of pots kettles and a rather dark colour...

Alan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

Jes Sorensen wrote:

> Telling them to install an updated gcc for kernel compilation
> is a necessary evil, which can easily be done without disturbing the
> rest of the system. Updating the system's python installation is not a
> reasonable request.


Au contraire.  It is very reasonable to have both python and python2
installed.  Having two different gcc versions installed is a big pain
in the arse.

> So far I haven't heard a single
> developer say something positive about CML2, the most positive I have
> heard so far has been "whatever", "it's his choice", "I don't care",
> "I want to hack". The majority are of the "NO!" and "you got to be
> kiddin'".


Anonymized hearsay evidence is less than convincing.


> Let's just say you didn't exactly give peoiple a good impression with
> the trolling around on how everybody had to change their option names 
> and how important it was for the world.


Decidedly bad form to criticize someone for a bug (in this case,
a design bug) that's already been fixed.  If that behavior starts,
who shall escape hanging?

 
> I do not have Python2 installed and I do not plan to, if you
> change CML2 to use a reasonable programming language I might give it a
> try.


Those who don't remember the past are condemned to repeat it.

John Cowan, _novus homo_ (Latin for "upstart")

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
> Jes Sorensen wrote:
> 
> > Telling them to install an updated gcc for kernel compilation
> > is a necessary evil, which can easily be done without disturbing the
> > rest of the system. Updating the system's python installation is not a
> > reasonable request.
> 
> 
> Au contraire.  It is very reasonable to have both python and python2
> installed.  Having two different gcc versions installed is a big pain
> in the arse.

Fump. Some distributions do even come with two gcc's out of the box.
With the whole egcs and gcc2.95 (dunno about 3.0) you can even share
the compiler driver if you want.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[John Cowan]

Christoph Hellwig wrote:

> On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
> 
>>Jes Sorensen wrote:
>>
>>
>>>Telling them to install an updated gcc for kernel compilation
>>>is a necessary evil, which can easily be done without disturbing the
>>>rest of the system. Updating the system's python installation is not a
>>>reasonable request.
>>>
>>
>>Au contraire.  It is very reasonable to have both python and python2
>>installed.  Having two different gcc versions installed is a big pain
>>in the arse.
>>
> 
> Fump. Some distributions do even come with two gcc's out of the box.
> With the whole egcs and gcc2.95 (dunno about 3.0) you can even share
> the compiler driver if you want.


Yes, I should have limited myself to pre-egcs versions.

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
> Christoph Hellwig wrote:
> Yes, I should have limited myself to pre-egcs versions.

Huh?

It's been possible to have multiple versions of gcc installed for a very
long time.  At least since 2.0 came out.

Thu Dec 19 15:54:29 1991  K. Richard Pixley  (rich at cygnus.com)

        * configure: added -V for version number option.


mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Christoph Hellwig]

In article <20010518101533.E10611@thune.mrc-home.com> you wrote:
> On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote:
>> Christoph Hellwig wrote:

[my voice was snipped here]

>> Yes, I should have limited myself to pre-egcs versions.
>
> Huh?
>
> It's been possible to have multiple versions of gcc installed for a very
> long time.  At least since 2.0 came out.
>
> Thu Dec 19 15:54:29 1991  K. Richard Pixley  (rich at cygnus.com)
>
>         * configure: added -V for version number option.

But with at least the combination of gcc2.7.2.x and egcs1.x it did not
work for me (and others).

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "John" == John Cowan <jcowan@reutershealth.com> writes:

John> Jes Sorensen wrote:
>> Telling them to install an updated gcc for kernel compilation is a
>> necessary evil, which can easily be done without disturbing the
>> rest of the system. Updating the system's python installation is
>> not a reasonable request.

John> Au contraire.  It is very reasonable to have both python and
John> python2 installed.  Having two different gcc versions installed
John> is a big pain in the arse.

It's not unreasonable to have both installed, it's unreasonable to
require it.

Eric seems to think he can tell every distributor to ship Python2
tomorrow. Well it's a fine dream but it's not going to happen; Most
distributors do not ship new major versions of tools in their minor
number release versions. I've seen him mention the number 6 months
until everybody ships it, but a) thats not going to happen Red Hat is
currently at 7.1 (if one looks at their release history, one would say
there is a good chance there will be a 7.2) not to mention the release
rate of Debian (not sure about the current state of all other
distributions). 18 months is more realistic for it to be deployed
widely enough.

>> So far I haven't heard a single developer say something positive
>> about CML2, the most positive I have heard so far has been
>> "whatever", "it's his choice", "I don't care", "I want to
>> hack". The majority are of the "NO!" and "you got to be kiddin'".

John> Anonymized hearsay evidence is less than convincing.

Well I don't like to quote personal conversations without peoples'
approval, now both David Woodhouse and Arjan are two examples.

Jes

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
> distributions). 18 months is more realistic for it to be deployed
> widely enough.

People who are going to be savvy enough to install a development 2.5.*
kernel that is defining a new configuration utility are going to be savvy
enough to install python.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Ben Ford]

Mike Castle wrote:

>On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
>
>>distributions). 18 months is more realistic for it to be deployed
>>widely enough.
>>
>
>People who are going to be savvy enough to install a development 2.5.*
>kernel that is defining a new configuration utility are going to be savvy
>enough to install python.
>
>mrc
>
Not only that, but Alan said that somebody is rewriting it in C.

-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Ben" == Ben Ford <ben@kalifornia.com> writes:

Ben> Mike Castle wrote:
>>  People who are going to be savvy enough to install a development
>> 2.5.* kernel that is defining a new configuration utility are going
>> to be savvy enough to install python.
>> 
Ben> Not only that, but Alan said that somebody is rewriting it in C.

No and yes, the Python 2 issue is not reasonable, the C version of it
is. Hopefully with a proper C version, the Python 2 dependencies will
go away completely and that part of the discussion becomes moot.

The Python 2 one is a major issue, some people compile current kernels
because thats all that exists for their hardware. Some people who are
bringing up new architectures etc. wants to be self hosting but things
like Perl and Python are not exactly the first things you build. You
may not have threads, you may not have proper math support, maybe no
shared libraries, but that wont stop you from getting
gcc/binutils/bash going. The argument I got from Eric at the 2.5
kernel summit when I first brought this up was 'just configure your
kernel on another machine and copy it over'. Thats extremely naiive,
in some cases you do not have network nor floppy. You copy your
sources over once (so you can hack on the network driver :), you don't
want to have to rip out the disk every time you need a change to the
.config because some obscure option doesn't compile and you hadn't
noticed.

It's just not that trivial.

Jes

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Castle]

On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote:
> Not only that, but Alan said that somebody is rewriting it in C.

I'll believe it when I see it.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote:
> > Not only that, but Alan said that somebody is rewriting it in C.
> I'll believe it when I see it.

and if not then obviously nobody hates the python one enough ;)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[arjan]

In article <20010520185827.B16356@thune.mrc-home.com> you wrote:
> On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote:
>> distributions). 18 months is more realistic for it to be deployed
>> widely enough.

> People who are going to be savvy enough to install a development 2.5.*
> kernel that is defining a new configuration utility are going to be savvy
> enough to install python.

In the first months, yes. Once we freeze you've just lost a major part of
your testersbase...

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Nicolas Pitre]

On 21 May 2001, Jes Sorensen wrote:

> John> Au contraire.  It is very reasonable to have both python and
> John> python2 installed.  Having two different gcc versions installed
> John> is a big pain in the arse.
>
> It's not unreasonable to have both installed, it's unreasonable to
> require it.
>
> Eric seems to think he can tell every distributor to ship Python2
> tomorrow. Well it's a fine dream but it's not going to happen

Distributors aren't going to ship Linux 2.5.x tomorrow either.


Nicolas

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Robert M. Love]

On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
> John> Au contraire.  It is very reasonable to have both python and
> John> python2 installed.  Having two different gcc versions installed
> John> is a big pain in the arse.
> 
> It's not unreasonable to have both installed, it's unreasonable to
> require it.
> 
> Eric seems to think he can tell every distributor to ship Python2
> tomorrow. Well it's a fine dream but it's not going to happen; <snip>

I think this is a very important point, and one I agree with.  I tend to
let my distribution handle stuff like python.  now, I use RedHat's
on-going devel, RawHide. it is not using python2.  in fact, since
switching to python2 may break old stuff, I don't expect python2 until
8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
al, are written in python1 and they just are not going to change on
someone's whim.

im not installing python2 from source just so i can run some new config
utility.

(on another note, about the coexist issue: am i going to have a python
and python2 binary? so now the config tool will find which to use, ala
the kgcc mess? great)

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jakob Østergaard]

On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> On 21 May 2001 02:29:17 +0200, Jes Sorensen wrote:
> > John> Au contraire.  It is very reasonable to have both python and
> > John> python2 installed.  Having two different gcc versions installed
> > John> is a big pain in the arse.
> > 
> > It's not unreasonable to have both installed, it's unreasonable to
> > require it.
> > 
> > Eric seems to think he can tell every distributor to ship Python2
> > tomorrow. Well it's a fine dream but it's not going to happen; <snip>
> 
> I think this is a very important point, and one I agree with.  I tend to
> let my distribution handle stuff like python.  now, I use RedHat's
> on-going devel, RawHide. it is not using python2.  in fact, since
> switching to python2 may break old stuff, I don't expect python2 until
> 8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
> al, are written in python1 and they just are not going to change on
> someone's whim.

2.6.0 isn't going to happen for at least a year or two.  What's the problem ?

Want 2.5.X ?  Get the tools too.

I'm in no position to push people around, but I think the whining about CML2
tool requirements is completely unjustified.  If we required that everything
worked with GCC 2.7.2 and nmake, where would we be today ?   I'm a lot more
worried about CML2 itself than about the tools it requires   :)

> 
> im not installing python2 from source just so i can run some new config
> utility.

python2 will be in rawhide when 2.5 development requires it, if I'm not much
mistaken.

Whether CML2 requires python2 or not, the distributions will change. This is
not about Eric pushing something down people's throats. Tools evolve, and new
revisions introduce incompatibilities, but distributions still follow the
evolution.  Nobody ships perl4 today either.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike Galbraith]

On Mon, 21 May 2001, Jakob Østergaard wrote:

> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> >
> > im not installing python2 from source just so i can run some new config
> > utility.
>
> python2 will be in rawhide when 2.5 development requires it, if I'm not much
> mistaken.

Alan said someone is rewriting in C, so the python2 requirement is
already becoming a non-problem.

	-Mike

(don't like requirement, but don't think it's a big hairy deal either)

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Jakob" == Jakob Østergaard <jakob@unthought.net> writes:

Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
>> I think this is a very important point, and one I agree with.  I
>> tend to let my distribution handle stuff like python.  now, I use
>> RedHat's on-going devel, RawHide. it is not using python2.  in
>> fact, since switching to python2 may break old stuff, I don't
>> expect python2 until 8.0. that wont be for 9 months.  90% of
>> RedHat's configuration tools, et al, are written in python1 and
>> they just are not going to change on someone's whim.

Jakob> 2.6.0 isn't going to happen for at least a year or two.  What's
Jakob> the problem ?

Jakob> Want 2.5.X ?  Get the tools too.

Some people grab the latest devel kernels because thats all that works
on their hardware.

Jakob> I'm in no position to push people around, but I think the
Jakob> whining about CML2 tool requirements is completely unjustified.
Jakob> If we required that everything worked with GCC 2.7.2 and nmake,
Jakob> where would we be today ?  I'm a lot more worried about CML2
Jakob> itself than about the tools it requires :)

gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are
not.

Jakob> Whether CML2 requires python2 or not, the distributions will
Jakob> change. This is not about Eric pushing something down people's
Jakob> throats. Tools evolve, and new revisions introduce
Jakob> incompatibilities, but distributions still follow the
Jakob> evolution.  Nobody ships perl4 today either.

The point is that Eric has been trying to push distributions to ship
P2.

Jes

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Tom Rini]

On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote:
> >>>>> "Jakob" == Jakob ?stergaard <jakob@unthought.net> writes:
> 
> Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote:
> >> I think this is a very important point, and one I agree with.  I
> >> tend to let my distribution handle stuff like python.  now, I use
> >> RedHat's on-going devel, RawHide. it is not using python2.  in
> >> fact, since switching to python2 may break old stuff, I don't
> >> expect python2 until 8.0. that wont be for 9 months.  90% of
> >> RedHat's configuration tools, et al, are written in python1 and
> >> they just are not going to change on someone's whim.
> 
> Jakob> 2.6.0 isn't going to happen for at least a year or two.  What's
> Jakob> the problem ?
> 
> Jakob> Want 2.5.X ?  Get the tools too.
> 
> Some people grab the latest devel kernels because thats all that works
> on their hardware.

And they can grab the latest tools too.  Why is this a problem again?
python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
uses undocumented things which did work in python1.5.x.  But that's not as
big of a problem since they can co-exist.  Debian already does this (And thus
CML2 already deals with python2 being called 'python2') and I wouldn't be
supprised if the PowerTools python2 rpm someone pointed out makes them
co-exist as well.

Which brings up another point, RedHat (7.1?) and Debian/woody both have the
option of having python2 around.  Anyone know about mandrake?  My point is
that some dists are already dealing with python2.

> Jakob> I'm in no position to push people around, but I think the
> Jakob> whining about CML2 tool requirements is completely unjustified.
> Jakob> If we required that everything worked with GCC 2.7.2 and nmake,
> Jakob> where would we be today ?  I'm a lot more worried about CML2
> Jakob> itself than about the tools it requires :)
> 
> gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are
> not.

Well no, but python1 requires another 2k lines of python code or so.
Eric, would it be easy/possible to go back to requiring python 1.5.x for
CML2, since that is what many dists ship with?

> Jakob> Whether CML2 requires python2 or not, the distributions will
> Jakob> change. This is not about Eric pushing something down people's
> Jakob> throats. Tools evolve, and new revisions introduce
> Jakob> incompatibilities, but distributions still follow the
> Jakob> evolution.  Nobody ships perl4 today either.
> 
> The point is that Eric has been trying to push distributions to ship
> P2.

Maybe, maybe not.  Forgetting about the QA time and whatnot, there's good
odds that all of the python scripts RedHat (for example) ships will just
work with python2.  I know one of the PPC dists didn't ship with python2
(which does have a lot of python bits to it) entirely because they were
already in testing when it came out.  It's not something the distros
can switch to at a whim, but it's also something which shouldn't cause
them problems when they do.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Tom Rini <trini@kernel.crashing.org>:
> python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script
> uses undocumented things which did work in python1.5.x.

That's true of the core language.  The reason I moved to 2.0 was that there
are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint
substantially.

> Which brings up another point, RedHat (7.1?) and Debian/woody both have the
> option of having python2 around.  Anyone know about mandrake?  My point is
> that some dists are already dealing with python2.

Yes.  By the time 2.5 forks, distros covering an estimated 85% of the market
will carry python2 binaries which the CML2 install script will find 
automatically.  By the time 2.6 forks, we're going to laugh if we ever
remember that we thought this was an issue.

> Eric, would it be easy/possible to go back to requiring python 1.5.x for
> CML2, since that is what many dists ship with?

It wouldn't be too difficult.  But it would make the code heavier, and
I'm not clear that it would make anybody happy who isn't already willing
to deal with the design concept.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The world is filled with violence. Because criminals carry guns, we
decent law-abiding citizens should also have guns. Otherwise they will
win and the decent people will lose.
        -- James Earl Jones

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Mike A. Harris]

On 20 May 2001, Robert M. Love wrote:

>I think this is a very important point, and one I agree with.  I tend to
>let my distribution handle stuff like python.  now, I use RedHat's
>on-going devel, RawHide. it is not using python2.  in fact, since
>switching to python2 may break old stuff, I don't expect python2 until
>8.0. that wont be for 9 months.  90% of RedHat's configuration tools, et
>al, are written in python1 and they just are not going to change on
>someone's whim.
>
>im not installing python2 from source just so i can run some new config
>utility.
>
>(on another note, about the coexist issue: am i going to have a python
>and python2 binary? so now the config tool will find which to use, ala
>the kgcc mess? great)

powertools/7.1/SRPMS/python2-2.0-3.src.rpm

For the record, the kgcc "mess" you speak of was used by
Conectiva, and I believe also by debian before adoption in Red
Hat Linux.  It was about as good a solution as one could get for
the problem that it solved - the kernel being broken and unable
to build with our gcc-2.96.  Just to head anyone off at the
pass... the kernel is fixed and now builds properly with
gcc-2.96.  Also, if anyone has any questions about gcc-2.96
please see:

http://www.bero.org/gcc296.html

----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------
Microsoft Windows(tm). A 32 bit extension and graphical shell to a 16 bit 
patch to an 8 bit operating system originally coded for a 4 bit microprocessor
which was written by a 2 bit company that can't stand 1 bit of competition.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Robert M. Love]

On 21 May 2001 02:11:39 -0400, Mike A. Harris wrote:
> On 20 May 2001, Robert M. Love wrote:
>>(on another note, about the coexist issue: am i going to have a python
>>and python2 binary? so now the config tool will find which to use, ala
>>the kgcc mess? great)
>
> For the record, the kgcc "mess" you speak of was used by
> Conectiva, and I believe also by debian before adoption in Red
> Hat Linux.  It was about as good a solution as one could get for
> the problem that it solved - the kernel being broken and unable
> to build with our gcc-2.96.  Just to head anyone off at the
> pass... the kernel is fixed and now builds properly with
> gcc-2.96.

my view of the mess wasn't the fact RedHat used kgcc. i think that was a
good move.

i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95,
gcc-2.91 etc. what is the cml2 parser going to do? search for my python2
binary because my python1 binary is my "standard" python?

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> i mean how in 2.2 the Makefile must search out for gcc, kgcc, gcc-2.95,
> gcc-2.91 etc. what is the cml2 parser going to do? search for my python2

This isnt a CML2 related problem. 

Problem 1: 
	People who don't like the CML2 description

Problem 2:
	People who don't like python

Problem 3:
	People who don't like the tool design

Problem 4:
	People who don't have python2 


#1 is the important item
#2 is fixed by rewriting tools in C
#3 is fixed by writing alternative tools using CML2 - and if you cant its a bug
   in the CML2 language
#4 is probably one for the LDPS/LSB and vendor people to discuss so we have an
official path for python2

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Brent D. Norris]

> #2 is fixed by rewriting tools in C

didn't Eric say that this has stalled though?  Is that not the case?

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
                        Best Mechanical

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Eric S. Raymond]

Brent D. Norris <brent@biglinux.tccw.wku.edu>:
> didn't Eric say that this has stalled though?  Is that not the case?

Nope.  Greg is still working.  He got the first version of the theorem prover
working recently.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A wise and frugal government, which shall restrain men from injuring
one another, which shall leave them otherwise free to regulate their
own pursuits of industry and improvement, and shall not take from the
mouth of labor the bread it has earned. This is the sum of good
government, and all that is necessary to close the circle of our
felicities.
	-- Thomas Jefferson, in his 1801 inaugural address

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Wichert Akkerman]

In article <Pine.LNX.4.33.0105210205520.1590-100000@asdf.capslock.lan>,
Mike A. Harris <mharris@opensourceadvocate.org> wrote:
>For the record, the kgcc "mess" you speak of was used by
>Conectiva, and I believe also by debian

Debian never had that mess.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |
-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alan Cox]

> Mike A. Harris <mharris@opensourceadvocate.org> wrote:
> >For the record, the kgcc "mess" you speak of was used by
> >Conectiva, and I believe also by debian
> Debian never had that mess.

Debians variant was gcc272 not kgcc. The 2.2.19 makefile knows about both of
them

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Alexander Viro]

On 21 May 2001, Wichert Akkerman wrote:

> In article <Pine.LNX.4.33.0105210205520.1590-100000@asdf.capslock.lan>,
> Mike A. Harris <mharris@opensourceadvocate.org> wrote:
> >For the record, the kgcc "mess" you speak of was used by
> >Conectiva, and I believe also by debian
> 
> Debian never had that mess.

I think that Mike refers to gcc272 being used as a kernel compiler
for quite a while and gcc-2.95 being used the same way in -testing.

<shrug> having different compilers for kernel and userland is not
pretty, but there's no way to avoid it at some points in cycle.

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Steven Cole]

On Friday 18 May 2001 09:19, Jes Sorensen wrote:
> Replacing the code does not require changing the style of the config
> files. Thats a major problem with CML2, you introduce a new 'let me do
> everything for you' tool that relies on a programming language that is
> not being shipped by any major vendor nor does it look like they are
> planning to do it anytime soon. And even if they start doing so, this

Actually, Linux-Mandrake 8.0 ships with Python 2.0, but your next
point is a very good one:

> is a totally unreasonable requirement, you *must* to make it possible
> to compile kernels on older distributions without requiring people to
> update half of their system. On some architectures, the majority of
> the users are still on glibc 2.0 and other old versions of
> tools. Telling them to install an updated gcc for kernel compilation
> is a necessary evil, which can easily be done without disturbing the
> rest of the system. Updating the system's python installation is not a
> reasonable request. Nobody disagrees that the Makefiles needs a
> redesign, however that doesn't mean everything else has to be
> redisigned in a totally incompatible manner.

I didn't have trouble installing python 2.0 before LM 8.0 did that for me,
but I was probably just lucky.  I've seen some reports by other people who
did have difficulty upgrading python.  If the python installation difficulties
are a real obstacle, perhaps that is what needs to be fixed.

Steven

Re: [kbuild-devel] Re: CML2 design philosophy heads-up

[Steven Cole]

On Monday 21 May 2001 10:01, Tom Rini wrote:
> On Mon, May 21, 2001 at 09:58:04AM -0600, Steven Cole wrote:
> > On Monday 21 May 2001 09:36, Tom Rini wrote:
> > > Which brings up another point, RedHat (7.1?) and Debian/woody both have
> > > the option of having python2 around.  Anyone know about mandrake?  My
> > > point is that some dists are already dealing with python2.
> >
> > Hi Tom,
> > I use Linux-Mandrake 8.0 now, and python2 is installed by default for a
> > development workstation installation.  I asked Mandrakesoft to also
> > install the tkinter package (which was not installed by default in
> > release candidate 1), and it appeared in LM 8.0 final, so if you like to
> > use make xconfig with CML2, you can.
>
> Could you please send this to linux-kernel as well? :)

At Tom's request, posting to lkml.
Steven

Re: CML2 design philosophy heads-up

[Ruth Ivimey-Cook]

At 04:22 PM 5/13/01 +0200, you wrote:
>I've said before on these lists that one of the purposes of
>CML2's single-apex tree design is to move the configuration
>dialog away from low-level platform- specific questions towards
>higher-level questions about policy or intentions.
>
>Or to put another way: away from hardware, towards capabilities.

Can I just say I think this is the right approach, overall. Those who say 
it's not right to cripple those doing weird things to support the masses 
are right, but on the other hand very many kernel compiles will be 
relatively small deviations from a fairly standard setup (e.g. enabling or 
disabling NAT) and in my opinion life's too short to spend learning about 
configuring the latest kernel.

Specifically:

1. Deriving common cases from simple assertions is Good for many people, 
making it less likely they will end up with a bad kernel through oversight.

2. Allowing an expert mode that allows you to change each & every option 
allows those with specific needs to configure them (i.e. you need know 
whether a user made a choice to include X rather than it being a 
derivation, and this must be stored in the config database along with the 
actual choice)

3. I would like to be able to start off configuring a kernel with a list of 
statements like:

  - an Asus motherboard
  - a Pentium III
  - an Adaptec AHA2400 SCSI controller
  - IDE disks

and see what else must be specified. I.e. I don't want to have to search to 
tell the config program what I know; I want to tell it what I know, digest 
that and then let it figure out what else it needs answers to.

-- extra bonus section: Obviously, sometimes, you are compiling for another 
machine, but it would be great if the config could be asked to get at least 
some of this list of items from the current hardware/system (using lspci 
and friends).

It would be nice if it then printed a summary (in English, not config-ese) 
what has been configured, so I can double-check.

4. It would be neat to have a quick way of taking a config file from an 
older kernel. Then the config program to be able to tell what config items 
have changed/are new/etc and then have a menu containing just these items. 
You could then upgrade kernels by looking through this list, safe in the 
knowledge that everything else is already OK.

5. One final, general plea: Please can we have a sensible menu structure 
for the config options. The current (for me, 2.4.1) menu structure is just 
plain irritating, because it is not organised in an understandable (for me) 
way...  If you want me to help define things further, I'm willing.

HTH,

Ruth
-- 

Ruth 
Ivimey-Cook                       ruthc@sharra.demon.co.uk
Technical 
Author, ARM Ltd              ruth.ivimey-cook@arm.com

Re: Background to the argument about CML2 design philosophy

[Ben Bridgwater]

> derive MVME147_SCSI from MVME147 & SCSI

It seems that the preferred semantics would be:

default MVME147_SCSI from MVME147 & SCSI

That way the platform defines sane defaults, but no flexibility has been
taken away.

Presumably many of these defaulted options would also be ones that would
be configured not to be changeable in novice mode. The novice gets the
vanilla platform defaults without being bothered by detailed options,
and can switch to expert mode if they need more control. The experts get
all the options presented, but also get to benefit from the smart
platform defaults.

Ben

Re: Background to the argument about CML2 design philosophy

[Wayne.Brown]

On 05/21/2001 at 05:04:40 AM esr@thyrsus.com wrote:

>See, I've already written off the chronic bellyachers.  Since I can't
>please them without scrapping the whole plan, I'm going to ignore
>them.  In particular, anybody who repeated "fsck Python..." after Linus
>ruled that Python is not an issue and Greg Banks announced the C
>implementation of CML2 has got a sufficiently severe case of
>rectocranial insertion that they've defined themselves out of the
>conversation.

I probably qualify as one of the bellyachers.  If so, I apologize.  It was not
my intention to disparage the work of Eric or anyone else involved in this
project.

Speaking from the perspective of a user of the CML tools, rather than as a
developer, all I've been trying to say is this:  When I type "make menuconfig"
or "make oldconfig" in the future, I want to see the same interface and the same
results that I've always seen, because it's always worked for me in the past.
It really doesn't matter to me if, down underneath, this is being done by CML1,
CML2, or a little man in my computer who slaughters chickens and reads their
entrails for omens to determine dependencies.  Right now I can grab a new -pre
or -ac patch, use oldconfig, and have a compile going in a few minutes, without
knowing or caring about the details of the config process.  In the rare case
that a patch breaks an existing driver, it takes only a couple of minutes with
menuconfig to disable that driver and compile without it, and then put it back
in when it's fixed.  And when, every once in a great while, I decide to scrap my
.config and start over, I can fly through all the menuconfig options very
quickly and make my customary selections almost without thinking about it.

I just want to be able to keep using the tools in this way.  If that's not going
to be possible... well, I'll adapt.  But from my point of view, learning a new
set of tools just to keep doing the same things I've always done isn't a
pleasant prospect.  I understand that changes may be necessary to meet others'
needs, but I'd like to see those changes made without affecting the way my own
needs are met.

I'm off my soapbox now and won't bellyache about it any further.

Wayne

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Wayne.Brown@altec.com <Wayne.Brown@altec.com>:
> Speaking from the perspective of a user of the CML tools, rather
> than as a developer, all I've been trying to say is this: When I
> type "make menuconfig" or "make oldconfig" in the future, I want to
> see the same interface and the same results that I've always seen,
> because it's always worked for me in the past.

Visual details will differ, but I've been careful about maintaining
functional compatibility.  There was a phase of the development during
which I was mostly processing feature requests from people who wanted
features of the old system that I had not properly understood (such as
the NEW tag).  That phase ended almost a month ago.  Nobody who has
actually tried the CML2 tools more recently has reported that the UI
changes present any difficulty.

CML2 drops its configuration results in the same place, in the same
formats, as CML1.  So you should in fact be able to type `make menuconfig'
and `make oldconfig' with good results.  Have you actually tried this?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The right of the citizens to keep and bear arms has justly been considered as
the palladium of the liberties of a republic; since it offers a strong moral
check against usurpation and arbitrary power of rulers; and will generally,
even if these are successful in the first instance, enable the people to resist
and triumph over them."
        -- Supreme Court Justice Joseph Story of the John Marshall Court

Re: Background to the argument about CML2 design philosophy

[Urban Widmark]

On Mon, 21 May 2001, Eric S. Raymond wrote:

> the NEW tag).  That phase ended almost a month ago.  Nobody who has
> actually tried the CML2 tools more recently has reported that the UI
> changes present any difficulty.

What happened with the discussion on configurable colors in make
menuconfig? Darkblue on black as frozen options get isn't exactly optimal
... at least not for my eyes. Being next to a bold, white text doesn't
help either.


> CML2 drops its configuration results in the same place, in the same
> formats, as CML1.  So you should in fact be able to type `make menuconfig'
> and `make oldconfig' with good results.  Have you actually tried this?

It works for me, but anyone testing this should know that the CML2 tools
read "config.out" if it finds one. So people that do things like:

make mrproper ; cp ../.config-2.4 .config ; make oldconfig

will have to change to copying config.out instead. Doing like this sort of
works* if there is no config.out, otherwise it does not (as it uses the
config.out).

Saying that the config result ends up in the same place and same format is
somewhat misleading, you do get a copy in the CML1 output format but the
tools doesn't care about that if it can find a file in the new format.

*) "Sort of works", since doing like I do will cause you to get a lot of
questions that you have already answered. That appears to be a one-time
problem as 'oldconfig' does not read "# CONFIG_FOO is not set" as "no".
Would be nice if it did.


make mrproper doesn't remove config.out. It should since that's what it
does with .config* files. Not sure if it should remove the rules.out file
also, but I think it should as the idea(?) with mrproper is to clean up
anything that is generated.

/Urban

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Urban Widmark <urban@teststation.com>:
> What happened with the discussion on configurable colors in make
> menuconfig? Darkblue on black as frozen options get isn't exactly optimal
> ... at least not for my eyes. Being next to a bold, white text doesn't
> help either.

Nobody could come up with a way to support configurable colors that didn't seem
like way more trouble than it was worth.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),

Re: Background to the argument about CML2 design philosophy

[john slee]

On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote:
> On Mon, 21 May 2001, Eric S. Raymond wrote:
> 
> > the NEW tag).  That phase ended almost a month ago.  Nobody who has
> > actually tried the CML2 tools more recently has reported that the UI
> > changes present any difficulty.
> 
> What happened with the discussion on configurable colors in make
> menuconfig? Darkblue on black as frozen options get isn't exactly optimal
> ... at least not for my eyes. Being next to a bold, white text doesn't
> help either.

if you don't like dark blue on black, change your terminal colours.
then you won't find it hard to read in other applications either.

it's also far less effort this way...

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Background to the argument about CML2 design philosophy

[Daniel Phillips]

On Tuesday 22 May 2001 16:42, john slee wrote:
> On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote:
> > On Mon, 21 May 2001, Eric S. Raymond wrote:
> > > the NEW tag).  That phase ended almost a month ago.  Nobody who
> > > has actually tried the CML2 tools more recently has reported that
> > > the UI changes present any difficulty.
> >
> > What happened with the discussion on configurable colors in make
> > menuconfig? Darkblue on black as frozen options get isn't exactly
> > optimal ... at least not for my eyes. Being next to a bold, white
> > text doesn't help either.
>
> if you don't like dark blue on black, change your terminal colours.
> then you won't find it hard to read in other applications either.

On the first day of my graduate course 'Advanced Topics in Computer
Graphics' the professor walked in and wrote on the blackboard "Never
Use Blue on Black".

Yes, we had blackboards then.  No, our eyes have not evolved since
then. ;-)

--
Daniel

Re: Background to the argument about CML2 design philosophy

[Wayne.Brown]

On 05/21/2001 at 12:58:57 esr@thyrsus.com wrote:

>CML2 drops its configuration results in the same place, in the same
>formats, as CML1.  So you should in fact be able to type `make menuconfig'
>and `make oldconfig' with good results.  Have you actually tried this?

No, I haven't tried it yet.  I usually wait for things like this to be included
in Linus' or Alan's kernels before trying them.  In this case, I might have
tried it by now but I only have Python 1.5.2 on my system and don't want to
upgrade it until/unless it's absolutely necessary.  So I probably won't see CML2
until Linus puts it in 2.5.  My comments have been based on your descriptions of
it on lkml.

Wayne