[kbuild-devel] 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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Eric S. Raymond]

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

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 

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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.


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Eric S. Raymond]

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

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 

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Eric S. Raymond]

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

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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] cml2-2.1.3 bug report

[jeff millar]

I sent this to Eric privately with a lot of data, but maybe someone else can
jump in with an opinion about they way make oldconfig _should_ work.

Several items...

1. Make oldconfig doesn't behave like cml1.  With cml1, we would patch the
kernel or copy in a backup .config file and run make oldconfig.  It would do
its thing for 30 seconds and be done...no (or few) questions asked.  With
CML2, I get an endless series of questions about each possible configuration
item...much like "make config" does.

I just want make oldconfig to get ready for make dep with the minimum of
fuss. It's ok to ask about new configuration items but not a bunch of stuff
already set.

2. Something triggers the building of "everything" modular, like _all_ the
network cards, I2O, IEEE1394, etc.  You implied in an earlier email that
selecting modules leads to this.  But, I just want to build a few modules
because it takes less time and disk space and it easier to audit
/lib/modules/2.4.x/ results.   Besides with bleeding edge kernels, often lots
of drivers don't compile correctly. My original .config has m where I want it
and setting m a bunch more places means I just have to go around and shut off
hundreds of things.

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Eric S. Raymond]

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

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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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 <[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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Nicolas Pitre]

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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Eric S. Raymond]

Anton Altaparmakov <[EMAIL PROTECTED]>:
> 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.
-- 
http://www.tuxedo.org/~esr/";>Eric S. Raymond

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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

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

[Eric S. Raymond]

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

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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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
[EMAIL PROTECTED]

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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 .
> 
> 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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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 ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] 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 .
> 
> 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.

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


___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

[kbuild-devel] CML2-2.1.3 is available

[Eric S. Raymond]

The latest version is always available at .

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

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

___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel