LinuxLists.cc - CML2-2.1.3 is available

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

> The interactive configurators remain stable; no bugs of any kind have been
> reported since 6 Jan. I'm waiting on an update of the probe tables from
> Giacomo Catenazzi before releasing 2.2.0.

I tried CML2 (2.1.2) yesterday with Linux 2.4.17 and found that I couldn't turn
on suppression ('S' didn't seem to toggle, only disable suppression, which was
already off) and entering into a submenu marked FROZEN locked up the
configurator.

It seems the second issue is related to the first; if I move off of the "Inter
or Processor type (FROZEN)" selection, I'm not allowed to go back and select it.
However, when just starting, it is the default selection.

If I then press 'S' I get the "Suppression turned off" message, but still cannot
move the selection back onto "Intel or Processor type (FROZEN)". CTRL-C gets me
back to a prompt, no other keys initiated a response.

I'm using Python 2.0.1 with Slackware 8.

Ross Vandegrift
[email protected]

2002-01-15 20:34:10

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Nicolas Pitre <[email protected]>:
> > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> > * The `vitality' flag is gone from the language. Instead, the
> > autoprober detects the type of your root filesystem and forces
> > its symbol to Y.
>
> What happens if you compile a kernel for another machine? Or cross-compile?

In that case you can't use the autoconfigurator anyway. You're going
to have to make sure by hand that the controller, bus type, and file
system code for your root device are hard-compiled in. (This is at
least no worse off than you were under CML1.)

Rob Landley pointed out correctly that the vitality flag was not
actually solving this problem, and it was an ugly wart on the
language. Instead, there's a symbol property "BOOTABLE" in the new
rulebase that is attached to IDE and SCSI hardware symbols that are
controllers for what could be boot devices.

One of the remaining limitations of the autoconfigurator is that it
only knows how to detect IDE and SCSI boot devices. I want to be able
to make it nail NFS and USB storage being used as root, but it's not
there yet.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The American Republic will endure, until politicians realize they can
bribe the people with their own money.
-- Alexis de Tocqueville

2002-01-15 20:41:22

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Anton Altaparmakov <[email protected]>:
> </me ignorant of current state of cml2>I sometimes configure and compile
> kernels for different computers on my athlon due to the extremely fast
> compile time on the athlon. The autoprober would interfere here extremely
> badly. Is it disabled by default? I.e. if I do make menuconfig or make
> oldconfig will the autoprober temper with my choices?

Absolutely not.

To invoke the autoconfigurator, you do one of two things:

`make autoconfigure'
This runs the autoconfigurator in standalone mode. This gives you
an entire configuration, ready to build with.

`make autoprobe {config,menuconfig,xconfig}'
This runs the autoconfigurator in probe mode, which gives you
a report on facilities found (without making assumptions about facilities
not found). This report gets fed to your interactive configurator, which
then proceeds not to bother you with questions for which the autoprobe
report already gave it answers.

The ordinary make {config,menuconfig,xconfig} behaves as it always did.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

If we believe absurdities, we shall commit atrocities.
-- Voltaire

2002-01-15 20:42:00

by Nicolas Pitre

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tue, 15 Jan 2002, Eric S. Raymond wrote:

> Nicolas Pitre <[email protected]>:
> > > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> > > * The `vitality' flag is gone from the language. Instead, the
> > > autoprober detects the type of your root filesystem and forces
> > > its symbol to Y.
> >
> > What happens if you compile a kernel for another machine? Or cross-compile?
>
> In that case you can't use the autoconfigurator anyway.

Sorry. I passed over "autoprober" too fast. As long as auto* stuff can
be turned off that fine.

Nicolas

2002-01-15 21:10:50

by David Lang

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tue, 15 Jan 2002, Eric S. Raymond wrote:

> * The `vitality' flag is gone from the language. Instead, the
> autoprober detects the type of your root filesystem and forces
> its symbol to Y.

can you override this autodetect? (it may not be valid if you are building
on one machine for another)

David Lang

2002-01-16 00:15:57

by Henning P. Schmiedehausen

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

"Eric S. Raymond" <[email protected]> writes:

>Rob Landley pointed out correctly that the vitality flag was not
>actually solving this problem, and it was an ugly wart on the
>language. Instead, there's a symbol property "BOOTABLE" in the new
>rulebase that is attached to IDE and SCSI hardware symbols that are
>controllers for what could be boot devices.

Wasn't this SunOS (Larry?): "Can't boot a typewriter."

Actually, some can. Or maybe their current incarnation, the serial port.

Will you make every thinkable device "BOOTABLE"? USB?

Regards
Henning

--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20

2002-01-16 00:39:07

by Peter Samuelson

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

[esr]
> > * The `vitality' flag is gone from the language. Instead, the
> > autoprober detects the type of your root filesystem and forces
> > its symbol to Y.

[Russell King]
> This seems like a backwards step. What's the reasoning for breaking
> the ability to configure the kernel for a completely different
> machine to the one that you're running the configuration/build on?

As Eric keeps saying - autoconfigure is OPTIONAL. It is merely one way
to generate a .config, not the only way.

> Answers including Aunt Tillies or Penelopes won't be accepted. 8)

(:

Peter

2002-01-16 03:42:01

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tuesday 15 January 2002 03:41 pm, Nicolas Pitre wrote:
> On Tue, 15 Jan 2002, Eric S. Raymond wrote:
> > Nicolas Pitre <[email protected]>:
> > > > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> > > > * The `vitality' flag is gone from the language. Instead, the
> > > > autoprober detects the type of your root filesystem and forces
> > > > its symbol to Y.
> > >
> > > What happens if you compile a kernel for another machine? Or
> > > cross-compile?
> >
> > In that case you can't use the autoconfigurator anyway.
>
> Sorry. I passed over "autoprober" too fast. As long as auto* stuff can
> be turned off that fine.

It's optional.

I -STILL- can't figure out why the autoprober doesn't just look in
/proc/mounts to figure out who and what our root device and filesystem are.

I need to set up a system that boots to an initrd and puts the root device
lives on a samba server just to confuse eric's autoprober. Hmmm... I wonder
if that would work? :)

Rob

2002-01-16 03:45:33

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tuesday 15 January 2002 03:24 pm, Eric S. Raymond wrote:

> To invoke the autoconfigurator, you do one of two things:
>
> `make autoconfigure'
> This runs the autoconfigurator in standalone mode. This gives you
> an entire configuration, ready to build with.
>
> `make autoprobe {config,menuconfig,xconfig}'
> This runs the autoconfigurator in probe mode, which gives you
> a report on facilities found (without making assumptions about facilities
> not found). This report gets fed to your interactive configurator, which
> then proceeds not to bother you with questions for which the autoprobe
> report already gave it answers.
>
> The ordinary make {config,menuconfig,xconfig} behaves as it always did.

Eric and I disagree on the behavior of "make autoprobe". He likes the
concept of "freezing" symbols, which says if the autoprober detected a
configuration setting, the question shouldn't show up and give you the
opportunity to disagree. (Not confusing Aunt Tillie, with her LCSE from
CompTIA (and apparently has recently moved in with Alan Cox), with questions
that she's more likely to screw up than improve.)

Personally, I think that if you turn on "expert" mode, you should be able to
override anything. I haven't complained much because there is an easy
workaround: Although the autoprober puts the "frozen" flag on the symbols it
finds, menuconfig doesn't save them out :). So just run menuconfig twice and
you can edit everything that got autoprobed...

The user interface still has a couple of teething troubles, but they're
mostly in the new stuff that CML1 never attempted to do (like autoconfig).

(Now the standard configuration DOES freeze, and therefore hide, the "which
architecture am I building for" question. It would be nice if "make
menuconfig" would let you do a cross-compile simply by selecting your
architecture. I understand why this isn't supported though: to properly
build most architectures other than X86, you have to apply patches to Linus's
tree. And the make would have to tell gcc to cross-compile, which most gcc
builds don't know how to do and the makefiles don't seem to support
anyway...)

Rob

2002-01-16 03:45:34

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tuesday 15 January 2002 03:25 pm, Russell King wrote:
> On Tue, Jan 15, 2002 at 02:53:24PM -0500, Eric S. Raymond wrote:
> > * The `vitality' flag is gone from the language. Instead, the
> > autoprober detects the type of your root filesystem and forces
> > its symbol to Y.
>
> This seems like a backwards step. What's the reasoning for breaking the
> ability to configure the kernel for a completely different machine to the
> one that you're running the configuration/build on?

He didn't. If you want to do that, run "make menuconfig" instead of "make
autoconfigure".

Autoprobing is just another tool at your disposal, you don't have to use it.
And you can probe for your hardware and then menuconfig what it found (run
"make autoconfig menuconfig"., and see my previous post for a small gripe
about this. :)

> Answers including Aunt Tillies or Penelopes won't be accepted. 8)

Trust me, if I thought there was ANY code I could write that would make cute
single women start using the Linux kernel en masse...

Right now I'm going for reformed MCSEs who are still largely clueless but now
have Linux+ certification and a boss who wants to spend his department's six
figure budget on something OTHER than a microsoft audit. Autoprobing might
help us convert a few of that crowd.

Rob

2002-01-16 04:04:55

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Rob Landley <[email protected]>:
> I -STILL- can't figure out why the autoprober doesn't just look in
> /proc/mounts to figure out who and what our root device and filesystem are.

The version I just released does exactly that. Well, not exactly; it
actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
than a physical device name in the root entry.

> I need to set up a system that boots to an initrd and puts the root
> device lives on a samba server just to confuse eric's autoprober.
> Hmmm... I wonder if that would work? :)

No. It only knows about IDE and SCSI root devices at the moment. As I
learn how to identify other kinds of root volume it will get smarter.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The IRS has become morally corrupted by the enormous power which we in
Congress have unwisely entrusted to it. Too often it acts like a
Gestapo preying upon defenseless citizens.
-- Senator Edward V. Long

2002-01-16 04:15:36

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Rob Landley <[email protected]>:
> Eric and I disagree on the behavior of "make autoprobe". He likes the
> concept of "freezing" symbols, which says if the autoprober detected a
> configuration setting, the question shouldn't show up and give you the
> opportunity to disagree. (Not confusing Aunt Tillie, with her LCSE from
> CompTIA (and apparently has recently moved in with Alan Cox), with questions
> that she's more likely to screw up than improve.)

Note, everyone else, that the freezing only happens on "make autoprobe".
The config.out that "make autoconfigure" writes is not frozen.

> Personally, I think that if you turn on "expert" mode, you should be
> able to override anything. I haven't complained much because there
> is an easy workaround: Although the autoprober puts the "frozen"
> flag on the symbols it finds, menuconfig doesn't save them out :).

Correction: menuconfig *does* save out frozen symbols, but it saves
them unfrozen.

> So just run menuconfig twice and you can edit everything that got
> autoprobed...

This "workaround" is entirely intentional.

> (Now the standard configuration DOES freeze, and therefore hide, the
> "which architecture am I building for" question. It would be nice
> if "make menuconfig" would let you do a cross-compile simply by
> selecting your architecture. I understand why this isn't supported
> though: to properly build most architectures other than X86, you
> have to apply patches to Linus's tree. And the make would have to
> tell gcc to cross-compile, which most gcc builds don't know how to
> do and the makefiles don't seem to support anyway...)

Actually, this kind of cross-configuration is already fully supported.
The normal way of calling the configurator, through the Makefile,
passes -D$(ARCH) -- but if you call it without an architecture symbol
frozen by command-line option, architecture will be the first question
you're asked.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

All forms of government are pernicious, including good government.
-- Edward Abbey

2002-01-16 04:18:46

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Ross Vandegrift <[email protected]>:
> I tried CML2 (2.1.2) yesterday with Linux 2.4.17 and found that I
> couldn't turn on suppression ('S' didn't seem to toggle, only
> disable suppression, which was already off) and entering into a
> submenu marked FROZEN locked up the configurator.

I'd sure like to know how you managed this. Since 2.1.2 frozen symbols
are no longer supposed to be visible at all. Can you reproduce this?
Can you give me the recipe for reproducing it?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill. -- H. L. Mencken

2002-01-16 06:30:34

by Peter Samuelson

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

[esr]
> The version I just released does exactly that. Well, not exactly; it
> actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
> than a physical device name in the root entry.

/etc/fstab is hardly guaranteed to be accurate either. The kernel
mounts the root device based on its command line and any pivot_root()
calls you make, not based on /etc/fstab.

[In practice, I imagine most people don't lie to fstab. The fsck init
script would get annoyed.]

But the horse's mouth, in this case, is /proc/sys/kernel/real-root-dev,
a 16-bit decimal int which represents a device number in
MAJOR*256+MINOR format. There *may* also the 'root=' asciiz string in
/proc/cmdline, which will be a 4-digit hex number, but that is not
reliable - because of pivot_root() among other things.

On my system, real-root-dev gives 8453, which means /dev/hde5, which is
on ide2. According to /proc/ide/ide2/config, it is a PCI device of
type 105a:4d30 [Promise Ultra100], so you can derive
CONFIG_BLK_DEV_PDC202XX as well as CONFIG_BLK_DEV_IDEDISK.

Peter

2002-01-16 06:36:34

by Alexander Viro

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Wed, 16 Jan 2002, Peter Samuelson wrote:

> But the horse's mouth, in this case, is /proc/sys/kernel/real-root-dev,
> a 16-bit decimal int which represents a device number in

... and is there only if initrd is compiled in.

2002-01-16 06:49:37

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Peter Samuelson <[email protected]>:
> > The version I just released does exactly that. Well, not exactly; it
> > actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
> > than a physical device name in the root entry.
>
> /etc/fstab is hardly guaranteed to be accurate either. The kernel
> mounts the root device based on its command line and any pivot_root()
> calls you make, not based on /etc/fstab.
>
> [In practice, I imagine most people don't lie to fstab. The fsck init
> script would get annoyed.]

Agreed. The root device getting overridden by either of these means
is well into the territory an autoconfigurator cannot be reasonably
expected to cover.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill. -- H. L. Mencken

2002-01-16 07:14:20

by Peter Samuelson

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Forgot this point earlier..

[esr]
> > > The version I just released does exactly that. Well, not exactly; it
> > > actually looks at fstab -- /proc/mounts gives you '/dev/root' rather
> > > than a physical device name in the root entry.

IMHO you should still use /proc/mounts to determine the root filesystem
type. In my fstab file I don't mention ext3 anywhere - I use 'auto' as
fs type instead. That way my ext3 partitions will mount correctly when
I boot a non-ext3-capable kernel. (They mount as ext2 in that case.)

Peter

2002-01-16 16:39:02

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tue, Jan 15, 2002 at 11:02:11PM -0500, Eric S. Raymond wrote:
> Ross Vandegrift <[email protected]>:
> > I tried CML2 (2.1.2) yesterday with Linux 2.4.17 and found that I
> > couldn't turn on suppression ('S' didn't seem to toggle, only
> > disable suppression, which was already off) and entering into a
> > submenu marked FROZEN locked up the configurator.
>
> I'd sure like to know how you managed this. Since 2.1.2 frozen symbols
> are no longer supposed to be visible at all. Can you reproduce this?
> Can you give me the recipe for reproducing it?

Here's what I do to reproduce it:

$ tar yxvf linux-2.4.17.tar.bz2
...
$ cd cml2-2.1.2
$ ./install-cml2 /home/ross/linux
Examining your build environment...
Good. You have Python 2.x installed as 'python' already.
Python looks sane...
Good, your python has curses support linked in.
Good, your python has Tk support linked in.
Compiling file list...
Operating on /home/ross/linux...
Installing new files...
Merging in CML2 help texts from Configure.help...
Modifying configuration productions...
You are ready to go, cd to /home/ross/linux.
$ cd ../linux
$ make config

At this point the rules are compiled and a dialog box indicates that
Suppression has been turned off (press any key to continue). I hit any key and
am presented with the first menu.

The first selection at the top of the screen is "Intel or Processor type
(FROZEN)" and it is highlighted as the default selection. If I press enter
*boom*, I'm locked solid. If I move the active selection off of this menu item,
I can't move back to it, though it remains visible. If I enter a submenu, the
frozen processor type menu is gone.

It's reproduceable with fresh trees (as above), existing trees, and at least
linux 2.4.12 and linux 2.4.17 (the two kernel tarballs I have lying around).

I'm planning on trying this on a Debian testing box I have at work at some
point.

Ross Vandegrift
[email protected]

2002-01-16 16:59:34

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Wed, Jan 16, 2002 at 11:38:40AM -0500, Ross Vandegrift wrote:
[snip]
> I'm planning on trying this on a Debian testing box I have at work at some
> point.

Just verified the same process works on Debian testing, as well as with
cml2-2.1.3.

Ross Vandegrift
[email protected]

2002-01-16 21:48:09

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Horst von Brand <[email protected]>:
> > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> > * Resync with 2.4.18-pre3 and 2.5.2.
> > * It is now possible to declare explicit saveability predicates.
> > * The `vitality' flag is gone from the language. Instead, the
> > autoprober detects the type of your root filesystem and forces
> > its symbol to Y.
>
> Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it
> up! As it goes, we can safely forget about CML2...

Oh, nonsense. You can do this just fine with any of the manual configurators.
Now repeat after me, Horst:

The autoconfigurator is *optional*, not required.

The autoconfigurator is *optional*, not required.

The autoconfigurator is *optional*, not required.

The autoconfigurator is *optional*, not required.

The autoconfigurator is *optional*, not required.

: : : : :

Please continue until insight penetrates your skull. Thank you.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
-- Robert A. Heinlein, "Time Enough for Love"

2002-01-16 21:40:21

by Horst von Brand

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

"Eric S. Raymond" <[email protected]> said:
> The latest version is always available at <http://www.tuxedo.org/~esr/cml2/>.
>
> Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> * Resync with 2.4.18-pre3 and 2.5.2.
> * It is now possible to declare explicit saveability predicates.
> * The `vitality' flag is gone from the language. Instead, the
> autoprober detects the type of your root filesystem and forces
> its symbol to Y.

Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it
up! As it goes, we can safely forget about CML2...
--
Horst von Brand http://counter.li.org # 22616

2002-01-16 21:57:29

by Horst von Brand

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

