Re: CML2-2.1.3 is available

Re: CML2-2.1.3 is available

[Giacomo Catenazzi]

Keith Owens wrote:

> On Tue, 22 Jan 2002 10:11:10 +0100, 
> Giacomo Catenazzi <cate@debian.org> wrote:
> 
>>If autoconfigure will go in the kernel, I have not problems on
>>filenames, but when I initially created it, I thinked ev. to
>>distribuite it as a package. Here the name matter.
>>
>>IMHO longer filename ia a good things (iff normal user should
>>not type it).
>>
> 
> autoconf autoconfigure: symlinks
>         $(CONFIG_SHELL) scripts/....
> 
> make autoconf == make autoconfigure.
> 
> Watch out for the generated autoconf.h file, it might confuse some
> people.
> 


Where?

I don't find it in:
http://lxr.linux.no/search?v=2.4.17&string=autoconfigure

	giacomo

Re: CML2-2.1.3 is available

[Keith Owens]

On Tue, 22 Jan 2002 11:09:14 +0100, 
Giacomo Catenazzi <cate@debian.org> wrote:
>Keith Owens wrote:
>> Watch out for the generated autoconf.h file, it might confuse some
>> people.
>
>Where?
>
>I don't find it in:
>http://lxr.linux.no/search?v=2.4.17&string=autoconfigure

All the make *config entries generate include/linux/autoconf.h, it is
the C representation of .config.  Some people may think that autoconf.h
is created by make autoconfig when it is really created by all *config
steps.

Re: CML2-2.1.3 is available

[Giacomo Catenazzi]

Keith Owens wrote:

> 
> All the make *config entries generate include/linux/autoconf.h, it is
> the C representation of .config.  Some people may think that autoconf.h
> is created by make autoconfig when it is really created by all *config
> steps.
> 
 
I know.

My question: where do you find

autoconf autoconfigure: symlinks
    $(SHELL_SCRIPT) script/...


This can cause confution, but I don't find ut in the sources.

BTW: I used 'make autoprobe' because of possible confutions, in

latter version. Now Eric will use both 'make autoconfig' and
'make autoprobe'.
The choice of name now is on Eric hands. Important is that
*users* doesn't confuse it.

	giacomo

Re: CML2-2.1.3 is available

[Keith Owens]

On Tue, 22 Jan 2002 11:48:06 +0100, 
Giacomo Catenazzi <cate@debian.org> wrote:
>My question: where do you find
>
>autoconf autoconfigure: symlinks
>    $(SHELL_SCRIPT) script/...

You don't.  That was an example of how you can have multiple targets
pointing to the same code, it is not in kbuild yet.

>BTW: I used 'make autoprobe' because of possible confutions, in
>latter version. Now Eric will use both 'make autoconfig' and
>'make autoprobe'.

FWIW, I prefer autoprobe.

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

[Giacomo Catenazzi]

Kai Henningsen wrote:

> phillips@bonn-fries.net (Daniel Phillips)  wrote on 22.01.02 in <E16Snav-0001kl-00@starship.berlin>:
>>On January 21, 2002 06:05 pm, Giacomo Catenazzi wrote:
>>
>>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.
>>
> 
> Last time I checked, autoconf (not -ig) was GPL. But as long as you don't  
> use code from it, copyright is completely irrelevant anyway: trademark  
> status might be relevant when you're talking about names. (And %@$&$!  
> patent status when talking about algorithms.)
> 

No problem on copyright, licences,...
I choose (for the file names, not for the 'make autoconfig') a
longer name, to distinguish the kernel autoconfig from the
GNU autoconf (without the final 'ig').
Only for pratical reasons.

If autoconfigure will go in the kernel, I have not problems on
filenames, but when I initially created it, I thinked ev. to
distribuite it as a package. Here the name matter.

IMHO longer filename ia a good things (iff normal user should
not type it).

	giacomo

Re: CML2-2.1.3 is available

[Keith Owens]

On Tue, 22 Jan 2002 10:11:10 +0100, 
Giacomo Catenazzi <cate@debian.org> wrote:
>If autoconfigure will go in the kernel, I have not problems on
>filenames, but when I initially created it, I thinked ev. to
>distribuite it as a package. Here the name matter.
>
>IMHO longer filename ia a good things (iff normal user should
>not type it).

autoconf autoconfigure: symlinks
        $(CONFIG_SHELL) scripts/....

make autoconf == make autoconfigure.

Watch out for the generated autoconf.h file, it might confuse some
people.

CML2-2.1.3 is available

[Eric S. Raymond]

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.

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.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Under democracy one party always devotes its chief energies
to trying to prove that the other party is unfit to rule--and
both commonly succeed, and are right... The United States
has never developed an aristocracy really disinterested or an
intelligentsia really intelligent. Its history is simply a record
of vacillations between two gangs of frauds. 
	--- H. L. Mencken

Re: CML2-2.1.3 is available

[Nicolas Pitre]

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

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


Nicolas

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Nicolas Pitre <nico@cam.org>:
> > 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

Re: CML2-2.1.3 is available

[Nicolas Pitre]

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

> Nicolas Pitre <nico@cam.org>:
> > > 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

Re: CML2-2.1.3 is available

[Rob Landley]

On Tuesday 15 January 2002 03:41 pm, Nicolas Pitre wrote:
> On Tue, 15 Jan 2002, Eric S. Raymond wrote:
> > Nicolas Pitre <nico@cam.org>:
> > > > 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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> 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

Re: CML2-2.1.3 is available

[Peter Samuelson]

[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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Peter Samuelson <peter@cadcamlab.org>:
> > 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 

Re: CML2-2.1.3 is available

[Peter Samuelson]

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

Re: CML2-2.1.3 is available

[Alexander Viro]

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.

Re: CML2-2.1.3 is available

[Henning P. Schmiedehausen]

"Eric S. Raymond" <esr@thyrsus.com> 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     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: CML2-2.1.3 is available

[Anton Altaparmakov]

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

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

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

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Anton Altaparmakov <aia21@cus.cam.ac.uk>:
> </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

Re: CML2-2.1.3 is available

[Rob Landley]

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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> 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

Re: CML2-2.1.3 is available

[Russell King]

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?

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

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: CML2-2.1.3 is available

[Rob Landley]

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

Re: CML2-2.1.3 is available

[Val Henson]

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

Re: CML2-2.1.3 is available

[Daniel Phillips]

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

Re: CML2-2.1.3 is available

[Peter Samuelson]

  [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

Re: CML2-2.1.3 is available

[Ross Vandegrift]

> 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
ross@willow.seitz.com

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Ross Vandegrift <ross@willow.seitz.com>:
> 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 

Re: CML2-2.1.3 is available

[Ross Vandegrift]

On Tue, Jan 15, 2002 at 11:02:11PM -0500, Eric S. Raymond wrote:
> Ross Vandegrift <ross@willow.seitz.com>:
> > 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
ross@willow.seitz.com

Re: CML2-2.1.3 is available

[Ross Vandegrift]

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
ross@willow.seitz.com

Re: CML2-2.1.3 is available

[Rob Landley]

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

Re: CML2-2.1.3 is available

[Ross Vandegrift]

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
	ross@willow.seitz.com

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Ross Vandegrift <ross@willow.seitz.com>:
> 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.

Thanks for the offer, but the question I was after has been answered.

> 2) It seems that searching is broken.

Got it, I think I've fixed this.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Nearly all men can stand adversity, but if you want to test a man's character,
give him power.
	-- Abraham Lincoln

Re: CML2-2.1.3 is available

[Robert Love]

On Tue, 2002-01-15 at 14:53, 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.

And when I compile a kernel for my Dreamcast?  Or when I want to change
rootfs?  Or how I just don't want the configurator enforcing policy?

	Robert Love

Re: CML2-2.1.3 is available

[David Lang]

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

Re: CML2-2.1.3 is available

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> 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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Horst von Brand <brand@jupiter.cs.uni-dortmund.de>:
> > 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"

Re: CML2-2.1.3 is available

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Horst von Brand <brand@jupiter.cs.uni-dortmund.de>:
> > > 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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

Horst von Brand <brand@jupiter.cs.uni-dortmund.de>:
> 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"

Re: CML2-2.1.3 is available

[David Woodhouse]

esr@thyrsus.com 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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 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

Re: CML2-2.1.3 is available

[David Woodhouse]

esr@thyrsus.com 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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 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

Re: CML2-2.1.3 is available

[David Woodhouse]

esr@thyrsus.com 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

Re: CML2-2.1.3 is available

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> 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

Re: CML2-2.1.3 is available

[David Lang]

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 <esr@thyrsus.com>
> To: Horst von Brand <brand@jupiter.cs.uni-dortmund.de>
> Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net
> Subject: Re: CML2-2.1.3 is available
>
> Horst von Brand <brand@jupiter.cs.uni-dortmund.de>:
> > > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: CML2-2.1.3 is available

[Kai Henningsen]

david.lang@digitalinsight.com (David Lang)  wrote on 16.01.02 in <Pine.LNX.4.40.0201161533090.25405-100000@dlang.diginsite.com>:

> 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