Background to the argument about CML2 design philosophy

Background to the argument about CML2 design philosophy

[Eric S. Raymond]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Nobody had a problem with the SUN3_SCSI derivation.

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

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

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

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

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

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

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

Thankyou for the clarification.

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

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

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

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


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

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

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



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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

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

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

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

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

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

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

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

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

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

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

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

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

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

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

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

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

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

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

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

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

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

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

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

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

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

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

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Arjan van de Ven]

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

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

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

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


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

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

Greetings,
  Arjan van de Ven

Re: Background to the argument about CML2 design philosophy

[Robert M. Love]

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

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

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

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

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

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

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Jes Sorensen]

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

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

[snip derive rules]

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

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

And you suddenly imposed decisions on people.

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

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

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

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

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

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

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

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

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

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

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

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

Jes

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

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

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

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

Re: Background to the argument about CML2 design philosophy

[Ben Bridgwater]

> derive MVME147_SCSI from MVME147 & SCSI

It seems that the preferred semantics would be:

default MVME147_SCSI from MVME147 & SCSI

That way the platform defines sane defaults, but no flexibility has been
taken away.

Presumably many of these defaulted options would also be ones that would
be configured not to be changeable in novice mode. The novice gets the
vanilla platform defaults without being bothered by detailed options,
and can switch to expert mode if they need more control. The experts get
all the options presented, but also get to benefit from the smart
platform defaults.

Ben

Re: Background to the argument about CML2 design philosophy

[Nicolas Pitre]

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

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

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

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

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

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

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

Now you protest with:

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

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


Nicolas

Re: Background to the argument about CML2 design philosophy

[Nicolas Pitre]

On 20 May 2001, Robert M. Love wrote:

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

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


Nicolas

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Helge Hafting]

"Eric S. Raymond" wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Helge Hafting

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

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

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

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

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

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

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

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

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

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

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

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

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

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

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

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

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

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

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

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

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

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

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

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Alan Cox]

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

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

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

which are a lot more useful. 

Names matter a lot 

Re: Background to the argument about CML2 design philosophy

[Wayne.Brown]

On 05/21/2001 at 05:04:40 AM esr@thyrsus.com wrote:

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

I probably qualify as one of the bellyachers.  If so, I apologize.  It was not
my intention to disparage the work of Eric or anyone else involved in this
project.

Speaking from the perspective of a user of the CML tools, rather than as a
developer, all I've been trying to say is this:  When I type "make menuconfig"
or "make oldconfig" in the future, I want to see the same interface and the same
results that I've always seen, because it's always worked for me in the past.
It really doesn't matter to me if, down underneath, this is being done by CML1,
CML2, or a little man in my computer who slaughters chickens and reads their
entrails for omens to determine dependencies.  Right now I can grab a new -pre
or -ac patch, use oldconfig, and have a compile going in a few minutes, without
knowing or caring about the details of the config process.  In the rare case
that a patch breaks an existing driver, it takes only a couple of minutes with
menuconfig to disable that driver and compile without it, and then put it back
in when it's fixed.  And when, every once in a great while, I decide to scrap my
.config and start over, I can fly through all the menuconfig options very
quickly and make my customary selections almost without thinking about it.

I just want to be able to keep using the tools in this way.  If that's not going
to be possible... well, I'll adapt.  But from my point of view, learning a new
set of tools just to keep doing the same things I've always done isn't a
pleasant prospect.  I understand that changes may be necessary to meet others'
needs, but I'd like to see those changes made without affecting the way my own
needs are met.

I'm off my soapbox now and won't bellyache about it any further.

Wayne

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Wayne.Brown@altec.com <Wayne.Brown@altec.com>:
> Speaking from the perspective of a user of the CML tools, rather
> than as a developer, all I've been trying to say is this: When I
> type "make menuconfig" or "make oldconfig" in the future, I want to
> see the same interface and the same results that I've always seen,
> because it's always worked for me in the past.

Visual details will differ, but I've been careful about maintaining
functional compatibility.  There was a phase of the development during
which I was mostly processing feature requests from people who wanted
features of the old system that I had not properly understood (such as
the NEW tag).  That phase ended almost a month ago.  Nobody who has
actually tried the CML2 tools more recently has reported that the UI
changes present any difficulty.

CML2 drops its configuration results in the same place, in the same
formats, as CML1.  So you should in fact be able to type `make menuconfig'
and `make oldconfig' with good results.  Have you actually tried this?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The right of the citizens to keep and bear arms has justly been considered as
the palladium of the liberties of a republic; since it offers a strong moral
check against usurpation and arbitrary power of rulers; and will generally,
even if these are successful in the first instance, enable the people to resist
and triumph over them."
        -- Supreme Court Justice Joseph Story of the John Marshall Court

Re: Background to the argument about CML2 design philosophy

[Wayne.Brown]

On 05/21/2001 at 12:58:57 esr@thyrsus.com wrote:

>CML2 drops its configuration results in the same place, in the same
>formats, as CML1.  So you should in fact be able to type `make menuconfig'
>and `make oldconfig' with good results.  Have you actually tried this?

No, I haven't tried it yet.  I usually wait for things like this to be included
in Linus' or Alan's kernels before trying them.  In this case, I might have
tried it by now but I only have Python 1.5.2 on my system and don't want to
upgrade it until/unless it's absolutely necessary.  So I probably won't see CML2
until Linus puts it in 2.5.  My comments have been based on your descriptions of
it on lkml.

Wayne

Re: Background to the argument about CML2 design philosophy

[Urban Widmark]

On Mon, 21 May 2001, Eric S. Raymond wrote:

> the NEW tag).  That phase ended almost a month ago.  Nobody who has
> actually tried the CML2 tools more recently has reported that the UI
> changes present any difficulty.

What happened with the discussion on configurable colors in make
menuconfig? Darkblue on black as frozen options get isn't exactly optimal
... at least not for my eyes. Being next to a bold, white text doesn't
help either.


> CML2 drops its configuration results in the same place, in the same
> formats, as CML1.  So you should in fact be able to type `make menuconfig'
> and `make oldconfig' with good results.  Have you actually tried this?

It works for me, but anyone testing this should know that the CML2 tools
read "config.out" if it finds one. So people that do things like:

make mrproper ; cp ../.config-2.4 .config ; make oldconfig

will have to change to copying config.out instead. Doing like this sort of
works* if there is no config.out, otherwise it does not (as it uses the
config.out).

Saying that the config result ends up in the same place and same format is
somewhat misleading, you do get a copy in the CML1 output format but the
tools doesn't care about that if it can find a file in the new format.

*) "Sort of works", since doing like I do will cause you to get a lot of
questions that you have already answered. That appears to be a one-time
problem as 'oldconfig' does not read "# CONFIG_FOO is not set" as "no".
Would be nice if it did.


make mrproper doesn't remove config.out. It should since that's what it
does with .config* files. Not sure if it should remove the rules.out file
also, but I think it should as the idea(?) with mrproper is to clean up
anything that is generated.

/Urban

Re: Background to the argument about CML2 design philosophy

[John Stoffel]

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

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

     *some* developers prefer it.  Not all. 

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

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

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

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

David> CONFIG_AUNT_TILLIE does not require CML2.

Correct.

David> CML2 does not require CONFIG_AUNT_TILLIE.

Correct.  And never has offered it either!

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

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

- the existing interface of vi .config; make oldconfig

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

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

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


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

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

John

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

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

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

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

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

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

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[Jonathan Morton]

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

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

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

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

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

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

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

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

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: Background to the argument about CML2 design philosophy

[Keith Owens]

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

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

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

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

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

Urban Widmark <urban@teststation.com>:
> What happened with the discussion on configurable colors in make
> menuconfig? Darkblue on black as frozen options get isn't exactly optimal
> ... at least not for my eyes. Being next to a bold, white text doesn't
> help either.

Nobody could come up with a way to support configurable colors that didn't seem
like way more trouble than it was worth.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

  "...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
        -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),

Re: Background to the argument about CML2 design philosophy

[Daniel Phillips]

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

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

"No news is good news".

--
Daniel

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

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

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

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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[john slee]

On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote:
> On Mon, 21 May 2001, Eric S. Raymond wrote:
> 
> > the NEW tag).  That phase ended almost a month ago.  Nobody who has
> > actually tried the CML2 tools more recently has reported that the UI
> > changes present any difficulty.
> 
> What happened with the discussion on configurable colors in make
> menuconfig? Darkblue on black as frozen options get isn't exactly optimal
> ... at least not for my eyes. Being next to a bold, white text doesn't
> help either.

if you don't like dark blue on black, change your terminal colours.
then you won't find it hard to read in other applications either.

it's also far less effort this way...

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Background to the argument about CML2 design philosophy

[John Stoffel]

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

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

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

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

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

Agreed.

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

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

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

Such as what?  Do you have any examples here?  

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

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

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

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

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

Thanks,
John

Re: Background to the argument about CML2 design philosophy

[David Woodhouse]

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

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

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

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

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

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

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

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

--
dwmw2

Re: Background to the argument about CML2 design philosophy

[Daniel Phillips]

On Tuesday 22 May 2001 16:42, john slee wrote:
> On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote:
> > On Mon, 21 May 2001, Eric S. Raymond wrote:
> > > the NEW tag).  That phase ended almost a month ago.  Nobody who
> > > has actually tried the CML2 tools more recently has reported that
> > > the UI changes present any difficulty.
> >
> > What happened with the discussion on configurable colors in make
> > menuconfig? Darkblue on black as frozen options get isn't exactly
> > optimal ... at least not for my eyes. Being next to a bold, white
> > text doesn't help either.
>
> if you don't like dark blue on black, change your terminal colours.
> then you won't find it hard to read in other applications either.

On the first day of my graduate course 'Advanced Topics in Computer
Graphics' the professor walked in and wrote on the blackboard "Never
Use Blue on Black".

Yes, we had blackboards then.  No, our eyes have not evolved since
then. ;-)

--
Daniel

Re: Background to the argument about CML2 design philosophy

[Eric S. Raymond]

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

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

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

Re: Background to the argument about CML2 design philosophy

[Keith Owens]

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

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