"Eric S. Raymond" <[email protected]> said:
> Horst von Brand <[email protected]>:
> > > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> > > * Resync with 2.4.18-pre3 and 2.5.2.
> > > * It is now possible to declare explicit saveability predicates.
> > > * The `vitality' flag is gone from the language. Instead, the
> > > autoprober detects the type of your root filesystem and forces
> > > its symbol to Y.
> >
> > Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it
> > up! As it goes, we can safely forget about CML2...
>
> Oh, nonsense. You can do this just fine with any of the manual
> configurators.

Whatever happened to "Do exactly as CML1 does; leave fixes and extensions
for later"? If you put the kitchen sink into it, it _won't_ go into the
standard kernel.

> Now repeat after me, Horst:
>
> The autoconfigurator is *optional*, not required.

It isn't "optional", it is builtin. It doesn't matter if somebody uses it
or nobody does, it will be there. And AFAIU what you have said, you are
modifiying CML2 (or at least the rulebase) for the sake of it. This is
_not_ what had been agreed on the matter.
--
Horst von Brand http://counter.li.org # 22616

2002-01-16 22:04:33

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Horst von Brand <[email protected]>:
> Whatever happened to "Do exactly as CML1 does; leave fixes and extensions
> for later"? If you put the kitchen sink into it, it _won't_ go into the
> standard kernel.

If you stick to the CML1-equivalent facilities, you'll get almost
CML1-equivalent behavior. It's "almost" partly because the hardware symbols
have more platform- and bus-type guards than they used to -- but mostly
because I have not emulated the numerous CML1 bugs.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The people cannot delegate to government the power to do anything
which would be unlawful for them to do themselves.
-- John Locke, "A Treatise Concerning Civil Government"

2002-01-16 23:37:28

by David Lang

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Eric, the way you worded the change report it sounded to many of us as if
you were making the autoprober mandatory for detecting the root
filesystem.

That's why it spawned so many messages like this (including one from me
yesterday)

you should have added something in the changelog entry that said that this
autoprobe only happened when you do an autoconfigure, as it is it implies
that is is for every variaty of make *config.

I understand why you are frustrated with the response, but it's not a case
of people having thick skulls it's a case of you leaving out critical info
from you changelog so people reading it without your mindset see it saying
something that you didn't mean.

remember most of us have no idea why the 'vitality' flag was there in the
first place so we can't imply a limit on the autoprober that is replacing
it.

David Lang

On Wed, 16 Jan 2002, Eric S. Raymond wrote:

> Date: Wed, 16 Jan 2002 16:31:44 -0500
> From: Eric S. Raymond <[email protected]>
> To: Horst von Brand <[email protected]>
> Cc: [email protected], [email protected]
> Subject: Re: CML2-2.1.3 is available
>
> Horst von Brand <[email protected]>:
> > > Release 2.1.3: Tue Jan 15 14:41:45 EST 2002
> > > * Resync with 2.4.18-pre3 and 2.5.2.
> > > * It is now possible to declare explicit saveability predicates.
> > > * The `vitality' flag is gone from the language. Instead, the
> > > autoprober detects the type of your root filesystem and forces
> > > its symbol to Y.
> >
> > Great! Now I can't configure a kernel for ext3 only on an ext2 box. Keep it
> > up! As it goes, we can safely forget about CML2...
>
> Oh, nonsense. You can do this just fine with any of the manual configurators.
> Now repeat after me, Horst:
>
> The autoconfigurator is *optional*, not required.
>
> The autoconfigurator is *optional*, not required.
>
> The autoconfigurator is *optional*, not required.
>
> The autoconfigurator is *optional*, not required.
>
> The autoconfigurator is *optional*, not required.
>
> : : : : :
>
> Please continue until insight penetrates your skull. Thank you.
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> A human being should be able to change a diaper, plan an invasion,
> butcher a hog, conn a ship, design a building, write a sonnet, balance
> accounts, build a wall, set a bone, comfort the dying, take orders, give
> orders, cooperate, act alone, solve equations, analyze a new problem,
> pitch manure, program a computer, cook a tasty meal, fight efficiently,
> die gallantly. Specialization is for insects.
> -- Robert A. Heinlein, "Time Enough for Love"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2002-01-17 01:18:48

by Valerie Henson

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Tue, Jan 15, 2002 at 02:37:57PM -0500, Rob Landley wrote:
> > Answers including Aunt Tillies or Penelopes won't be accepted. 8)
>
> Trust me, if I thought there was ANY code I could write that would make cute
> single women start using the Linux kernel en masse...

The above comment is a good example of one reason cute single women
tend not to use Linux.

-VAL

2002-01-17 01:26:26

by David Woodhouse

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

[email protected] said:
> If you stick to the CML1-equivalent facilities, you'll get almost
> CML1-equivalent behavior. It's "almost" partly because the hardware
> symbols have more platform- and bus-type guards than they used to --
> but mostly because I have not emulated the numerous CML1 bugs.

I'm concerned by the 'platform- and bus-type guards' to which you refer.
Could you give some examples where the behaviour has changed? Lots of
embedded non-x86, non-ISA boxen have ISA network chips glued in somehow,
for example. I hope you haven't helpfully stopped that from working.

--
dwmw2

2002-01-17 02:00:39

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

David Woodhouse <[email protected]>:
> I'm concerned by the 'platform- and bus-type guards' to which you refer.
> Could you give some examples where the behaviour has changed? Lots of
> embedded non-x86, non-ISA boxen have ISA network chips glued in somehow,
> for example. I hope you haven't helpfully stopped that from working.

No, I haven't.

Wha's happened is that I, and others, have merged in a lot of information
about what cards can be plugged into which platforms. That information
has been turned into dependency/visibility rules.

The generic hardware that can be used on several platforms has bus guards.
The on-board hardware has platform guards. Some cards that can only be used
in single-platform buses have platform guards as well.

Here are some examples from the network cards...

Bus guards:

unless MCA suppress dependent ELMC ELMC_II ULTRAMCA SKMC NE2_MCA IBMLANA
unless ISA_CLASSIC suppress EL1 EL2 ELPLUS EL16 WD80x3 APOLLO_ELPLUS unless ISA_PNP suppress CONFIG_3C515
unless EISA suppress dependent LNE390 NE3210
unless ISA_CLASSIC or EISA suppress AC3200
unless ISA_CLASSIC or ISA_PNP!=n or EISA or MCA suppress EL3 # 3c509 source
unless EISA or PCI or CARDBUS!=n suppress VORTEX # Vortex help screen
unless ISA_CLASSIC or ISA_PNP!=n or PCI suppress LANCE # Lance source
unless SPARC or SPARC64 suppress SUNLANCE
unless EISA suppress dependent ULTRA32 # SMC-ULTRA32
unless PCI suppress dependent
PCNET32 DE2104X TULIP EEPRO100 NE2K_PCI CONFIG_8139TOO CONFIG_8139TOO_8129
WINBOND_840 HAPPYMEAL ADAPTEC_STARFIRE FEALNX NATSEMI VIA_RHINE EPIC100
SUNDANCE
unless ISA_CLASSIC suppress dependent NI52 NI65
unless EISA or PCI suppress DE4X5 DGRS DM9102 TLAN
unless ISA_CLASSIC or EISA or MCA suppress DEPCA #depca.c
unless ISA_CLASSIC or EISA or MCA suppress HP100
unless ISA_CLASSIC or MCA suppress AT1700 #at1700.c
unless ISA_CLASSIC suppress dependent NI5010 #ni5010.c
unless ISA_CLASSIC suppress dependent E2100 EWRK3 EEXPRESS EEXPRESS_PRO FMV18X
HPLAN HPLAN_PLUS ETH16I SEEQ8005 SK_G16 ES3210 APRICOT
unless ISA_CLASSIC or ISA_PNP suppress NE2000
unless ISA_PNP suppress ULTRA
unless ISA_PNP or CARDBUS suppress I82365

Platform guards:

unless SGI_IP27 or IA64_SGI_SN1 suppress SGI_IOC3_ETH
unless X86 suppress dependent ATP
unless X86 or ALPHA or PPC suppress NET_VENDOR_3COM
unless X86 or ALPHA suppress LANCE NET_VENDOR_SMC NET_VENDOR_RACAL
unless SPARC suppress dependent HAPPYMEAL SUNBMAC SUNQE
unless DECSTATION suppress dependent DECLANCE
unless BAGET_MIPS suppress dependent BAGETLANCE
unless (CONFIG_8xx or CONFIG_8260) suppress SCC_ENET FEC_ENET ENET_BIG_BUFFERS
unless AMIGA and PCMCIA!=n suppress dependent APNE
unless APOLLO suppress dependent APOLLO_ELPLUS
unless MAC suppress dependent MAC8390 MACSONIC SMC9194 MAC89x0 MACMACE CS89x0
unless ATARI suppress dependent ATARILANCE
unless SUN3X or SPARC suppress SUN3LANCE
unless SUN3 suppress dependent SUN3_82586
unless HP300 suppress dependent HPLANCE
unless SUPERH suppress dependent STNIC

Compound bus *and* platform guard:

unless (X86 or ALPHA) and PARPORT!=n suppress dependent NET_POCKET

In a typical situation, you're going to enable platform and bus
symbols early. All these guards will drastically filter the questions
you have to answer later. The overall objective is to reduce the
questions a human user asks to those strictly relevant to his or her
configuration.

Now we're closing in on the second-stage objective, which is to automatically
discover (via an *optional* program...kids, remember that word *optional*)
so much about the configuration that the user need only answer questions
that are genuinely about policy and capabilities.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The conclusion is thus inescapable that the history, concept, and
wording of the second amendment to the Constitution of the United
States, as well as its interpretation by every major commentator and
court in the first half-century after its ratification, indicates
that what is protected is an individual right of a private citizen
to own and carry firearms in a peaceful manner.
-- Report of the Subcommittee On The Constitution of the Committee On
The Judiciary, United States Senate, 97th Congress, second session
(February, 1982), SuDoc# Y4.J 89/2: Ar 5/5

2002-01-17 02:32:02

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On Wednesday 16 January 2002 11:38 am, Ross Vandegrift wrote:
>
> At this point the rules are compiled and a dialog box indicates that
> Suppression has been turned off (press any key to continue). I hit any key
> and am presented with the first menu.

Ah, I understand the bug.

That dialog indicates that your existing .config (the one it loaded the
symbols from) is setting a symbol that is ordinarily suppressed. (One your
dependency list thinks you shouldn't have access to, like a piece of
Alpha-only hardware during an X86 configuration session.)

It found it, noticed that setting it would be inconsistent with the existing
rulebase's dependencies, and let you know that it had to turn suppression off
in order to access it. That's not the bug (although it implies that either
your .config is really weird, or there's a rulebase error suppressing
something that shouldn't be). It just triggers the bug.

