Re: CML2 design philosophy heads-up

Re: CML2 design philosophy heads-up

[Pete Zaitcev]

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

I always do "vi .config", then "make oldconfig", because it is very
convinient, simple, and flexible way to do it. For instance, it is
very easy to store a pile of configs for different kernels, very
easy do diff them (with -u and without).

I do not have Python installed on any of my machines.

The right way to handle the CML2 problem, IMHO, is to have a
C implementation of Python part without curses, tcl, and other crap.
Half of ESR's justification is "dynatic loading of components and
recovery from failure to load them", which goes away if we
do not support extras like curses. Another half was GC, which
is just a convinience for a project of CML's size.

-- Pete

Re: CML2 design philosophy heads-up

[Matthew Wilcox]

Eric S. Raymond wrote:
> 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.

Eric, you're trying to do too much too quickly.  Wait until 2.5 to clean
stuff up.  That's what the rest of us have to do, even for some things
which are real bugs rather than infelicities in the current design.
You can't treat this as an all-or-nothing deal.  Some of your ideas for
CML2 are right, and some aren't.  Get the non-controversial bits in,
then fight over the ideas that're worth fighting for.

Yes, CML2 enables a more task-based than hardware-based approach, and
I think that's generally a good thing; but I do believe that this isn't
going to be suitable for everyone.  Let's work up to it gradually.

-- 
  One of the most insidious things the CIA Communists did when they took
over Unistat was to change the Constitution.
  The original Constitution, having been written by a group of
intellectual libertines and Freemasons in the eighteenth century,
included an amendment which declared:
      A self-regulated sex life being necessary to the happiness of a
      citizen, the right of people to keep and enjoy pornography shall not
      be abridged.
  This amendment had been suggested by Thomas Jefferson, who had over nine
hundred Black concubines, and Benjamin Franklin, a member of the Hell
Fire Club, which had the largest collection of erotic books and art in
the Western world at that time.
  The Communists changed the amendment to read:
      A well-regulated militia being necessary to the security of a free
      state, the right of the citizens to keep and bear arms shall not
      be abridged.
  All documents and textbooks were changed, so that nobody would be able
to find out what the amendment had originally said.  Then the Communists
set up a front organisation, the National Rifle Association, to encourage
the wide usage of guns of all sorts and to battle any attempt to control
guns as "unconstitutional."
  Thus, they guaranteed that the murder rate in Unistat would always be
the highest in the world.  This kept the citizens in perpetual anxiety
about their safety both on the streets and in their homes.  The citizens
then tolerated the rapid growth of the Police State, which controlled
almost everything, except the sale of guns, the chief cause of crime.

-- Robert Anson Wilson in the Schroedinger's Cat Trilogy

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

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

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