Turning off suppression will also make frozen symbols show up, as you
noticed. This is where an old bug I already got Eric to patch resurfaced. :)

The "menu freezing" bug is a menuconfig display problem. It happens because
you can't select a frozen symbol: it skips to the next one when you cursor
over it. If EVERY symbol in the menu is frozen, when you first try to
display the menu it goes into an endless loop trying to figure our what
symbol to put the cursor on.

I told Eric about this earlier, and he hid all the frozen symbols (which he
intended to do anyway). A menu with no visible symbols won't show up.

But when you turn off suppression, the menu gets unhidden, and the bug comes
back.

Eric, you wanna take another swing at it?

Rob

2002-01-17 08:54:33

by David Woodhouse

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

[email protected] said:
> Wha's happened is that I, and others, have merged in a lot of
> information about what cards can be plugged into which platforms.
> That information has been turned into dependency/visibility rules.

> Here are some examples from the network cards...

Hmmm, yes. I think I see at least two errors in that small selection, if I
understand it correctly. But as these are obviously behavioural changes, and
you've said you won't make behavioural changes in the first push of CML2 to
Linus, we can safely ignore them for now - they're lined up for your second
wave of patches, right?

This is why the behavioural changes must be separate from the initial
conversion, btw. They _do_ need separate attention from the gruntwork of
translating CML1 to CML2.

--
dwmw2

2002-01-17 13:55:01

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

David Woodhouse <[email protected]>:
> Hmmm, yes. I think I see at least two errors in that small selection, if I
> understand it correctly.

Please help me correct them.

> But as these are obviously behavioural changes, and
> you've said you won't make behavioural changes in the first push of CML2 to
> Linus, we can safely ignore them for now - they're lined up for your second
> wave of patches, right?

The definition of "behavioral change" you're implying here is so narrow that
if I interpreted the "agreement" that way", CML2 could do nothing worthwhile.

Get real, please.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The danger (where there is any) from armed citizens, is only to the
*government*, not to *society*; and as long as they have nothing to
revenge in the government (which they cannot have while it is in their
own hands) there are many advantages in their being accustomed to the
use of arms, and no possible disadvantage.
-- Joel Barlow, "Advice to the Privileged Orders", 1792-93

2002-01-17 14:10:21

by David Woodhouse

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

[email protected] said:
> Please help me correct them.

No. I haven't the time or the inclination to audit the whole of the CML2
rule base to check for such things. Merge a version of CML2 that matches the
CML1 rules as closely as can be expressed in CML2, then submit the
'improvements' later as separate changes - change one thing at a time just
like everyone else does. Then I promise I'll look at the actual behavioural
changes for you as you submit them and Cc them to linux-kernel.

> The definition of "behavioral change" you're implying here is so
> narrow that if I interpreted the "agreement" that way", CML2 could do
> nothing worthwhile.

Utter crap. CML2 makes them possible, and is a step in the right direction.
I'm not suggesting that you never make these changes - just that you do them
separately from the change in mechanism.

Go read what our Lord and Master said about why he likes Al Viro's patches.
Repeatedly, if needs be.

--
dwmw2

2002-01-17 14:46:21

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

David Woodhouse <[email protected]>:
> Utter crap. CML2 makes them possible, and is a step in the right direction.
> I'm not suggesting that you never make these changes - just that you do them
> separately from the change in mechanism.

Sorry, it's *way* too late for that. In fact, it was already way too
late for that at the kernel summit last March when Linus issued his ukase.
The "change in mechanism" phase of the project was essentially complete
almost a year ago now. If you had been paying attention, you would
have noticed this.

The idea that a pure change in mechanism could ever have been cleanly
separated from changes in behavior was a fantasy anyway. Large changes in
a software architecture just don't work that way, as we rediscover every
time a significant subsystem gets reworked to fix bugs.

I have held off on many things that I think badly need to be done in
order to pacify the conservative instincts of people like yourself --
for example, I think the device menus cry out to be reorganized on a
functional basis rather than on the basis of internal distinctions
like "block" vs. "character" devices that are pointless to anyone
but a kernel implementor.

But if attempting that implausibility of no behavioral changes is what
you think I "agreed" to, we'd best both forget the "agreement" --
because it would be hypocrisy if I agreed falsely and an absurd,
project-strangling shackle if I agreed sincerely.

Continuity, avoiding gratuitous changes, and a good-faith effort to
emulate the interfaces people are expecting is one thing; artificial
stasis is entirely another. I'm doing my best to give you the former.
You won't get the latter, no way, nohow.

If you have spotted errors, the time to tell me about them is *now*.
It's unfair to me and to other developers to artificially hold off
until we pass some mythical point at which it will suddenly be OK for
behavior to change. The real world doesn't work that way, and I am
sure you are too experienced to believe it does.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
-- Henry David Thoreau

2002-01-18 08:34:27

by kaih

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

[email protected] (David Lang) wrote on 16.01.02 in <[email protected]>:

> Eric, the way you worded the change report it sounded to many of us as if
> you were making the autoprober mandatory for detecting the root
> filesystem.

> I understand why you are frustrated with the response, but it's not a case
> of people having thick skulls it's a case of you leaving out critical info
> from you changelog so people reading it without your mindset see it saying
> something that you didn't mean.

I agree that a different wording might have avoided this.

But I also must say that paying even a little bit of attention on the part
of the readers would also have avoided this.

It is certainly not the first time the autoconfigurator has been discussed
here, and it was made clear *every* *single* *time* that this is an
optional thing, usually several times.

This is not a case of witholding "critical info". This is a case of
readers without any attention span.

On a mailing list such as this, the number of such readers is highly
disappointing. It feels just like Windows.

In fact, I am beginning to suspect that some people protest something they
full well *know* is not the case, just to stir up trouble.

MfG Kai

2002-01-18 18:33:27

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

Eric,

Finally got around to trying 2.1.6 - everything works great, and I'm really
impressed! Looks like killer stuff. Two things:

1) I noticed you've been pining the lists for EISA information. I don't know a
whole lot about EISA systems or anything, but I do have a 486 EISA board and
an EISA network card I'd be willing to send you if you wanted a system to play
around with. I don't use it anymore and it's just gathering dust in my
basement.

2) It seems that searching is broken. I didn't see anything in TODO and
couldn't find any bug reports on linux-kernel or kbuild-devel. Pressing '/' to
search on any screen, for any text results in the following crash:

Traceback (most recent call last):
File "cml2/cmlconfigure.py", line 3312, in ?
main(options, arguments)
File "cml2/cmlconfigure.py", line 3218, in main
curses.wrapper(curses_style_menu, config, banner)
File "/usr/lib/python2.0/curses/wrapper.py", line 44, in wrapper
res = apply(func, (stdscr,) + rest)
File "cml2/cmlconfigure.py", line 1154, in __init__
self.interact(config)
File "cml2/cmlconfigure.py", line 1782, in interact
recompute = self.symbol_menu_command(cmd, sel_symbol)
File "cml2/cmlconfigure.py", line 1535, in symbol_menu_command
configuration.debug_emit(1, "hits: " + str(hits))
File "cml2/cmlsystem.py", line 134, in _newstr
if symbol.frozen():
File "cml2/cmlsystem.py", line 154, in _frozen
if symbol.iced:
AttributeError: 'ConfigSymbol' instance has no attribute 'iced'
make: *** [menuconfig] Error 1

Other than that, this look really awesome!

Thanks,
Ross Vandegrift
[email protected]

2002-01-21 16:19:21

by Daniel Phillips

[permalink] [raw]

Subject: Re: CML2-2.1.3 is available

On January 15, 2002 08:37 pm, Rob Landley wrote:
> On Tuesday 15 January 2002 03:25 pm, Russell King wrote:
> > On Tue, Jan 15, 2002 at 02:53:24PM -0500, Eric S. Raymond wrote:
> > > * The `vitality' flag is gone from the language. Instead, the
> > > autoprober detects the type of your root filesystem and forces
> > > its symbol to Y.
> >
> > This seems like a backwards step. What's the reasoning for breaking the
> > ability to configure the kernel for a completely different machine to the
> > one that you're running the configuration/build on?
>
> He didn't. If you want to do that, run "make menuconfig" instead of "make
> autoconfigure".

I detect a slight lack of symmetry here, shouldn't it be "make autoconfig"?
Pardon me if this has been beaten to^W^W discussed above.

--
Daniel

2002-01-21 17:08:24

by Giacomo Catenazzi

[permalink] [raw]

Subject: Re: [kbuild-devel] Re: CML2-2.1.3 is available

Daniel Phillips wrote:

>
> I detect a slight lack of symmetry here, shouldn't it be "make autoconfig"?
> Pardon me if this has been beaten to^W^W discussed above.

Yes. It should be "make autoconfig", for symmterty reasons :-)
I called the files and the project autoconfigure, because
'autoconfig' is already an utility made by GNU. (not related
to kernel)

giacomo

2002-01-21 23:06:46

by Daniel Phillips

[permalink] [raw]

Subject: Re: [kbuild-devel] Re: CML2-2.1.3 is available

On January 21, 2002 06:05 pm, Giacomo Catenazzi wrote:
> Daniel Phillips wrote:
>
> >
> > I detect a slight lack of symmetry here, shouldn't it be "make
> > autoconfig"? Pardon me if this has been beaten to^W^W discussed above.
>
>
> Yes. It should be "make autoconfig", for symmterty reasons :-)
> I called the files and the project autoconfigure, because
> 'autoconfig' is already an utility made by GNU. (not related
> to kernel)

This is kernel autoconfig, different namespace, same idea. I don't think you
have a problem. Besides, last time I checked, autoconfig wasn't copyrighted.

--
Daniel

2002-01-22 05:50:42