RE: ISA hardware discovery -- the elegant solution

RE: ISA hardware discovery -- the elegant solution

[Michael Lazarou (ETL)]

> -----Original Message-----
> From: Eric S. Raymond [mailto:esr@thyrsus.com]
> Subject: ISA hardware discovery -- the elegant solution
> 
> 
> I've been thinking about the hardware-discovery problem for 
> ISA devices,
> and there may be an elegant solution.  It will take a number 
> of small changes
> to the kernel sources, however.
> 
> The kernel's device drivers have, of course, to include probe
> routines, and those hard-compiled in typically log the presence of
> their hardware to /var/log/mesg when it loads.  By scanning that
> file, we in effect get to use those probes.

Doesn't this mean that you would need a fully functional kernel
before you get to run the autoconfigurator?

Michael

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?

Yes, but this was always true.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the great struggle
for independence.	-- Attributed to Charles Austin Beard (1874-1948)

Re: ISA hardware discovery -- the elegant solution

[Eli Carter]

"Eric S. Raymond" wrote:
> 
> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> Yes, but this was always true.

And if the reason you are building a new kernel is that the old one is
mis-identifying some of your hardware? ;)

Could you maybe describe the problem you are trying to solve a bit more
clearly than "the hardware-discovery problem for ISA devices"?  If you
are trying to discover the ISA devices, but rely upon them having
already been discovered, what are you accomplishing?

Puzzled,

Eli
--------------------.     Real Users find the one combination of bizarre
Eli Carter           \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

Re: ISA hardware discovery -- the elegant solution

[Wichert Akkerman]

In article <3C430E89.E65DCEDC@inet.com>,
Eli Carter  <eli.carter@inet.com> wrote:
>Could you maybe describe the problem you are trying to solve a bit more
>clearly than "the hardware-discovery problem for ISA devices"?  If you
>are trying to discover the ISA devices, but rely upon them having
>already been discovered, what are you accomplishing?

The problem is that it is simply not possible to identify ISA devices
if they aren't isapnp devices. The only thing you can do is try to
probe for them by poking at different addresses and checking what happens.
Unfortunately this can do any of three things: show that a piece of
hardware exists, show that it is not there or completely crash your
machine if another unpexpected piece of hardware happens to be at the 
place you are poking.

The best approach to doing ISA detection is ask the user which
devices he thinks he has installed and try looking for them while
praying bad things won't happen.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Eli Carter <eli.carter@inet.com>:
> Could you maybe describe the problem you are trying to solve a bit more
> clearly than "the hardware-discovery problem for ISA devices"?  If you
> are trying to discover the ISA devices, but rely upon them having
> already been discovered, what are you accomplishing?

Sure.  Let's say Aunt Tillie needs a kernel update.

Aunt Tillie is running a distro kernel (modular everything) on the
machine her nephew Melvin bought her last year.  The distro kernel
knows about the ISA devices on the machine.

She complains of occasional lockups, and that she gets skips when
playing her Guy Lombardo MP3s.  Melvin says, over the phone: "Yup,
that version had some VM problems.  And you need the low-latency stuff
that went in three releases ago.  But never mind the technical stuff.
Just click on the 'kernel update' icon on your desktop."  Melvin is
500 miles away at college.

Aunt Tillie clicks.  She sees a message saying "Downloading kernel
sources" and a progress bar.  Under the hood, the mchine is downloading
the tip of the stable branch from a kernel.org mirror site.

So why doesn't she use Red Hat or Mandrake's RPM update?  Maybe she's
running something else.  (You ain't going to tell me Aunt Tillie is ready
for Debian apt-get, either.)  Maybe she wants a kernel that's compiled
for her AMD Athlon K6 rather than a 386.  OK, so she doesn't know what
processor she has, she just remembers that Melvin told her you get a
faster kernel when you build it yourself.

(Aunt Tillie probably thinks having a faster kernel will mean she can
download images from her favorite knitting-pattern website more
quickly.  Aunt Tillie is a little confused about the difference
between processor and network speed.  That's OK; well-designed
technology should allow people the luxury of ignorance.)

Then the progress window changes to a message that says
"Configuring..." and some information about her hardware.  This is the
autoconfigurator running inside a GUI shell.

Then it says "Building..." and another progress bar.  Finally it says
"Please enter your root password so I can install the new kernel".
And, once she's done that, it tells her "Your new kernel will be named
'Sapphire' on your boot screen.  Shall I reboot now?"  She clicks "Yes".

Her machine reboots.  She selects "Sapphire" on her boot screen.  The
new kernel boots.  She logs in.  She surfs to her knitting-pattern 
website.  She logs out.  

When she clicks "Shutdown", a popup says "This is not the same kernel
that will come up by default when you next boot.  Should I make it the
default?"  She clicks "Yes".  Her kernel upgrade is done.  It required
just four mouse clicks and one password entry.  At no point did she 
have to retain mental state about previous stages of the upgrade.
(Aunt Tillie is getting on in years; she isn't as good at retaining
abstract facts as she used to be.)

In fact, at a pinch we could have done away with the password entry,
presuming that anyone with physical access to the console is allowed
to perform canned administrative functions (though not to a root
shell).

We have the technology to do all of this now; the autoconfigurator is
the last nontrivial missing piece. And if we truly want world
domination, this is what it's going to take -- ease of use that is
Macintosh-like or better at *every* level of system use and
administration.

It takes a different way of thinking than most hackers are used to.
We're proud of our mad programming skillz and our ability to wrestle
with arcana.  That pride isn't a bad thing -- except when it gets in
the way of designing systems that Aunt Tillie can use.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes the law
places the whole apparatus of judges, police, prisons and gendarmes at the
service of the plunderers, and treats the victim -- when he defends himself --
as a criminal.	-- Frederic Bastiat, "The Law"

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> So why doesn't she use Red Hat or Mandrake's RPM update?  Maybe she's
> running something else.  (You ain't going to tell me Aunt Tillie is ready
> for Debian apt-get, either.)  Maybe she wants a kernel that's compiled

I've seen apt-get used successfully by people whom I wouldnt trust to have
a glass front door in case they forgot to open it. The trick being that
"upgrade" is a desktop item someone put there that runs apt for them (or
gnome-apt or kpackage)

Now to do everything you describe does not need her to configure a custom
kernel tree. Not one bit. You think apt or up2date build each user a custom
kernel tree ?

You basically build everything modular as the distro kernel did, you install
it as the distro kernel would. You build an initrd as the distro kernel did.

Not only does it work, but it needs no configuration because when the box
was installed someone already configured it

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Now to do everything you describe does not need her to configure a custom
> kernel tree. Not one bit. You think apt or up2date build each user a custom
> kernel tree ?

Is it OK in your world that Aunt Tillie is dependent on a distro maker?  Is
it OK that she never gets to have a kernel compiled for anything above the
least-common-denominator chip?  

Not that I'm running down distro makers.  They do a valuable job, and in fact
my approach relies on Aunt Tillie's machine starting life with an all-modular
distro kernel.

But the point of this game is for Aunt Tillie to have more and better
choices.  Isn't that what we're supposed to be about?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role.	-- Edward Abbey

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Charles Cazabon]

Eric S. Raymond <esr@thyrsus.com> wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > Now to do everything you describe does not need her to configure a custom
> > kernel tree. Not one bit. You think apt or up2date build each user a custom
> > kernel tree ?
> 
> Is it OK in your world that Aunt Tillie is dependent on a distro maker?  Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?  

Yes, and yes.  Aunt Tillie is running Linux because someone installed a
distribution for her.

She is never going to need anything out of her kernel that her vendor-shipped
update kernels do not provide.  She is never going to need the 1% performance
difference she might she if she custom-compiled a kernel for her architecture
rather than using the closest one shipped by her vendor.

> But the point of this game is for Aunt Tillie to have more and better
> choices.  Isn't that what we're supposed to be about?

No.  We're supposed to be about stuff that works.  Vendor-shipped kernels work
for 99.9% of people.  The remaining 0.1% have no need for an
"auto-configurator".

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                         <charlesc@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Monday 14 January 2002 01:55 pm, Charles Cazabon wrote:
> Eric S. Raymond <esr@thyrsus.com> wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > > Now to do everything you describe does not need her to configure a
> > > custom kernel tree. Not one bit. You think apt or up2date build each
> > > user a custom kernel tree ?
> >
> > Is it OK in your world that Aunt Tillie is dependent on a distro maker? 
> > Is it OK that she never gets to have a kernel compiled for anything above
> > the least-common-denominator chip?
>
> Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> distribution for her.

Or, some glorious day in the future, it came preinstalled on her hardware.

> She is never going to need anything out of her kernel that her
> vendor-shipped update kernels do not provide.

I wouldn't go THAT far, but when she does she'll have someone else upgrade it 
for her.  (Just because you CAN learn to change the oil in your car doesn't 
mean you want to.  Can aunt tillie actually unscrew her case and insert a PCI 
card?  More to the point, WOULD she?)

> > But the point of this game is for Aunt Tillie to have more and better
> > choices.  Isn't that what we're supposed to be about?

No.  The point is to offer EVERYBODY more and better choices.  Whether 
they'll be any use to aunt tillie specifically is secondary.

> No.  We're supposed to be about stuff that works.  Vendor-shipped kernels
> work for 99.9% of people.  The remaining 0.1% have no need for an
> "auto-configurator".

I like the auto-configurator.  I build custom kernels for all sorts of 
different machines and it can take me half an hour to walk through the menus 
with a command line open in a second window doing cat /proc/pci, cat 
/proc/bus/usb, and whatever replaced isapnp (cat /proc/bus/isapnp probably) 
to figure out and properly select everything that's in this box.

If the autoprobe saves me that half an hour, I'm all for it.  People who 
don't see much use in an autoprober probably don't work with other people's 
hardware very often.

It's also a nice educational tool for newbies learning the linux kernel, 
which I suspect is the real reason some people actively object to it. :) 

> Charles

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Charles Cazabon <charlesc@discworld.dyndns.org>:
> Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> distribution for her.

You don't know that.  Maybe she installed it herself.
 
> She is never going to need anything out of her kernel that her vendor-shipped
> update kernels do not provide.

*You can't know that.*  

And your belief that you *can* know it is a key part of the elitist
developer psychology and implicit assumptions that keeps Linux mostly
inaccessible to the Aunt Tillies of the world.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"
		Law and Contemporary Problems 49, no. 1. (Winter 1986.): 35-62.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Monday 14 January 2002 01:54 pm, Eric S. Raymond wrote:
> Charles Cazabon <charlesc@discworld.dyndns.org>:
> > Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> > distribution for her.
>
> You don't know that.  Maybe she installed it herself.
>
> > She is never going to need anything out of her kernel that her
> > vendor-shipped update kernels do not provide.
>
> *You can't know that.*
>
> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.

No need to get defensive, Eric.

If make autoprobe is to become useful to an aunt tillie, it's something the 
distribution is going to have to provide a wrapper for, which strikes me as 
unlikely in the short term.  (QA issues: there's 8 zillion oddball hardware 
combos out there, and autodetect is guaranteed to either miss something or 
configure something wrong on at least some of them.  It'll need rather a lot 
of shakedown.  More than a year in mainstream.)

As for aunt tillie moving from red hat's kernel to linus's most recent 
kernel, is that advisable?  Vendors provide outside patches long before linus 
does (yes, Linus is more conservative than the distributions are).  And 
sometimes you get brown paper bag releases (2.4.11-dontuse).  Even the 
non-brown-paper-bag ones tend to have hardware combinations that won't build 
due to easily patchable compilation errors, which aunt tillie ain't up to.

A vendor that provides faster updates than Red Hat (like Kevin's Red Hat Uber 
Distribution) is a market opportunity.  But a tool is not the same thing as a 
service.  It just makes providing the service easier.

Make autoconfigure expands the pool of people who can build kernels, but it's 
not going to saturate the populace to the point where everybody immediately 
SHOULD.  Not even close.  Over time, the pool will grow.  But aiming for Aunt 
Tillie in the short term is probably overreaching.

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> Make autoconfigure expands the pool of people who can build kernels,
> but it's not going to saturate the populace to the point where
> everybody immediately SHOULD.  Not even close.  Over time, the pool
> will grow.  But aiming for Aunt Tillie in the short term is probably
> overreaching.

No, it's not.  Because the second we stop thinking about Aunt Tillie,
we start making excuses for badly-designed interfaces and excessive
complexity.  We tend to fall back into insular, elitist assumptions
that limit both the useability of our software and its potential user
population.  We get lazy and stop checking our assumptions.  When we
do this, Bill Gates laughs at us, and is right to do so.

I've seen it happen in this thread.  Many lkml people clearly have the
attitude that if you aren't willing to sweat the arcana, you
shouldn't be building kernels.  Whst they don't realize is that with
that attitude, we not only lose the Aunt Tillies of the world, we
inflict a lot of unnecessary hassle on *ourselves*, too.  We're
sweating details with think time we could be spending creatively.

Therefore I try to stay focused on Aunt Tillie even though I know
that you are objectively correct and her class of user is likely
not to build kernels regularly for some years yet.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction.  Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
        -- Colin Greenwood, in the study "Firearms Control", 1972

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Bruce Harada]

On Mon, 14 Jan 2002 17:34:23 -0500
"Eric S. Raymond" <esr@thyrsus.com> wrote:

> Therefore I try to stay focused on Aunt Tillie even though I know
> that you are objectively correct and her class of user is likely
> not to build kernels regularly for some years yet.

Change that last line to read "her class of user will never build kernels ever,
and would be aggressively disinterested in the possibility of doing so", and
you might be closer to the truth.

Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
worried about whether her kernel supports the Flangelistic2000 SuperDoodad.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Monday 14 January 2002 06:02 pm, Bruce Harada wrote:
> On Mon, 14 Jan 2002 17:34:23 -0500
>
> "Eric S. Raymond" <esr@thyrsus.com> wrote:
> > Therefore I try to stay focused on Aunt Tillie even though I know
> > that you are objectively correct and her class of user is likely
> > not to build kernels regularly for some years yet.
>
> Change that last line to read "her class of user will never build kernels
> ever, and would be aggressively disinterested in the possibility of doing
> so", and you might be closer to the truth.
>
> Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> worried about whether her kernel supports the Flangelistic2000 SuperDoodad.

I think what Eric's REALLY going for is converting some of the Minesweeper 
Certified Solitaire Experts down at the corner store (and yes there are still 
corner computer stores in mini-malls around the country) over to The Penguin. 
 (And providing them enough coffee to sober up, and making sure that their 
minimal training is slightly more than teaching to the test.  Give them some 
stimulus-response answers that might actually address reality in some small 
way.)

Anyway, if aunt tillie calls for her neighborhood computer mechanic, he's 
probably not going to be a particularly high powered geek.  He may have 
aspirations of geekdom, but basically we're talking glorified tech support.

These guys might build a kernel when they install her new cutting edge USB 
Salad Shooter that is only supported by a kernel newer than the distribution 
vendor has yet shipped.  And most of them WOULD be lost without auto-probe.

The above maps even more strongly into corporate space, to the point of being 
a cliche even.  But I still think Aunt Tillie is a couple stepping stones 
beyond a realistic next jump, and a distraction away from whether or not 
auto-probe is a cool hack and useful toy.  Not being useful for aunt tillie 
is not the same as not being useful at all.

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Bruce Harada]

On Mon, 14 Jan 2002 10:39:25 -0500
Rob Landley <landley@trommello.org> wrote:

> On Monday 14 January 2002 06:02 pm, Bruce Harada wrote:
> > On Mon, 14 Jan 2002 17:34:23 -0500
> >
> > Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> > worried about whether her kernel supports the Flangelistic2000
SuperDoodad.
> 
> I think what Eric's REALLY going for is converting some of the Minesweeper 
> Certified Solitaire Experts down at the corner store (and yes there are still 
> corner computer stores in mini-malls around the country) over to The Penguin. 

Er... if Eric were REALLY going for that, why didn't he use it as an example?
That might actually be a possible real-world situation, whereas all the ones
I've seen so far are so far removed from reality as to be pointless.

Let me put it this way: Requiring Aunt Tillie to configure/compile her kernel
is a *failure* on the part of the vendor. It doesn't matter whether Aunt
Tillie is really Aunt Tillie or your local MSCE. They should not have to do it.

As for adding a driver that's not included in the vendor's kernel, do you
mean that having a Microsoft-trained drone rebuild a kernel specifically for a
certain PC (thus requiring further compilation for any hardware added later)
and including a no-doubt beta driver and then giving it to Aunt Tillie without
any testing beyond the MCSE's PC is a *good* idea?

(I've trimmed the cc line a bit, BTW.)

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Monday 14 January 2002 09:22 pm, Bruce Harada wrote:

> As for adding a driver that's not included in the vendor's kernel, do you
> mean that having a Microsoft-trained drone rebuild a kernel specifically
> for a certain PC (thus requiring further compilation for any hardware added
> later) and including a no-doubt beta driver and then giving it to Aunt
> Tillie without any testing beyond the MCSE's PC is a *good* idea?

No, it would be tested on Aunt Tillie's PC, which she brought in for 
upgrading (she's not going to unscrew the case and put a new card in herself, 
is she), and which the drone has never seen before and didn't necessarily 
sell her in the first place.  (Maybe if Aunt Tillie's lucky the store did, 
but this is the new guy and aunt tillie's had the PC for two years, they 
don't sell that model anymore...)

I don't think having a microsoft-trained drone TOUCH a computer is a good 
idea.  But SAIR and Linux+ are going to turn out their own drones with a 
"USDA approved" stamp on their forehead who are NOT hackers, and who intend 
to make a living off of glorified tech support.  It happened in the mainframe 
world, it happened in the minicomputer world, it happened under DOS and 
Windows, and it'll happen under Linux.  And nine to five workers are not 
actually a BAD thing.  Very few actual hackers WANT to babysit database 
schema for Fortune 500 corporations...

The "I summon the vast power of certification" crowd will always be with us.  
Would you rather that the hundreds of thousands of people who get a four year 
degree in computing every year (because they think there's money in it, not 
because they actually LIKE computers) work on windows boxes, or on Linux?  
(Hint: as long as they work on windows boxes, they and their bosses are 
paying money to microsoft, and they are enabling windows-only shops where 
employees send *.doc files to everybody they know, and advancing the dot-net 
flag.)

You can't have total world domination without bringing along the drones.  
Hoping for a world where there ARE no drones is a utopian view.  Hoping for a 
PLATFORM where there are no drones is easily achievable, it's called a "tiny 
niche market".

The drones -ARE- the service industry through which you get aunt tillie.  I 
just think Eric's skipping a step...

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[H. Peter Anvin]

Followup to:  <20020115080218.7709cef7.bruce@ask.ne.jp>
By author:    Bruce Harada <bruce@ask.ne.jp>
In newsgroup: linux.dev.kernel
>
> On Mon, 14 Jan 2002 17:34:23 -0500
> "Eric S. Raymond" <esr@thyrsus.com> wrote:
> 
> > Therefore I try to stay focused on Aunt Tillie even though I know
> > that you are objectively correct and her class of user is likely
> > not to build kernels regularly for some years yet.
> 
> Change that last line to read "her class of user will never build kernels ever,
> and would be aggressively disinterested in the possibility of doing so", and
> you might be closer to the truth.
> 
> Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> worried about whether her kernel supports the Flangelistic2000 SuperDoodad.
> 

I would make this an even stronger statement:

We (yes, we) should make sure Aunt Tillie doesn't ever have to build a
kernel, ever.  If we have designed our kernels so that:

a) A distributor needs more than a handful of kernels (UP, SMP,
   SMP+PAE, perhaps CMOV or not) on their install CD, or;

b) It's not possible to add a driver without rebuilding the kernel, or;

c) It's not possible to autodetect the module set needed AT RUNTIME;

then we have screwed up.  Kernel compile autoconfiguration is a red
herring in that respect; I would argue if anything it hides the real
issue.  We're currently crappy at both (b) and (c) -- a monolithic
kernel does (c) a lot better, and that is quite frankly unacceptable.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Andrew Pimlott]

On Tue, Jan 15, 2002 at 08:02:18AM +0900, Bruce Harada wrote:
> On Mon, 14 Jan 2002 17:34:23 -0500
> "Eric S. Raymond" <esr@thyrsus.com> wrote:
> 
> > Therefore I try to stay focused on Aunt Tillie even though I know
> > that you are objectively correct and her class of user is likely
> > not to build kernels regularly for some years yet.
> 
> Change that last line to read "her class of user will never build
> kernels ever, and would be aggressively disinterested in the
> possibility of doing so", and you might be closer to the truth.
> 
> Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> worried about whether her kernel supports the Flangelistic2000 SuperDoodad.

Ok, Grandpa Willie only cares about support for his doodad.  Why do
you conclude that he should never build a kernel?

It's just as easy in principle to write a friendly front-end that
downloads sources and compiles them, as one that downloads binaries.
The obstacle is reliability, because there are more things that can
go wrong.  But imagine for a moment that this is overcome.  What
benefits might accrue from Willie compiling his own kernels (even if
he doesn't realize it)?

- It's easier for third-parties to provide kernel software in source
  form than in binary form (because binaries must be in the correct
  package format, and be compiled with the right config options, and
  adhere to the particular distribution's conventionts; whereas
  source is relatively neutral).  Why should Willie be limited to
  getting his kernels from his vendor?  What if his vendor doesn't
  support the Flangelistic2000 SuperDoodad yet, but there's a solid
  driver available from a volunteer?  What if he hears the hype
  (sorry) about the low latency patch, and decides he wants to try
  it (maybe his MP3's skip when Netscape thrashes)?  Why take the
  choice out of Willie's hands?  And why keep a willing tester and a
  developer apart?  (If you claim that novice users don't want to
  install random beta software--that contradicts my experience with
  lots of Windows users!)

- It's a system that experts are likely to use as well, because
  there's a lot of overlap between this system and what experts
  want.  A nice front-end to browse and manage kernel versions,
  patches, and drivers; to download, configure, compile and install
  them?  I might use that.  Such a system helps more people, and
  thus attracts more developers.  It's more likely to become common
  infrastructure, instead of a distribution-specific one-off.

- It makes it easier for Willie's hacker grandson to help him.
  Hackers know all about compiling kernels, but aren't as likely to
  be familiar with the distribution's binary packaging.  The more we
  all do things the same way, the more we can help each other; when
  different groups use different tools, the community is fragmented.

- It can support a graceful transition from beginner to expert.
  Suppose one day, for whatever reason, Willie really does need to
  change a compile-time option.  Or, heaven forbid, he gets curious
  about what his computer is doing when the status line says
  "compiling".  He's already got all the pieces he needs.  Ideally,
  he just needs to click on that scary "Advanced options" button.

- Building from source is good karma.

You might think these are trifles and < 1% cases.  My intuition
tells me that they add up in the long run.  At least it's worth
considering.

Andrew

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Bruce Harada]

This topic is well past the point of being done to death - it's not so much
whipping a dead horse as trying to ride the gravestone, but ah well...

On Tue, 15 Jan 2002 07:29:58 -0500
Andrew Pimlott <andrew@pimlott.ne.mediaone.net> wrote:

> On Tue, Jan 15, 2002 at 08:02:18AM +0900, Bruce Harada wrote:
> > On Mon, 14 Jan 2002 17:34:23 -0500
> > "Eric S. Raymond" <esr@thyrsus.com> wrote:
> > 
> > Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> > worried about whether her kernel supports the Flangelistic2000 SuperDoodad.
> 
> Ok, Grandpa Willie only cares about support for his doodad.  Why do
> you conclude that he should never build a kernel?

Because it adds extra complexity for very little gain and forces the vendor to
support 10,000 variations on a kernel that would normally only have a dozen or
so at most?

> It's just as easy in principle to write a friendly front-end that
> downloads sources and compiles them, as one that downloads binaries.

We're not talking about a front-end for kernel compilation - the topic is an
autoconfigurator that tries to decide what hardware is available, no matter
what might *need* to be available tomorrow, or next week, or next month.

> - It's easier for third-parties to provide kernel software in source
>   form than in binary form (because binaries must be in the correct
>   package format, and be compiled with the right config options, and
>   adhere to the particular distribution's conventionts; whereas
>   source is relatively neutral).

Except when it requires another source package to compile, which requires
another, and another... and God forbid that some patches conflict. Compiling
from source is a *bad* idea for someone who wants things to just work.

>   Why should Willie be limited to
>   getting his kernels from his vendor?

If he wants ongoing support from his vendor, he damn well better.

>   What if his vendor doesn't
>   support the Flangelistic2000 SuperDoodad yet, but there's a solid
>   driver available from a volunteer?

"Solid" as in "will not eat his hard drive and spit it out as metal shavings
when used in combination with whatever other patches have been applied to the
kernel by the vendor"? Or "solid" as in "works for me, should work OK for you,
and if it doesn't there's always the next version, and hey, don't forget to
submit a bug report"?

>  What if he hears the hype
>   (sorry) about the low latency patch, and decides he wants to try
>   it (maybe his MP3's skip when Netscape thrashes)?

I would say the chance of that level of user hearing about the low-latency
patches is about the same as me becoming an astronaut and flying to the Moon.
And if he does hear about them, the correct place for him to ask about them is
his vendor.

>   Why take the
>   choice out of Willie's hands?

Choice to do what? Break his box beyond hope of repair (by himself, at least)
and lose him any chance of support from the people he paid to do so?

>   And why keep a willing tester and a
>   developer apart?  (If you claim that novice users don't want to
>   install random beta software--that contradicts my experience with
>   lots of Windows users!)

...and how many of those Windows users submitted meaningful bug reports? Or,
indeed, *any* bug reports?

> - It's a system that experts are likely to use as well, because
>   there's a lot of overlap between this system and what experts
>   want.

Er... from the response on the list so far, I somehow doubt that...

>   A nice front-end to browse and manage kernel versions,
>   patches, and drivers; to download, configure, compile and install
>   them?  I might use that.

Again, I believe the topic of this thread was an autoconfiguration system,
not a version management utility.

> - It makes it easier for Willie's hacker grandson to help him.
>   Hackers know all about compiling kernels, but aren't as likely to
>   be familiar with the distribution's binary packaging.

Really?? There aren't that many - RPM, deb, tgz. Anyone who's that familiar
with compiling kernels is rather likely to be able to handle 'man rpm'.

>   The more we
>   all do things the same way, the more we can help each other; when
>   different groups use different tools, the community is fragmented.

Er, so you're one of those "let's all run Red Hat because it'll make things
simpler" people are you? Having a variety of tools that do similar things is
*good*.

> - It can support a graceful transition from beginner to expert.
>   Suppose one day, for whatever reason, Willie really does need to
>   change a compile-time option.  Or, heaven forbid, he gets curious
>   about what his computer is doing when the status line says
>   "compiling".  He's already got all the pieces he needs.  Ideally,
>   he just needs to click on that scary "Advanced options" button.

Who's to say that gcc is even installed on his box? Or Python? Or the userland
utilities required for him to actually make use of that compiletime option?
It's an awfully big jump from "I just want to balance my checkbook" to "let's
see, how do I activate and configure a new QoS algorithm". That's the VENDOR's
job, not Willie's or Penelope's or whoever the random user of the week may be.
If they want to do that, they are by definition no longer an average user.

> You might think these are trifles and < 1% cases.  My intuition
> tells me that they add up in the long run.  At least it's worth
> considering.

What is? A patch and version management utility? Sure - but it doesn't belong
in the kernel tree. An autoconfigurator? Not as it's been described so far by
Eric, and even if his idea wasn't broken it still shouldn't be in the kernel
tree.


Bruce

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Thomas Duffy]

On Tue, 2002-01-15 at 04:29, Andrew Pimlott wrote:

> - Building from source is good karma.
> 
> You might think these are trifles and < 1% cases.  My intuition
> tells me that they add up in the long run.  At least it's worth
> considering.

- Someday, a stupid government or court decides that there is a strict
separation between source and binary.  Source is protected speech, but
binaries are not.  Linux decides it wants a really fast DVD decryption
in the kernel, so it adds it in drivers.  But now, distro's cannot
compile and distribute a binary kernel package and the end user will
need to compile the source code in order to watch their DVD.

Why is it unrealistic for everybody to compile their kernel when they do
an install?  If it is rather automated, then it just becomes another
step on the progress bar.

-tduffy

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Marco Colombo]

On 15 Jan 2002, Thomas Duffy wrote:

> On Tue, 2002-01-15 at 04:29, Andrew Pimlott wrote:
> 
> > - Building from source is good karma.
> > 
> > You might think these are trifles and < 1% cases.  My intuition
> > tells me that they add up in the long run.  At least it's worth
> > considering.
> 
> - Someday, a stupid government or court decides that there is a strict
> separation between source and binary.  Source is protected speech, but
> binaries are not.  Linux decides it wants a really fast DVD decryption
> in the kernel, so it adds it in drivers.  But now, distro's cannot
> compile and distribute a binary kernel package and the end user will
> need to compile the source code in order to watch their DVD.
> 
> Why is it unrealistic for everybody to compile their kernel when they do
> an install?  If it is rather automated, then it just becomes another
> step on the progress bar.

Every distro supplies a package with the source used to build their own
kernel. Just recomplile it. You can do it today. Yes, it takes longer
than building an autoconfigured kernel, since you're compiling a lot
of unused stuff. Yet the autoconfigurator belongs to the 'Kernel compiling
sybsystem' of that distribution. Don't forget that vanilla kernels can
even be incompatible with the one provided by the distro maker.

Doing it at install time is somewhat unrelated (it's even more distro-
dependant).

> 
> -tduffy
> 

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Richard B. Johnson]

On Tue, 15 Jan 2002, Marco Colombo wrote:

> On 15 Jan 2002, Thomas Duffy wrote:
> 
> > On Tue, 2002-01-15 at 04:29, Andrew Pimlott wrote:
> > 
> > > - Building from source is good karma.

[SNIPPED...]

> 
> Every distro supplies a package with the source used to build their own
> kernel. Just recomplile it.

Really???  Have you ever tried this? RedHat provides a directory
of random patches that won't patch regardless of the order in
which you attempt patches (based upon date-stamps on patches or
date-stamps on files). It's like somebody just copied in some
junk, thinking nobody would ever bother.

Some distributions don't even provide source. They provide
copies of /usr/src/linux/include/asm and /usr/src/linux/include/linux
but nothing else. You have to "find" source on the internet.

Some distributions don't even provide that, instead they provide
copies of /usr/src/linux/include/linux and /usr/src/linux/include/asm
under /usr/include.

The "good-ol-days" where you could get 72 floppies from Yggdrasil,
install Linux, and spend the next 48 hours watching it compile
are long gone.

I have never found a distribution that uses modules, in which is
was even remotely possible to duplicate the kernel supplied.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Manuel McLure]

Red Hat provides a source RPM for their kernel - install the source RPM and
use rpm to build it. If you want to figure out what order the patches were
applied in, just look at the RPM spec file. I myself have applied patches to
a Red Hat kernel RPM in this fashion.

--
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft


----- Original Message -----
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: "Marco Colombo" <marco@esi.it>
Cc: "Thomas Duffy" <Thomas.Duffy.99@alumni.brown.edu>; "Linux Mailing List"
<linux-kernel@vger.kernel.org>
Sent: Tuesday, January 15, 2002 10:52 AM
Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --
the elegant solution)


> On Tue, 15 Jan 2002, Marco Colombo wrote:
>
> > On 15 Jan 2002, Thomas Duffy wrote:
> >
> > > On Tue, 2002-01-15 at 04:29, Andrew Pimlott wrote:
> > >
> > > > - Building from source is good karma.
>
> [SNIPPED...]
>
> >
> > Every distro supplies a package with the source used to build their own
> > kernel. Just recomplile it.
>
> Really???  Have you ever tried this? RedHat provides a directory
> of random patches that won't patch regardless of the order in
> which you attempt patches (based upon date-stamps on patches or
> date-stamps on files). It's like somebody just copied in some
> junk, thinking nobody would ever bother.
>
> Some distributions don't even provide source. They provide
> copies of /usr/src/linux/include/asm and /usr/src/linux/include/linux
> but nothing else. You have to "find" source on the internet.
>
> Some distributions don't even provide that, instead they provide
> copies of /usr/src/linux/include/linux and /usr/src/linux/include/asm
> under /usr/include.
>
> The "good-ol-days" where you could get 72 floppies from Yggdrasil,
> install Linux, and spend the next 48 hours watching it compile
> are long gone.
>
> I have never found a distribution that uses modules, in which is
> was even remotely possible to duplicate the kernel supplied.
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
>
>     I was going to compile a list of innovations that could be
>     attributed to Microsoft. Once I realized that Ctrl-Alt-Del
>     was handled in the BIOS, I found that there aren't any.
>
>
> -
> 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: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Marco Colombo]

On Tue, 15 Jan 2002, Richard B. Johnson wrote:

> On Tue, 15 Jan 2002, Marco Colombo wrote:
> 
> > On 15 Jan 2002, Thomas Duffy wrote:
> > 
> > > On Tue, 2002-01-15 at 04:29, Andrew Pimlott wrote:
> > > 
> > > > - Building from source is good karma.
> 
> [SNIPPED...]
> 
> > 
> > Every distro supplies a package with the source used to build their own
> > kernel. Just recomplile it.
> 
> Really???  Have you ever tried this? RedHat provides a directory
> of random patches that won't patch regardless of the order in
> which you attempt patches (based upon date-stamps on patches or
> date-stamps on files). It's like somebody just copied in some
> junk, thinking nobody would ever bother.

Uh?

# cd /usr/src/linux-2.4
# make xconfig
(note that the autoconfigurator would provide a good starting point
here for a stripped down kernel, reducing compile time a lot!)
# make bzImage
# make modules
# make install
# make modules_install

# ls -al /boot/vmlinuz-2.4.9-13custom
/boot/vmlinuz-2.4.9-13custom

I've done that (with minimal variations) hundreds of times. It worked like
that since 4.1, IIRC. What Red Hat are you talking about? And it's no
different from what you do with a standard tree.

(you need the kernel-source RPMS, of course)


You encounter troubles when you apply some random patch to the RH tree.
It happens with almost every non vanilla tree out there...

> Some distributions don't even provide source. They provide
> copies of /usr/src/linux/include/asm and /usr/src/linux/include/linux
> but nothing else. You have to "find" source on the internet.

Name one, please. I can't believe it.

> Some distributions don't even provide that, instead they provide
> copies of /usr/src/linux/include/linux and /usr/src/linux/include/asm
> under /usr/include.

Name one, please. Really.

> The "good-ol-days" where you could get 72 floppies from Yggdrasil,
> install Linux, and spend the next 48 hours watching it compile
> are long gone.

Uh. SLS was the one. Less than 50 floppies. And it never took
48 to compile a kernel. Before 1.0 the kernel was so small than my
386/40, equipped with 4MB of RAM, managed to complile it in reasonable
time (<30mins) (not with X running). 0.96 (or was it 0.98) ate my disk
so many times during compile (HD Timeout...) that I must confess that
I've been a 386BSDer and a NetBSDer at times...  I can't remeber when
the problem has been fixed, BTW. Maybe when I switched to Slackware.

Kernel compile time has been nearly constant in time (since I was 
upgrading my HW meanwhile), in my experience.

> I have never found a distribution that uses modules, in which is
> was even remotely possible to duplicate the kernel supplied.

s|make xconfig|cp configs/kernel-2.4.9-athlon.config .config|

in the above. Works like a charm (ok, the kernel is named -custom, but
I like it this way).

Anyway, rpm --rebuild kernel-xxxx.src.rpm  does work, even if it's
obviously slow (I've never tried in on 7.x, though.  I'm reminiscent of
6.x days), since it produces all the binary packages...


Go get a better internet connection: the one you're using is corrupting
the packages you're downloading. Or it's corrupting the messages you're
sending.

> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
> 
>     I was going to compile a list of innovations that could be
>     attributed to Microsoft. Once I realized that Ctrl-Alt-Del
>     was handled in the BIOS, I found that there aren't any.
> 
> 
> 

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Richard B. Johnson]

On Tue, 15 Jan 2002, Marco Colombo wrote:

> On Tue, 15 Jan 2002, Richard B. Johnson wrote:
> 
> > On Tue, 15 Jan 2002, Marco Colombo wrote:
> > 
> > > On 15 Jan 2002, Thomas Duffy wrote:
> > > 
> > > > On Tue, 2002-01-15 at 04:29, Andrew Pimlott wrote:
> > > > 
> > > > > - Building from source is good karma.
> > 
> > [SNIPPED...]
> > 
> > > 
> > > Every distro supplies a package with the source used to build their own
> > > kernel. Just recomplile it.
> > 
> > Really???  Have you ever tried this? RedHat provides a directory
> > of random patches that won't patch regardless of the order in
> > which you attempt patches (based upon date-stamps on patches or
> > date-stamps on files). It's like somebody just copied in some
> > junk, thinking nobody would ever bother.
> 
> Uh?
> 
> # cd /usr/src/linux-2.4
> # make xconfig

[NO, No, NO....]

I'm not talking about making a kernel that will `work` on your
machine. I'm talking about making __the__ kernel that they supplied
with all its modules, etc.

RedHat 7 is a prime example. I put it on a box in the other room.
/usr/src didn't contain ANYTHING after an installation.
However, /usr/include/asm and /usr/include/linux existed, not
as symlinks, but as files that would-have-existed within a
kernel distribution. 

So... I did RPM install for the kernel after I found what was
alleged to have been the kernel. Now I had a /usr/src/linux/..., but
of course not /usr/src/linux-2.2.16-22, the binary kernel supplied.
The stuff in /usr/include was not fixed or changed to sym-links and it was
incompatible with what existed in the kernel. These were 2.2 files
with so much incompatible stuff; a 447,099 byte diff if you are truly
interested.

The usr/src/linux/.config was the .config obtained off from Linus`
tree, not something provided by RedHat so `make oldconfig` would have
made a "standard kernel" like you download from ftp.kernel.org.

Now, looking in /usr/src/redhat/../.., I find some patches that are
impossible to use to patch the kernel to bring it up (or down) to
the configuration used to build the distribution. The default
configuration, before I "installed" the kernel sources was some
empty directories of /usr/src/redhat/BUILD, /usr/src/redhat/RPMS,
/usr/src/redhat/SOURCES, /usr/src/redhat/SPECS, and /usr/src/redhat/SRPMS.
Now there were some patches and other files with no scripts and no
way to actually use them to modify the kernel. I spent hours, putting
them in order, based upon the time/date stamp within the files, not
the file time which was something more or less random. I made a script
and tried, over a period of weeks, to patch the supplied kernel with
the supplied patches. Forget it. If anything in this universe is truly
impossible, then making a Red Hat distribution kernel from the provided
tools, patches, and sources is a definitive example.

Then, to add insult to injury, the 'C' compiler provided would
not create a bootable kernel. It was egcs-2.91.66. To make
a bootable kernel, I had to install gcc-2.96. The list goes on.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Manuel McLure]

----- Original Message -----
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: "Marco Colombo" <marco@esi.it>
Cc: "Linux Mailing List" <linux-kernel@vger.kernel.org>
Sent: Tuesday, January 15, 2002 12:13 PM
Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --
the elegant solution)


[SNIP]
> The usr/src/linux/.config was the .config obtained off from Linus`
> tree, not something provided by RedHat so `make oldconfig` would have
> made a "standard kernel" like you download from ftp.kernel.org.
>
> Now, looking in /usr/src/redhat/../.., I find some patches that are
> impossible to use to patch the kernel to bring it up (or down) to
> the configuration used to build the distribution. The default
> configuration, before I "installed" the kernel sources was some
> empty directories of /usr/src/redhat/BUILD, /usr/src/redhat/RPMS,
> /usr/src/redhat/SOURCES, /usr/src/redhat/SPECS, and /usr/src/redhat/SRPMS.
> Now there were some patches and other files with no scripts and no
> way to actually use them to modify the kernel. I spent hours, putting
> them in order, based upon the time/date stamp within the files, not
> the file time which was something more or less random. I made a script
> and tried, over a period of weeks, to patch the supplied kernel with
> the supplied patches. Forget it. If anything in this universe is truly
> impossible, then making a Red Hat distribution kernel from the provided
> tools, patches, and sources is a definitive example.
>
> Then, to add insult to injury, the 'C' compiler provided would
> not create a bootable kernel. It was egcs-2.91.66. To make
> a bootable kernel, I had to install gcc-2.96. The list goes on.

Use the RPM - all of the instructions on what patches go in what order are
in the spec file. Or, you can simply copy the appropriate configuration file
from /usr/src/redhat/SOURCES to /usr/src/linux/.config, and do a "make
oldconfig; make dep; make clean; make install; make modules; make
modules_install". Voila, new kernel. Don't tell me this doesn't work because
I've done it myself.

--
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[arjanv]

In article <Pine.LNX.3.95.1020115143729.1338A-100000@chaos.analogic.com> you wrote:

Ok I shouldn't but...

> RedHat 7 is a prime example. I put it on a box in the other room.
> /usr/src didn't contain ANYTHING after an installation.
> However, /usr/include/asm and /usr/include/linux existed, not
> as symlinks, but as files that would-have-existed within a
> kernel distribution. 

Exactly and 100% correct. Those are GLIBC headers and have NOTHING to do
with the kerenl.

> So... I did RPM install for the kernel after I found what was

Well you should have installed the kernel-source rpm if you wanted the full
expanded source... we make that one for a reason you know...

> alleged to have been the kernel. Now I had a /usr/src/linux/..., but

> The usr/src/linux/.config was the .config obtained off from Linus`
> tree, not something provided by RedHat so `make oldconfig` would have
> made a "standard kernel" like you download from ftp.kernel.org.

Ehm yes it does if you use the kernel-source RPM, also we ship about a dozen
different configs (differing in cpu type and up/smp mostly), ALL those
.config files are neatly available in the configs/ subdirectory.

> Now, looking in /usr/src/redhat/../.., I find some patches that are
> impossible to use to patch the kernel to bring it up (or down) to
> the configuration used to build the distribution. The default
> configuration, before I "installed" the kernel sources was some
> empty directories of /usr/src/redhat/BUILD, /usr/src/redhat/RPMS,
> /usr/src/redhat/SOURCES, /usr/src/redhat/SPECS, and /usr/src/redhat/SRPMS.
> Now there were some patches and other files with no scripts

Ehm the .spec file is the script!
rpm -bp kernel-2.2.spec to "run" it to create a source, or rpm -bb to make
rpm -i'able rpm binaries files from it.

> and no
> way to actually use them to modify the kernel. I spent hours, putting
> them in order, based upon the time/date stamp within the files, not
> the file time which was something more or less random. I made a script
> and tried, over a period of weeks, to patch the supplied kernel with
> the supplied patches. Forget it. If anything in this universe is truly
> impossible, then making a Red Hat distribution kernel from the provided
> tools, patches, and sources is a definitive example.

Ok now you offend me. I spent quite a bit of time making the .spec file easy
to read, AND we provide a convenient kernel-source rpm which installs
/usr/src/linux (for RHL7.0) or /usr/src/linux-2.4 for 2.4 kernels (7.1/7.2) 
which contains the full source AND all configs we used. AND if you type
"make oldconfig" it picks the one you are currently running. Heck I even put
a (ok partial) description of each patch (in addition to the brief
description in the spec file) for the 7.1 kernel on
http://people.redhat.com/arjanv/patches.html for people who were interested
in why a patch existed.

Now what more would you want ?  

Greetings,
   Arjan van de Ven
   Red Hat Linux kernel maintainer
   

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Richard B. Johnson]

On Tue, 15 Jan 2002 arjanv@redhat.com wrote:

> In article <Pine.LNX.3.95.1020115143729.1338A-100000@chaos.analogic.com> you wrote:
> 
> Ok I shouldn't but...
> 
> > RedHat 7 is a prime example. I put it on a box in the other room.
> > /usr/src didn't contain ANYTHING after an installation.
> > However, /usr/include/asm and /usr/include/linux existed, not
> > as symlinks, but as files that would-have-existed within a
> > kernel distribution. 
> 
> Exactly and 100% correct. Those are GLIBC headers and have NOTHING to do
> with the kerenl.
> 
> > So... I did RPM install for the kernel after I found what was
> 
> Well you should have installed the kernel-source rpm if you wanted the full
> expanded source... we make that one for a reason you know...
> 
> > alleged to have been the kernel. Now I had a /usr/src/linux/..., but
> 
> > The usr/src/linux/.config was the .config obtained off from Linus`
> > tree, not something provided by RedHat so `make oldconfig` would have
> > made a "standard kernel" like you download from ftp.kernel.org.
> 
> Ehm yes it does if you use the kernel-source RPM, also we ship about a dozen
> different configs (differing in cpu type and up/smp mostly), ALL those
> .config files are neatly available in the configs/ subdirectory.
> 
> > Now, looking in /usr/src/redhat/../.., I find some patches that are
> > impossible to use to patch the kernel to bring it up (or down) to
> > the configuration used to build the distribution. The default
> > configuration, before I "installed" the kernel sources was some
> > empty directories of /usr/src/redhat/BUILD, /usr/src/redhat/RPMS,
> > /usr/src/redhat/SOURCES, /usr/src/redhat/SPECS, and /usr/src/redhat/SRPMS.
> > Now there were some patches and other files with no scripts
> 
> Ehm the .spec file is the script!
> rpm -bp kernel-2.2.spec to "run" it to create a source, or rpm -bb to make
> rpm -i'able rpm binaries files from it.
> 
> > and no
> > way to actually use them to modify the kernel. I spent hours, putting
> > them in order, based upon the time/date stamp within the files, not
> > the file time which was something more or less random. I made a script
> > and tried, over a period of weeks, to patch the supplied kernel with
> > the supplied patches. Forget it. If anything in this universe is truly
> > impossible, then making a Red Hat distribution kernel from the provided
> > tools, patches, and sources is a definitive example.
> 
> Ok now you offend me. I spent quite a bit of time making the .spec file easy
> to read, AND we provide a convenient kernel-source rpm which installs
> /usr/src/linux (for RHL7.0) or /usr/src/linux-2.4 for 2.4 kernels (7.1/7.2) 
> which contains the full source AND all configs we used. AND if you type
> "make oldconfig" it picks the one you are currently running. Heck I even put
> a (ok partial) description of each patch (in addition to the brief
> description in the spec file) for the 7.1 kernel on
> http://people.redhat.com/arjanv/patches.html for people who were interested
> in why a patch existed.
> 
> Now what more would you want ?  
> 
> Greetings,
>    Arjan van de Ven
>    Red Hat Linux kernel maintainer
>    
> 

Well you SHOULD and you did. I want to thank you for your definitive
explaination of how to make a kernel that is an exact functional
duplicate of the distributed kernel. Hopefully this will work, and I
will, in fact, make it worth your company's time by getting the
"latest-and-greatest" Red Hat distribution and use your Email as
a reference.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Marco Colombo]

On Tue, 15 Jan 2002 arjanv@redhat.com wrote:

[...]
> > and no
> > way to actually use them to modify the kernel. I spent hours, putting
> > them in order, based upon the time/date stamp within the files, not
> > the file time which was something more or less random. I made a script
> > and tried, over a period of weeks, to patch the supplied kernel with
> > the supplied patches. Forget it. If anything in this universe is truly
> > impossible, then making a Red Hat distribution kernel from the provided
> > tools, patches, and sources is a definitive example.
> 
> Ok now you offend me. I spent quite a bit of time making the .spec file easy
> to read, AND we provide a convenient kernel-source rpm which installs
> /usr/src/linux (for RHL7.0) or /usr/src/linux-2.4 for 2.4 kernels (7.1/7.2) 
> which contains the full source AND all configs we used. AND if you type
> "make oldconfig" it picks the one you are currently running. Heck I even put
	 	   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that one I didn't know, I've always done a manual cp from configs/*.
Thanks for the hint. B-)  (And for the good job)

> Greetings,
>    Arjan van de Ven
>    Red Hat Linux kernel maintainer
>    

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> However, /usr/include/asm and /usr/include/linux existed, not
> as symlinks, but as files that would-have-existed within a
> kernel distribution. 

This is correct behaviour, please read the glibc installation documentation

Alan

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> Really???  Have you ever tried this? RedHat provides a directory
> of random patches that won't patch regardless of the order in
> which you attempt patches (based upon date-stamps on patches or
> date-stamps on files). It's like somebody just copied in some
> junk, thinking nobody would ever bother.

They apply nicely and the spec file defines which to apply and when. The
srpm and rpm are generated together.

I was wondering who would actually need Aunt Tillie's autoconfigurator, now
I know

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[David Woodhouse]

alan@lxorguk.ukuu.org.uk said:
> > Really???  Have you ever tried this? RedHat provides a directory
> > of random patches that won't patch regardless of the order in
> > which you attempt patches (based upon date-stamps on patches or
> > date-stamps on files). It's like somebody just copied in some
> > junk, thinking nobody would ever bother.

> They apply nicely and the spec file defines which to apply and when.
> The srpm and rpm are generated together. 

And just in case you're too incompetent or lazy to manage this, there's also
a kernel-source package which contains the resulting source tree, with all
the patches already applied to it.

--
dwmw2

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

"Richard B. Johnson" <root@chaos.analogic.com> said:

[...]

> Really???  Have you ever tried this? RedHat provides a directory
> of random patches that won't patch regardless of the order in
> which you attempt patches (based upon date-stamps on patches or
> date-stamps on files). It's like somebody just copied in some
> junk, thinking nobody would ever bother.

rpm(1), particularly "rpm -p" on the SRPM. Or use the kernel-source RPM.

Last time I looked, they carried around patches that weren't applied in the
SRPM.

> Some distributions don't even provide source. They provide
> copies of /usr/src/linux/include/asm and /usr/src/linux/include/linux
> but nothing else. You have to "find" source on the internet.

They are in violation of GPL then. Make it clear to them.

> The "good-ol-days" where you could get 72 floppies from Yggdrasil,
> install Linux, and spend the next 48 hours watching it compile
> are long gone.

What stops you from getting Red Hat, and doing a massive "rpm --rebuild"
today? 

> I have never found a distribution that uses modules, in which is
> was even remotely possible to duplicate the kernel supplied.

Why do they then bother to distribute sources?
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

Thomas Duffy <Thomas.Duffy.99@alumni.brown.edu> said:

[...]

> - Someday, a stupid government or court decides that there is a strict
> separation between source and binary.  Source is protected speech, but
> binaries are not.  Linux decides it wants a really fast DVD decryption
> in the kernel, so it adds it in drivers.  But now, distro's cannot
> compile and distribute a binary kernel package and the end user will
> need to compile the source code in order to watch their DVD.

No need for a full compile, just the offending driver. IF and WHEN it
happens. Till then, why bother?

> Why is it unrealistic for everybody to compile their kernel when they do
> an install?  If it is rather automated, then it just becomes another
> step on the progress bar.

If each time you install $distro you have to get compiler, linker, Python,
and whatnot up and running; and then have to wait a half hour or so for the
standard distributed kernel to compile, I don't see the point. Its much
easier/faster/secure to just distribute and install binaries.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

Andrew Pimlott <andrew@pimlott.ne.mediaone.net> said:

[...]

> It's just as easy in principle to write a friendly front-end that
> downloads sources and compiles them, as one that downloads binaries.

That it is _possible_ do do so doesn't mean it is _worthwhile_. I do trust
Red Hat's binaries (because of QA), there is reasonable support for them to
correlate bug reports, etc. I _don't_ trust kernel.org sources, at least
not for production use. Sure, I fool around with them on my machines. There
they have eaten a few filesystems, some crashed on boot, others were
useless.

Aunt Tillie (and Nephew Mervin, and the whole bunch of relatives) present a
support (i.e., distribution and people) problem. They are _production_, not
_experiments_. Sure, we could mandate that kernels from the stable series
go through rigurous QA before being posted. Progress would slow to a crawl,
the fun of hacking Linux would soon be over, and so would be Linux. Or
there would be trhee branches: Production quality, stable, and
experimental. Next you know, Uncle Eric would then demand autobuilding for
Aunt Tillie from the stable (or even experimantal) branch for updated
driver for the Foomatic 37.

Autobuilding *is here*, *right now*. It is called "distribution's kernel",
aided by something hacked up a time ago called "modules" and "autoloading".

As techies we always try to find a technical solution to problems, but
there are problems where the best solution isn't technical at all. It is
organizational, education, setting up a support network, ... There are even
problems that _have_ no technical solutions. Or even problems that have
perfectly adequate non-technical solutions right now, which we overlook.

> The obstacle is reliability, because there are more things that can
> go wrong.

Bingo! With a binary, the vendor _knows_ what was shipped, and has checked
that configuration to death. With autoconfiguration this is probably the
_only_ copy of that particular configuration on the whole world. And
Point&Drool Nephew Mervin is supposed to find out why it doesn't boot
today. Forget about eyeing Penelope, he won't have time for that.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[David Woodhouse]

hpa@zytor.com said:
>   If we have designed our kernels so that:
	<...>
> b) It's not possible to add a driver without rebuilding the kernel,
> or;
	<...>
> then we have screwed up. 

Oops. In that case, we screwed up (130 - delta) times.

find /usr/src/linux/ -name \*.[ch] | xargs egrep \#if.*CONFIG_.*_MODULE |  cut -f2- -d: | sort | uniq | wc -l

--
dwmw2

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> No, it's not.  Because the second we stop thinking about Aunt Tillie,
> we start making excuses for badly-designed interfaces and excessive
> complexity.  We tend to fall back into insular, elitist assumptions
> that limit both the useability of our software and its potential user
> population.  We get lazy and stop checking our assumptions.  When we
> do this, Bill Gates laughs at us, and is right to do so.

That I doubt. Its good to see you've spent a day or two reading about
customer expectations and software relationship management, but you are
missing some key bits of UI design here

1.	You don't need to ask the poor user any questions
2.	You can be proactive
		[Shall I update your computer ?]
3.	You can be automated
		[x] update at 4am every day

This is why we have things like DHCP, plug and play, EDID, and so on.
When you ask a user a question they are not sure of you make them feel
inadequate. People don't like that so they dislike the result. Phrasing the 
question in child speak tends to make them feel more not less embarassed.
"Fronicate the Bazoom Hex value" people can justifiably feel isnt their
fault and just hit return. When faced with a two paragraph explanation of the
option, 3 choices and unsure of the answer - that upsets people.

Good design you simply don't notice. Nobody who ever used the gnome-lokkit
firewall configuration ever wondered why their DNS happened to still work for
example, while asking them about DNS would have confused many.

If you want Aunt Tillie to be happy your dialog should probably look like this

		Update my computer
		[yes]         [no]       [advanced] (and this one wants to go)

No hardware dialogs, no extra questions needed. Not even an "optimise my
computer to get the best performance", because that has only one answer in
reality "Duh of course, why are you asking me"

The Red Hat kernel is a modular kernel tuned to the CPU in question, and
with an initrd built for the root fs as needed. All the logic is built into
the existing GPL tools. It figures out what should be in the initrd, which
kernel cpu type to use (and that while now for install could easily be
for build).

I simply don't understand what you are trying to build and why it is hard.

Your new driver model isnt ideal too. Think bigger - unknown driver
PCMCIA [ident strings]. Fine - trigger an apt-get of dev-pcmcia-blah-blah-blah
and see if there is one yet.

Alan

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> I simply don't understand what you are trying to build and why it is hard.

Don't understand it?  Download it, follow the directions, and see.

It's not that hard.  Given Giacomo's table of probes it only took me about
two days to get it 85% of the way there.  The remaining 15% is partly 
issues with rulebase bugs that it exposes, and partly issues with what
to do about the possibility of ISA hardware that is not directly probeable.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance?  Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and tyrants.
	-- Thomas Jefferson, letter to Col. William S. Smith, 1787 

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

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

[...]

> It's not that hard.  Given Giacomo's table of probes it only took me about
> two days to get it 85% of the way there.  The remaining 15% is partly 
> issues with rulebase bugs that it exposes, and partly issues with what
> to do about the possibility of ISA hardware that is not directly
> probeable.

Ever heard of "90% done, the remaining 10% will take the other 90% of the
effort"? Just as predicted, a long way back... then comes a two or three
year shakedown to get it reliable enough for real use.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Mark Hahn]

> complexity.  We tend to fall back into insular, elitist assumptions

it's elitist to claim that someone is elitist, 
especially when using the royal 'we'.  ;)

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Sean Hunter]

On Mon, Jan 14, 2002 at 05:34:23PM -0500, Eric S. Raymond wrote:
> Because the second we stop thinking about Aunt Tillie,
> we start making excuses for badly-designed interfaces and excessive
> complexity. 

Bollocks.  The second we (including you) stop thinking about the _user_ of the
technology, we make bad decisions.  This is not the same thing.  

We don't expect Aunt Tillie to write kernel drivers for her knitting machine.
She (and we) expect(s) someone else to do that for her.

The Aunt Tillies of this world don't install of update Windows (or Mac O/S) for
themselves except perhaps via "Windows Update" or "Apple Update", which (guess
what) supplies a prebuilt binary and DOESN'T BUILD THEM A KERNEL.

Besides any other factor, the download/install/reboot time is less than the
download-full-tarball/untar/configure/compile/install/reboot cycle.

Sean

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Tuesday 15 January 2002 04:14 am, Sean Hunter wrote:
> On Mon, Jan 14, 2002 at 05:34:23PM -0500, Eric S. Raymond wrote:
> > Because the second we stop thinking about Aunt Tillie,
> > we start making excuses for badly-designed interfaces and excessive
> > complexity.
>
> Bollocks.  The second we (including you) stop thinking about the _user_ of
> the technology, we make bad decisions.  This is not the same thing.
>
> We don't expect Aunt Tillie to write kernel drivers for her knitting
> machine. She (and we) expect(s) someone else to do that for her.
>
> The Aunt Tillies of this world don't install of update Windows (or Mac O/S)
> for themselves except perhaps via "Windows Update" or "Apple Update", which
> (guess what) supplies a prebuilt binary and DOESN'T BUILD THEM A KERNEL.
>
> Besides any other factor, the download/install/reboot time is less than the
> download-full-tarball/untar/configure/compile/install/reboot cycle.
>
> Sean

Far down on my to-do list is breaking out the "linux from scratch" project, 
reading through it, and making a small, simple distribution that doesn't have 
ANY precompiled binaries except the initial boot disk.  It should compile and 
install everything from source code.  "configure; make; make install"  (I 
wouldn't be suprised if somebody's already done this.  It would save me a lot 
of work, actually.  But I haven't found it yet.)

The reason for this isn't that I expect end-users to deal with it, it's that 
whenever I'm trying to debug a problem in X or Konqueror or some such, it's 
ten times as much work to get the darn thing to compile and install from 
source than it is to track down and patch the actual BUG.  (Especially 
getting the home-built version and the RPM-installed version not to fight to 
the death configuration-wise, either overwriting OR installing them in 
seperate directories.)  Most of the time I just dump the problem on my "to 
do" list and never get around to it.  (I admit X and KDE are a bit worse than 
average here, and I've only really wanted to patch a bug in glibc once.  But 
still, it would be nice to have the option of following my nose into the 
source without doing four hours worth of preparatory work first...)

Possibly I've just had more than my share of bad experiences in this area...

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Tom Rini]

On Mon, Jan 14, 2002 at 01:54:12PM -0500, Eric S. Raymond wrote:
> Charles Cazabon <charlesc@discworld.dyndns.org>:
> > Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> > distribution for her.
> 
> You don't know that.  Maybe she installed it herself.

So she installed it herself, why isn't $distrovender kernel good enough?
Keep in mind that just because $kernelversion has a bug doesn't mean
that $distrovender-$kernelversion does.  So yes, relying on an update
from $distrovendor is a good thing.  What if your automagic tool existed
and Aunt Tillie clicked when 2.4.15 was current stable?

> > She is never going to need anything out of her kernel that her vendor-shipped
> > update kernels do not provide.
> 
> *You can't know that.*  

Would you accept She'll almost never need something thats not in her
current $distrovednor kernel or the one $distrovendor is working on?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eli Carter]

"Eric S. Raymond" wrote:
> Charles Cazabon <charlesc@discworld.dyndns.org>:
> > Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> > distribution for her.
> 
> You don't know that.  Maybe she installed it herself.

>From a box she bought at CompUSA (or equiv.).  She is dependant upon the
distro maker for the service they provide to her... that's what she's
paying them for.

> > She is never going to need anything out of her kernel that her vendor-shipped
> > update kernels do not provide.
> 
> *You can't know that.*
> 
> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.

Then she needs a better distribution, or at least one that caters to her
needs.
If there isn't such a distribution for her, she is no longer "Aunt
Tillie", but has become "Aun7 71LL13" ;)

Ahem, sorry, couldn't resist. :)  I'll be quiet now.

Eli
--------------------.     Real Users find the one combination of bizarre
Eli Carter           \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Dave Jones]

On Mon, Jan 14, 2002 at 01:54:12PM -0500, Eric S. Raymond wrote:

 > > She is never going to need anything out of her kernel that her vendor-shipped
 > > update kernels do not provide.
 > *You can't know that.*  
 > And your belief that you *can* know it is a key part of the elitist
 > developer psychology and implicit assumptions that keeps Linux mostly
 > inaccessible to the Aunt Tillies of the world.

 nonsense. if theres some whizzy-new-feature that Aunt Tillie really
 believes she'll need, there's more chance she'll find it in a
 prepackaged tested vendor kernel than stock kernel. And if not,
 then there's usually a good reason for non-inclusion.
 
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Charles Cazabon]

Eric S. Raymond <esr@thyrsus.com> wrote:
> Charles Cazabon <charlesc@discworld.dyndns.org>:
> > Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> > distribution for her.
> 
> You don't know that.  Maybe she installed it herself.

If she installed Linux herself, today, then she's not Aunt Tillie.  She's "my
Aunt Tillie who's something of a computer hobbyist, and not afraid to install
a Unix-like OS on her PC alongside (or instead of) Windows".  That's a _whole_
different ballgame -- and if she can do that, then she's fully capable of
reading a little bit and answering some yes/no questions to compile a kernel.

> > She is never going to need anything out of her kernel that her
> > vendor-shipped update kernels do not provide.
> 
> *You can't know that.*  

Sure I can -- the same way I know that Ma & Pa Kettle are never going to use
their computer for more than email, web surfing, and playing Solitaire.

> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.

No, my beliefs are based on twenty years of observing people using computers
and technoogy.  I have yet to see a single person who is simultaneously (i)
technical enough to need something from their kernel that their distribution
vendor doesn't provide, and (ii) not technical enough to be able to compile it
themselves with today's tools.

I think your auto-configurator will be something of a white elephant --
equivalent to a better guide for setting the clock in your VCR.  Those people
who can't figure out how to set their VCR clock from the current instructions
are the same people who don't care whether it flashes "12:00" or not.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Charles Cazabon <charlesc@discworld.dyndns.org>:
> > Yes, and yes.  Aunt Tillie is running Linux because someone installed a
> > distribution for her.

> You don't know that.  Maybe she installed it herself.

Linux-from-scratch or some such? In which case she'd better be able to
configure a custom kernel without help...

> > She is never going to need anything out of her kernel that her
> > vendor-shipped update kernels do not provide.

> *You can't know that.*  

Right. But 99.9% of Aunt Tillies won't need anything else. To have
_everybody_ go through a lot of pain for the sake of 0.02% of Linux users
is silly. Better let Nephew Mervin keep the junkheap, and give Tilly a new
machine for her birthday.

> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.

Have you ever tried f.ex. Red Hat's installer and updater for the latest
versions (Just because it is the one I know best; other distribuctions have
similar facilities)? Have you tried a machine with Linux preinstalled?

Have you ever battled with Windows "autoconfiguration"?! _It doesn't
work_. At all. _Ever_. And that hasn't been an impediment to Aunt Tilly to
get a WinPC...

I just think that your idea is cool. You are just wasting effort on trying
to solve a non-problem, when there are lots of problems that could use your
talents.

But again, it's your own time.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> Is it OK in your world that Aunt Tillie is dependent on a distro maker?  Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?  

The two don't follow. 

The goal of a typical end user is "make it work, make it go away and do what
it did last week". Random mechanics hating car owners don't do engine tuning
jobs or fit turbochargers.

Secondly we've established we can pick the right CPU for the kernel reliably
that is seperate to modules. 

Thirdly building a lot of stuff modular is the right choice anyway - in the
world of hot plugging and USB Grandma is not going to want to recompile her
kernel because she bought a new trackball to boost her quake score. 

Alan

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> The goal of a typical end user is "make it work, make it go away and do what
> it did last week". Random mechanics hating car owners don't do engine tuning
> jobs or fit turbochargers.

No...but they do change their own oil and antifreeze.  Upgrading your
kernel should be as simple as changing your oil.
 
> Secondly we've established we can pick the right CPU for the kernel reliably
> that is seperate to modules. 

Right, but that doesn't get you a recompiled binary with extended instructions
in it.

> Thirdly building a lot of stuff modular is the right choice anyway - in the
> world of hot plugging and USB Grandma is not going to want to recompile her
> kernel because she bought a new trackball to boost her quake score. 

I'm not arguing with building a lot of stuff modular.  The autoconfiugurator
does exactly that for hot-plug buses.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
	-- Ayn Rand

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> > it did last week". Random mechanics hating car owners don't do engine tuning
> > jobs or fit turbochargers.
> 
> No...but they do change their own oil and antifreeze.  Upgrading your
> kernel should be as simple as changing your oil.

Yeah. I go to the garage versus I click "up 2 date". I don't mix custom
oils.

> > Secondly we've established we can pick the right CPU for the kernel reliably
> > that is seperate to modules. 
> 
> Right, but that doesn't get you a recompiled binary with extended instructions
> in it.

It does. Once you have picked the required processor type you will get the
right instructions. Except for the Athlon, Winchip and maybe the PIV
I've seen little evidence it matters. The Debian folk claim its worth < 1%
and I don't doubt them.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Tom Rini]

On Mon, Jan 14, 2002 at 07:14:40PM +0000, Alan Cox wrote:
> > > it did last week". Random mechanics hating car owners don't do engine tuning
> > > jobs or fit turbochargers.
> > 
> > No...but they do change their own oil and antifreeze.  Upgrading your
> > kernel should be as simple as changing your oil.
> 
> Yeah. I go to the garage versus I click "up 2 date". I don't mix custom
> oils.

And people that do change their own oil usually know something about
their cars too. 

To carry this anaology out a bit further, the people who change their
own oil  know about as much about their car(s) as the people who go and
recompile their own kernel, but don't claim to know much about the
kernel internals. 

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Larry McVoy]

On Mon, Jan 14, 2002 at 07:00:13PM +0000, Alan Cox wrote:
> Secondly we've established we can pick the right CPU for the kernel reliably
> that is seperate to modules. 

Yup, I noticed this when I did a RH 7.2 install recently, pretty spiffy.
And it seems to work, 7.2 "feels" faster, especially groff for some reason
I don't understand.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[arjan]

In article <20020114132618.G14747@thyrsus.com> you wrote:
> Not that I'm running down distro makers.  They do a valuable job, and in fact
> my approach relies on Aunt Tillie's machine starting life with an all-modular
> distro kernel.

> But the point of this game is for Aunt Tillie to have more and better
> choices.  Isn't that what we're supposed to be about?

While I'm absolutely not disputing the right of anyone to compile their own
kernel (I'm not trying to lock customers into my special platform like some
unnamed industrial giant *cough*), I just wonder why an AUTOMATIC generated
kernel with all the _relevant_ drivers modules will be "more and better"
than a (distro) kernel with _all_ drivers modules. That's the POINT of
modules -> be there or not, nothing else cares. If that's not the case
right now it's something we ought to fix first I'd say.

Of course there are other settings that do have impact (CPU type mostly,
maybe memory layout) but other than that... distros already ship several
binary versions (last I counted Red Hat ships 11 or so with RHL72) to
account for CPU type and amount etc.

Greetings,
   Arjan van d Ven

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

arjan@fenrus.demon.nl <arjan@fenrus.demon.nl>:
> Of course there are other settings that do have impact (CPU type mostly,
> maybe memory layout) but other than that... distros already ship several
> binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> account for CPU type and amount etc.

OK.  Scenario #2:

Tillie's nephew Melvin is a junior-grade geek.  He's working his way
through college doing website administration for small businesses.  He
doesn't know C, but he can hack his way around Perl and a little PHP,
and he can type "configure; make".  He's been known to wear a penguin
T-shirt.

Some time back he set up a Linux box for Joe Foonly over at Joe's
Garage.  Joe calls him back and says "Hey, kid, I gotta problem here.
Lot of hits on that website and the machine's getting sluggish when
I'm doing my books with GnuCash on it at the same time.  But what with
the recession and all, I don't want to go buying new hardware if I can
help it."

Melvin thinks to himself "OK, let's see if we can't tune this sucker a
bit."  He runs top(1) and sees a bad shortage of free RAM; the box is
an older machine, a 586-based PCI/ISA hybrid from around 1995, and
only has 32MiB of memory in it.  But Joe doesn't want to spend money
on hardware and, since money is tight all over and Joe took care of
the state inspection for Melvin's car a few weeks ago without getting
around to billing him yet, Melvin kind of needs to make the best of
the situation.

Melvin thinks this is no problem, he'll start by building a new kernel
with some stuff trimmed out to leave more RAM for userspace.  But...
uh oh!  He nuked that source tree because free disk was getting kind
of tight, and the .config went with it.  Looks like Melvin's going to
have to reconstruct his configuration by hand.

"Crap." Melvin thinks.  "I don't remember what kind of network card I
compiled in.  Am I going to have to open this puppy up just to eyeball
the hardware?" Doing that would take time Melvin was planning to spend
chatting up a girl geek he's noticed over at the computer lab.

Autoconfigure saves the day.  Possibly it even helps Melvin get laid.
--
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Freedom, morality, and the human dignity of the individual consists
precisely in this; that he does good not because he is forced to do
so, but because he freely conceives it, wants it, and loves it.
	-- Mikhail Bakunin 

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[gmack]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Date: Mon, 14 Jan 2002 14:50:35 -0500
> From: Eric S. Raymond <esr@thyrsus.com>
> To: arjan@fenrus.demon.nl
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery
>     -- the elegant solution)
> "Crap." Melvin thinks.  "I don't remember what kind of network card I
> compiled in.  Am I going to have to open this puppy up just to eyeball
> the hardware?" Doing that would take time Melvin was planning to spend
> chatting up a girl geek he's noticed over at the computer lab.

BTDT queried the current kernel for the info I needed.

ISA doesn't look like it was designed to be autodetected at least not the
really old stuff.. if it's on a 586 it's likely to be at least PnP and
therefore more easilly detectable.

IMO ISA was designed for techies and not for J Random User.


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Monday 14 January 2002 02:50 pm, Eric S. Raymond wrote:

> the hardware?" Doing that would take time Melvin was planning to spend
> chatting up a girl geek he's noticed over at the computer lab.
>
> Autoconfigure saves the day.  Possibly it even helps Melvin get laid.

You had me with you right up until the end there, then suddenly my disbelief 
precipitated out of solution...  :)

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Charles Cazabon]

Eric S. Raymond <esr@thyrsus.com> wrote:
> arjan@fenrus.demon.nl <arjan@fenrus.demon.nl>:
> > Of course there are other settings that do have impact (CPU type mostly,
> > maybe memory layout) but other than that... distros already ship several
> > binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> > account for CPU type and amount etc.
> 
> OK.  Scenario #2:

Hmm.  This scenario seems totally bogus.

[...]
> Some time back he set up a Linux box for Joe Foonly over at Joe's
> Garage.  Joe calls him back and says "Hey, kid, I gotta problem here.
> Lot of hits on that website and the machine's getting sluggish when
> I'm doing my books with GnuCash on it at the same time.
[...]
> the box is
> an older machine, a 586-based PCI/ISA hybrid from around 1995, and
> only has 32MiB of memory in it.
[...]

Hmmm, 32MiB of RAM on a 586-class machine, and its doing useful work as both a
webserver and running GnuCash?  Care to construct something more real-world?

Even at that:

> Melvin thinks this is no problem, he'll start by building a new kernel
> with some stuff trimmed out to leave more RAM for userspace.  But...
> uh oh!  He nuked that source tree because free disk was getting kind
> of tight, and the .config went with it.  Looks like Melvin's going to
> have to reconstruct his configuration by hand.
> 
> "Crap." Melvin thinks.  "I don't remember what kind of network card I
> compiled in.  Am I going to have to open this puppy up just to eyeball
> the hardware?"

Uh, no.  Try `lsmod`.

> Autoconfigure saves the day.

Autoconfigure not necessary; read the output of lsmod, or read modules.conf.
Problem solved.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Charles Cazabon <linux@discworld.dyndns.org>:
> > "Crap." Melvin thinks.  "I don't remember what kind of network card I
> > compiled in.  Am I going to have to open this puppy up just to eyeball
> > the hardware?"
> 
> Uh, no.  Try `lsmod`.

He hard-compiled in that driver.  lsmod(1) can't see it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one is bound to obey an unconstitutional law and no courts are bound
to enforce it.  	-- 16 Am. Jur. Sec. 177 late 2d, Sec 256

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Dave Jones]

On Mon, Jan 14, 2002 at 03:19:42PM -0500, Eric S. Raymond wrote:
 > > > compiled in.  Am I going to have to open this puppy up just to eyeball
 > > > the hardware?"
 > > Uh, no.  Try `lsmod`.
 > He hard-compiled in that driver.  lsmod(1) can't see it.

 $ grep eth0 /var/log/boot.msg
 <6>eth0: PCnet/FAST+ 79C972 at 0x9400, 00 a0 d2 18 c0 2c

 (Ok, it's not ISA, but it serves a point).
 
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Brian Gerst]

"Eric S. Raymond" wrote:
> 
> Charles Cazabon <linux@discworld.dyndns.org>:
> > > "Crap." Melvin thinks.  "I don't remember what kind of network card I
> > > compiled in.  Am I going to have to open this puppy up just to eyeball
> > > the hardware?"
> >
> > Uh, no.  Try `lsmod`.
> 
> He hard-compiled in that driver.  lsmod(1) can't see it.

cat /proc/ioports.  If the card is in use, it will show up there.

--

				Brian Gerst

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> > > "Crap." Melvin thinks.  "I don't remember what kind of network card I
> > > compiled in.  Am I going to have to open this puppy up just to eyeball
> > > the hardware?"
> > 
> > Uh, no.  Try `lsmod`.
> 
> He hard-compiled in that driver.  lsmod(1) can't see it.

You mean he broke the carefully designed vendor set up by running a poorly
designed autoconfig script ? See if he'd run a sensible modular one he would
be fine

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[David Woodhouse]

esr@thyrsus.com said:
>  He hard-compiled in that driver.  lsmod(1) can't see it.

man dmesg.

Others have asserted that this kind of autoconfigure facility for 
non-technical people isn't necessary.

I assert that it is actually harmful, and will make their life more 
difficult.

My father's computer runs Linux. He doesn't need to recompile his kernels 
or do any maintenance - I don't even trust him to run up2date for himself. 
It's all he can manage to dial up and look at a web page so I can grab his 
current IP address out of my logs, log in and do the rest.

If I get a bug report from him, it's not particularly coherent or useful. 
Yet because he has a kernel binary which is identical to the one used by
many other more technical users out there, I can often match what he 
complains about with the more useful bugreports in Bugzilla.

If he (or even I) compiled a custom kernel for him rather than using the 
distro one, I wouldn't have a whelk's chance in a supernova of working out 
WTF he was on about.

--
dwmw2

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Justin Carlson]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

There are many times I would have found (and, I anticipate, many times I
will find) an autoconfigurator useful in my work, if only to get a
rough-cut kernel configuration done in minimal time.  For my purposes,
it doesn't have to be 100% correct to save me some significant amount of
work.

Does this mean I'm incapable of configuring a kernel with the available
tools?  No.  And it doesn't mean I think there needs to be some grand
shift in the way distro vendors provide kernels, but this kind of a
facility would be useful for *me*.  I don't want to get into whether
this is an appropriate thing to make easily accessible to good ol' Aunt
Tillie. 

>From the other side, how does having the ability to probe local hardware
hurt?  It should be cleanly seperable from the classical build process
for the purists, and helpful to some (I think) significant portion of
the userbase, particularly those folks who like to test bleeding edge
stuff on a variety of hardware.  I don't really understand the
resistance to the idea of someone going out and implementing this.

my $.02.

-Justin

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Tom Rini]

On Mon, Jan 14, 2002 at 03:30:46PM -0500, Justin Carlson wrote:

> From the other side, how does having the ability to probe local hardware
> hurt?  It should be cleanly seperable from the classical build process
> for the purists, and helpful to some (I think) significant portion of
> the userbase, particularly those folks who like to test bleeding edge
> stuff on a variety of hardware.  I don't really understand the
> resistance to the idea of someone going out and implementing this.

Right, and this is 95% possible even.  Doing PCI stuff is rather easy
(since we've got it all mapped out even).  The problem is the 100%
point-click-run goal that Eric has.

The original sticking point was doing ISA (and other buses that are
_not_ autodetect friendly in a safe way).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alex Bligh - linux-kernel]

>> From the other side, how does having the ability to probe local hardware
>> hurt?  It should be cleanly seperable from the classical build process
>> for the purists, and helpful to some (I think) significant portion of
>> the userbase, particularly those folks who like to test bleeding edge
>> stuff on a variety of hardware.  I don't really understand the
>> resistance to the idea of someone going out and implementing this.
>
> Right, and this is 95% possible even.  Doing PCI stuff is rather easy
> (since we've got it all mapped out even).  The problem is the 100%
> point-click-run goal that Eric has.
>
> The original sticking point was doing ISA (and other buses that are
> _not_ autodetect friendly in a safe way).

& this has a seemingly obvious solution, which is, if the autoprobe
stuff is selected, and, after presentation of the initial list
of drivers, plus comments like 'Network card: none', 'Sound card: none',
say 'We may have missed some stuff if you have an old computer, press
Y if what we've detected doesn't find all your hardware', and if
they press Y (only), select as modules every ISA driver except
those, which when loaded on a system not containing the relevant
card, can cause a hangup; thus deferring the autoprobing until
boot time.

--
Alex Bligh

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Tom Rini]

On Tue, Jan 15, 2002 at 10:46:11PM -0000, Alex Bligh - linux-kernel wrote:
> >>From the other side, how does having the ability to probe local hardware
> >>hurt?  It should be cleanly seperable from the classical build process
> >>for the purists, and helpful to some (I think) significant portion of
> >>the userbase, particularly those folks who like to test bleeding edge
> >>stuff on a variety of hardware.  I don't really understand the
> >>resistance to the idea of someone going out and implementing this.
> >
> >Right, and this is 95% possible even.  Doing PCI stuff is rather easy
> >(since we've got it all mapped out even).  The problem is the 100%
> >point-click-run goal that Eric has.
> >
> >The original sticking point was doing ISA (and other buses that are
> >_not_ autodetect friendly in a safe way).
> 
> & this has a seemingly obvious solution,
[snip]

> those, which when loaded on a system not containing the relevant
> card, can cause a hangup; thus deferring the autoprobing until
> boot time.

If everything worked before as a module, this works still.  If not, you
need to have a for loop or something that attempts to load every XXX
subsystem driver.

But the point I was getting at is the 100% solution isn't possible.
Even if we narrow the scope of the problem to just x86 hardware, theres
still things which can't be solved.  Talking to random memory locations
will bite you at somepoint on some hw.  Old busses weren't designed with
any sort of autoconfig in mind.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>:
> & this has a seemingly obvious solution, which is, if the autoprobe
> stuff is selected, and, after presentation of the initial list
> of drivers, plus comments like 'Network card: none', 'Sound card: none',
> say 'We may have missed some stuff if you have an old computer, press
> Y if what we've detected doesn't find all your hardware', and if
> they press Y (only), select as modules every ISA driver except
> those, which when loaded on a system not containing the relevant
> card, can cause a hangup; thus deferring the autoprobing until
> boot time.

Not a bad idea, but it conflicts with one of the goals of 
`make autoconfigurator', which is completely hands-off opration.

Giacomo Catenazzi thinks he has collected enough "safe" probes to 
find effectively all ISA devices, by grovelling through various bits
of /proc.  So this problem may get solved directly.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Probably fewer than 2% of handguns and well under 1% of all guns will
ever be involved in a violent crime. Thus, the problem of criminal gun
violence is concentrated within a very small subset of gun owners,
indicating that gun control aimed at the general population faces a
serious needle-in-the-haystack problem.
	-- Gary Kleck, "Point Blank: Handgun Violence In America"

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Dave Jones]

On Mon, Jan 14, 2002 at 02:50:35PM -0500, Eric S. Raymond wrote:
 > "Crap." Melvin thinks.  "I don't remember what kind of network card I
 > compiled in.  Am I going to have to open this puppy up just to eyeball
 > the hardware?" Doing that would take time Melvin was planning to spend
 > chatting up a girl geek he's noticed over at the computer lab.
 > Autoconfigure saves the day.  Possibly it even helps Melvin get laid.

 Unless of course, geekgirl realises what a dork Melvin was for
 not doing something like lsmod / looking in /var/log/messages for
 boot messages showing not only what card he has, but what driver
 he needs.

 Common sense saves the day. Possibly it even saves Melvin making an ass
 of himself. 8-)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
> On Mon, Jan 14, 2002 at 02:50:35PM -0500, Eric S. Raymond wrote:
>  > "Crap." Melvin thinks.  "I don't remember what kind of network card I
>  > compiled in.  Am I going to have to open this puppy up just to eyeball
>  > the hardware?" Doing that would take time Melvin was planning to spend
>  > chatting up a girl geek he's noticed over at the computer lab.
>  > Autoconfigure saves the day.  Possibly it even helps Melvin get laid.
> 
>  Unless of course, geekgirl realises what a dork Melvin was for
>  not doing something like lsmod / looking in /var/log/messages for
>  boot messages showing not only what card he has, but what driver
>  he needs.

Right now, neither lsmod nor the boot time messages  necessarily give you that 
information.  lsmod only works if the driver is in fact a module.  My 
/var/log/dmesg contains no message from the NIC on my motherboard.  And
going from the driver to the config symbol isn't trivial even if you *have*
the lsmod or dmesg information.  

And anyway there are settings you can't even recover by looking at the
hardware, such as whether KHTTPD or BSD process accounting were turned
on.

Sure, Melvin could remember a whole bunch of state, or a whole bunch
of rules for reconstructing it. But isn't sweating that kind of detail
exactly what *computers* are for?  

Melvin, you may be sure, has more important things on his mind...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

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

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Right now, neither lsmod nor the boot time messages  necessarily give you that
> information.  lsmod only works if the driver is in fact a module.  My
> /var/log/dmesg contains no message from the NIC on my motherboard.  And
> going from the driver to the config symbol isn't trivial even if you *have*
> the lsmod or dmesg information.

For network cards one needs only to issue the ETHTOOL_GDRVINFO ioctl to
find out what hardware is associated with an ethernet interface.

	Jeff


-- 
Jeff Garzik      | Alternate titles for LOTR:
Building 1024    | Fast Times at Uruk-Hai
MandrakeSoft     | The Took, the Elf, His Daughter and Her Lover
                 | Samwise Gamgee: International Hobbit of Mystery

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Dave Jones]

On Mon, Jan 14, 2002 at 05:07:37PM -0500, Jeff Garzik wrote:
 > 
 > For network cards one needs only to issue the ETHTOOL_GDRVINFO ioctl to
 > find out what hardware is associated with an ethernet interface.

 but not all the net drivers support this yet do they?

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Jeff Garzik]

Dave Jones wrote:
> 
> On Mon, Jan 14, 2002 at 05:07:37PM -0500, Jeff Garzik wrote:
>  >
>  > For network cards one needs only to issue the ETHTOOL_GDRVINFO ioctl to
>  > find out what hardware is associated with an ethernet interface.
> 
>  but not all the net drivers support this yet do they?

correct.  But it is the proper path one should take on this particular
train of thought ;-)

-- 
Jeff Garzik      | Alternate titles for LOTR:
Building 1024    | Fast Times at Uruk-Hai
MandrakeSoft     | The Took, the Elf, His Daughter and Her Lover
                 | Samwise Gamgee: International Hobbit of Mystery

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Reid Hekman]

On Mon, 2002-01-14 at 14:38, Eric S. Raymond wrote:
> Right now, neither lsmod nor the boot time messages  necessarily give you that 
> information.  lsmod only works if the driver is in fact a module.  My 
> /var/log/dmesg contains no message from the NIC on my motherboard.  And
> going from the driver to the config symbol isn't trivial even if you *have*
> the lsmod or dmesg information.  

Yes, getting the current used environment from the running kernel in a
simple way would be nice. Actually, I'm interested in trying out your
autoconfigurator, though I'll be one to go back to the config and look
it over. The Aunt Tillie scenario doesn't preclude the usefulness of an
autoconfig tool.

> Sure, Melvin could remember a whole bunch of state, or a whole bunch
> of rules for reconstructing it. But isn't sweating that kind of detail
> exactly what *computers* are for?  

Precisely. The Real Problem(TM) is there are more issues than initial
kernel configuration that effect the details the user installing a
kernel or device is required to know. For a real example of this -- Grip
fails to see an audio CD in my CDRW when ide-scsi is loaded, DVD
playback is also slower but I need ide-scsi so I can backup CD's from
one drive to another. Right now, if I want to do one or another task, I
need to reboot using different kernel command lines, with a script to
alter my /dev links so the relevant apps continue to work. For another,
some of my apps need to be poked and prodded when my USB webcam hops
from /dev/video1 to /dev/video0 depending on whether bttv was or not.

Fixing those bits will allow vendors to make better and easier choices
with supplied kernels, at which point initial kernel (auto)configuration
becomes less important. I guess it's part of what Linus calls growing to
have a "middle-aged" kernel.  

Anyway, I know it's not a zero sum game. We can't make Eric stop work on
one thing and make him do another. In what ways could an
autoconfigurator better work in today's environment? What could the
kernel do to make that job easier while not offending people too much?

Regards,
Reid

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Timothy Covell]

OK, drop what you're holding and prepare to load up on rotten
tomatoes, but I know that there is a solution.    Inasmuch as I
am a fan of Linux and BeOS, I think that the way to go is
with just about everything (sans networking perhaps) built
as a kernel module just like what is being discussed.    Nothing
is simpler in BeOS than downloading a driver and plopping
it in $HOME/config/add-ons/kernel/busses/ieee1394 (most install
scripts do this for the user or provides a "drag this driver to here"
link.   And with BeOS, the boot menu allows one to disable 
"user add-ons" so that if there is a problem with the module, one 
can disable it.  

	Yes, this doesn't please the server folks.  For them,
I think that we should either leave the monolithic build as an
option or find a way to get rid off any penalties to using modules.

	BeOS, autoconfigures and loads all drivers in the
15 seconds or so that it takes to achieve a complete hard
boot.    That much said, BeOS only supports good hardware
and left ISA stuff to user to play with (via a GUI tool).   I really 
do not see the value of any more discussion of how to 
autoconfigure ISA/MCA/EISA/VLB cards.   The vast majority 
of people using those systems are:

1. Still stuck in DOS World
2. Use M$ anyway
3. Would be afraid to upgrade their kernel
4. Think it's cool to have a Beowulf cluster of 386s
5. Forgot to turn off their computers before they died
6. Ancient sattelite based missile silos which we
wouldn't want to touch anyhow.....


-- 
timothy.covell@ashavan.org.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Hugh Dickins]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> 
> Tillie's nephew Melvin is a junior-grade geek.  He's working his way
...
> Some time back he set up a Linux box for Joe Foonly over at Joe's
> Garage.  Joe calls him back and says "Hey, kid, I gotta problem here.
...
> Autoconfigure saves the day.  Possibly it even helps Melvin get laid.
...
> so, but because he freely conceives it, wants it, and loves it.

This is terrific stuff!  "The Bold & the Bazaarre"?

Hugh

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> "Crap." Melvin thinks.  "I don't remember what kind of network card I
> compiled in.  Am I going to have to open this puppy up just to eyeball
> the hardware?" Doing that would take time Melvin was planning to spend

So he builds a kernel with modular setups just like the vendor kernel. The
existing module configuration and setup data that worked with the old
kernel keeps working and he has time to read up on his technique and get
laid.

I just don't buy your examples. Eric all I can think is that you have seriously 
weird relatives.

Alan

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > "Crap." Melvin thinks.  "I don't remember what kind of network card I
> > compiled in.  Am I going to have to open this puppy up just to eyeball
> > the hardware?" Doing that would take time Melvin was planning to spend
> 
> So he builds a kernel with modular setups just like the vendor kernel. The
> existing module configuration and setup data that worked with the old
> kernel keeps working and he has time to read up on his technique and get
> laid.

Where did your assumption that Melvin has the canned config files to
do that still available come from?  More fundamentally: which should 
he *have* to have those configs available?
 
> I just don't buy your examples. Eric all I can think is that you
> have seriously weird relatives.

Correct.  My relatives are *much* weirder than Melvin and Tillie :-).
-- 
		<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: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> Where did your assumption that Melvin has the canned config files to
> do that still available come from?  More fundamentally: which should 
> he *have* to have those configs available?

Because the GPL says he's entitled to them ?

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > Where did your assumption that Melvin has the canned config files to
> > do that still available come from?  More fundamentally: which should 
> > he *have* to have those configs available?
> 
> Because the GPL says he's entitled to them ?

You miss my point.  Sure he's entitled to them.  But why should he
*have to have them*?  They're extra state which, in the presence
of a proper autoconfigurator, he doesn't need.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
        -- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

> > Because the GPL says he's entitled to them ?
> 
> You miss my point.  Sure he's entitled to them.  But why should he
> *have to have them*?  They're extra state which, in the presence
> of a proper autoconfigurator, he doesn't need.

You have it backwards. The _autoconfigurator_ is extra state which in the
presence of the config he doesn't need

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > You miss my point.  Sure he's entitled to them.  But why should he
> > *have to have them*?  They're extra state which, in the presence
> > of a proper autoconfigurator, he doesn't need.
> 
> You have it backwards. The _autoconfigurator_ is extra state which in the
> presence of the config he doesn't need

Oh, come on Alan.  You can do better than that.  

If Melvin loses the autoconfigurator, there's no state he has to reconstruct.
There will be one exactly like it in the next tarball.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

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

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Marco Colombo]

On Mon, 14 Jan 2002, Alan Cox wrote:

> > > Because the GPL says he's entitled to them ?
> > 
> > You miss my point.  Sure he's entitled to them.  But why should he
> > *have to have them*?  They're extra state which, in the presence
> > of a proper autoconfigurator, he doesn't need.
> 
> You have it backwards. The _autoconfigurator_ is extra state which in the
> presence of the config he doesn't need
> -
> 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/
> 

Alan, Eric (and others, too), please.
Of course the autoconfigurator is an useful piece of software.
And of course Eric is posting to the wrong list here. Kernel developers
don't need any autoconfigurator at all (yes, it's just "extra state").

Eric, Aunt Tillie doesn't need any custom-made, untested, probably not
working kernel. QA comes at a price. The lastest VM fix may take a while
to reach mainstream kernels. That's life.

Face it, you're under the wrong assumption that Alan's 2.2 or Marcelo's 2.4
vanilla kernels are "better" than their patched counterparts shipped by
distro vendors. This is far from the truth[*]. Only very recent 2.2 kernels
can be installed on a Red Hat 6.x with little pain. Call it Red Hat's fault,
or mine, for choosing RH, (it's not Alan's of course), but I wanted
RAID 0.90 from the beginning.
Maybe today you can upgrade most 2.4-based distros to the latest Marcelo's,
but I bet it's going to change as soon as vendors start patching their own
kernels with random backports from 2.5.

No matter how you put it, 99% of the times your autoconfigurator will
produce a previuosly untested configuration. We can discuss about release
policies forever, but Marcelo isn't expected to replicate all the QA job
vendors do before releasing a kernel. Now, the kernel is modular
enough not to turn the issue into a nightmare for the average developer.
Most of the time you DO keep your old .config around. And you know your HW.
And the vanilla kernel you've just compiled happens to work. But you'd
better do some testing before putting it on any production box.
And of course, I consider Aunt Tillie's PC definitely "production".

In the end, I think you're just pushing the right piece of software
on the wrong list. IMHO, endusers compiling the kernel it's not an l-k
issue, it's a distro one.

[*] That is, from Aunt Tillie's standpoint.

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alex Bligh - linux-kernel]

--On Monday, 14 January, 2002 9:15 PM +0000 Alan Cox 
<alan@lxorguk.ukuu.org.uk> wrote:

>> "Crap." Melvin thinks.  "I don't remember what kind of network card I
>> compiled in.  Am I going to have to open this puppy up just to eyeball
>> the hardware?" Doing that would take time Melvin was planning to spend
>
> So he builds a kernel with modular setups just like the vendor kernel.

& if this is the sole aim, just (configurably no doubt) stick
.config somewhere in initramfs as part of the build process
and you have no parsing to do whatsoever.

For added contraversiality, optionally stick it (gzipped at source)
inside some module that registers an entry into /proc. This
means it only occupies its gzipped space in RAM. & yes I know
this has been discussed before.

However, I'd submit that recovering the previous .config file
is the least of your problems. If I'm the only one who tries
to beg/borrow/steal config fies form other machines I've built,
the net at large, etc. etc., then tweak then, rather than
mis-answer a seemingly endless sequence of questions, I'll eat
hat.

Besides if the user is clued up enough to go buy (for example)
a GigE card, they will know it's possible they have to turn
the option on in the driver, and making small incremental
changes like that are relatively easy. What's hard is (for
instance) when kernel builds with particular .config files
hang hard on boot. Normally once you have something 'nearly
working' tweaking it to suit your taste is relatively
easy (as you change only one thing at a time). But my
practice, and I'm sure I'm not alone, is to start off
either with a config I've used elsewhere, or one someone
else has developed for that machine (the latter being
the only option for Aunt Tillie). [I then do a diff between
what I used, and the other option, and start integrating
changes - being able to show Aunt Tillie the difference
between vendor options and ones 'for her machine' would
doubtless be useful]

--
Alex Bligh

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Tom Rini]

On Tue, Jan 15, 2002 at 10:17:13PM -0000, Alex Bligh - linux-kernel wrote:
 
> & if this is the sole aim, just (configurably no doubt) stick
> .config somewhere in initramfs as part of the build process
> and you have no parsing to do whatsoever.

initramfs goes away, I believe.  But most vendors stick their config in
/boot/config-`uname -r`, and last I looked at kbuild-2.5, it asked if
you wanted to stick your .config in /lib/modules/`uname -r` (which is
default loc for System.map too..)  Or maybe it just did it.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Keith Owens]

On Tue, 15 Jan 2002 16:22:52 -0700, 
Tom Rini <trini@kernel.crashing.org> wrote:
>... and last I looked at kbuild-2.5, it asked if
>you wanted to stick your .config in /lib/modules/`uname -r` (which is
>default loc for System.map too..)  Or maybe it just did it.

The first time you make oldconfig kbuild 2.5 asks if you want to
install System.map and .config, separate questions.  If you say y then
it asks where you want to install the files, with a default of
/lib/modules/`uname -r`/.  Once set, the values propagate to subsequent
builds that use the same .config.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[T. A.]

----- Original Message -----
From: "Eric S. Raymond" <esr@thyrsus.com>
To: <arjan@fenrus.demon.nl>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, January 14, 2002 2:50 PM
Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --
the elegant solution)


> arjan@fenrus.demon.nl <arjan@fenrus.demon.nl>:
> > Of course there are other settings that do have impact (CPU type mostly,
> > maybe memory layout) but other than that... distros already ship several
> > binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> > account for CPU type and amount etc.
>
> OK.  Scenario #2:
>
> Tillie's nephew Melvin is a junior-grade geek.  He's working his way
> through college doing website administration for small businesses.  He
> doesn't know C, but he can hack his way around Perl and a little PHP,
> and he can type "configure; make".  He's been known to wear a penguin
> T-shirt.
>>> SNIP <<<
> Autoconfigure saves the day.  Possibly it even helps Melvin get laid.
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>

    I see!!!  I see the light now!!!  I see it all now!!!  I have been
saved!!!  If your super doper kernel autoconfigurator goes into the kernel
source tree then all of geekdom will have a possibility of getting laid.
Marvelous.  Absolutely marvelous.  I always knew coding would be able to
overcome any kind of obstacle for us, even this one.  Horrah.  8-D

    8-D  Of course wantabe geek (if there is such a thing) Melvin could
always do it the hard way.  The experience might come in handy for the next
"internet" bubble to arise.  With the knowledge he gains he can make enough
paper money to take care of the getting laid problem once and for all (or at
least until the next crash).  Besides his current target seams way too easy
if he has a chance at her just because he entered "configure".  8-D

    Well anyway seams CML2 is becoming a literal everything and the kitchen
sink.  Wow.  8-D  So far my new kernel is going to require Python to
configure it, will include an super doper hardware detector so that it can
customize my spiffy new kernel specifically to my hardware, will include
special kernel access for regular users to be able to read my hardware
configuration because its so evil to configure my kernel as root even though
I will have to be root to install it and probably be root to untar/ungzip it
into /usr/src and not to mention removing the old /usr/src/linux, did I read
new driver model for autoconfiguring kernel somewhere too?, and the kernel
will even included a spiffy X Windows, KDE, or gnome (hey why skimp now)
program that installs itself as an icon on the user desktop (no matter what
the distribution, linux-kernel will support all) which the user can then
click on to fire up the kernel self-configuration, self-compiler,
self-installer, and auto boot loader configurator so that Aunt Tilly or the
slutty girl El Geeko has his eyes on can see a "Click here to launch new
kernel" button on their screen after their first reboot, oh and of course we
can't forget that the kernel must know that its either succeeded or failed
so that it could tell the user that and either restore the previous boot
configuration or install itself as the user's new default kernel thus
voiding the plebeian's support contract.  But no problem, I'm sure the new
kernel can take care of that too.  Just give it time.  8-D

    Hilarities aside, I wouldn't mind having a program to automatically
configure a kernel for a system via Windows-like hardware autoconfiguration.
However do have a couple of quick points.

    1. Don't see any reason for the kernel hardware autoconfigurator to be
included in the kernel.

    2. Don't see any reason the kernel hardware autoconfigurator cannot be
run as root.  Actually see one very good reason why it shouldn't be able to
be run as a regular user.  Probing certain hardware is inherently dangerous.
Machine can hang.  Hardware could be probed to death.  Heck a clever coder
could even make use of the user level access required to allow user hardware
autoconfiguration.  Wiping disks, destroying flash roms, finding system
backdoors, etc, etc.

    3. ISA is pretty much dead outside of certain standard PC equipment.
And of the remaining ISA out there, most in any machine than can still run a
Linux kernel effectively is most likely PNP ISA.  Plus there are a few
fairly common ISA cards that can also be found easily.  It seams that the
vast majority of Aunt Tillies will be served with just PCI autoconfiguration
and maybe PNP ISA configuration.

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> arjan@fenrus.demon.nl <arjan@fenrus.demon.nl>:
> > Of course there are other settings that do have impact (CPU type mostly,
> > maybe memory layout) but other than that... distros already ship several
> > binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> > account for CPU type and amount etc.
> 
> OK.  Scenario #2:
> 
> Tillie's nephew Melvin is a junior-grade geek.  He's working his way
> through college doing website administration for small businesses.  He
> doesn't know C, but he can hack his way around Perl and a little PHP,
> and he can type "configure; make".  He's been known to wear a penguin
> T-shirt.

> [Melvin needs a hand-tailored kernel for a crappy webserver. Source is
>  _long_ gone]

Melvin is a html-only geek, but not stupid. He knows where he can get the
sources for the distribution's kernel, and he knows very well that it is
advisable to stick to the distribution's software. He understands enough of
the process so he can tailor a kernel for _webserving_, not optimal use of
all hardware on Ye Olde Coffepot. He leaves out sound, serial support, and
acceleration support for the video card (What for in a webserver?),
configures floppy and CD as modules (to save the odd byte), just ext3 as
builtin filesystem (no need for all the others, iso9660 is module for some
savings). He includes iptables support, but no connection tracking or NAT
modules. All things an autoconfigurator wouldn't dream of doing on its own.

[Again, building a tailored kernel for a specific application on a crappy
 machine is no place for automatism; for everything else an Aunt Tillie
 might need a "get nearest size" is enough]

[...]

> "Crap." Melvin thinks.  "I don't remember what kind of network card I
> compiled in.  Am I going to have to open this puppy up just to eyeball
> the hardware?" Doing that would take time Melvin was planning to spend
> chatting up a girl geek he's noticed over at the computer lab.

If Melvin did compile the kernel in the first place, he is smart enough to
keep .configure around. If not, he doesn't deserve getting laid.

For terminally stupid Melvins, keep .configure around somewhere.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Ben Collins]

On Mon, Jan 14, 2002 at 01:26:18PM -0500, Eric S. Raymond wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > Now to do everything you describe does not need her to configure a custom
> > kernel tree. Not one bit. You think apt or up2date build each user a custom
> > kernel tree ?
> 
> Is it OK in your world that Aunt Tillie is dependent on a distro maker?  Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?  
> 
> Not that I'm running down distro makers.  They do a valuable job, and in fact
> my approach relies on Aunt Tillie's machine starting life with an all-modular
> distro kernel.
> 
> But the point of this game is for Aunt Tillie to have more and better
> choices.  Isn't that what we're supposed to be about?

Wouldn't it be better for Aunt Tillie to continue using an all modular
kernel (from a distro) so she doesn't have to "update" (in your example,
that means recompile) a new one everytime she adds new hardware? Does
she have to connect all of here 1394 and USB devices to the computer
during this phase in order to have them all supported?


Ben

-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/                   Ben Collins    --    Debian GNU/Linux                  \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Tom Gilbert]

* Eric S. Raymond (esr@thyrsus.com) wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > Now to do everything you describe does not need her to configure a custom
> > kernel tree. Not one bit. You think apt or up2date build each user a custom
> > kernel tree ?
> 
> Is it OK in your world that Aunt Tillie is dependent on a distro maker?  Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?  

$ apt-cache search kernel-image | grep 2.4.17
kernel-image-2.4.17-386 - Linux kernel image for version 2.4.17 on 386.
kernel-image-2.4.17-586tsc - Linux kernel image for version 2.4.17 on
Pentium-Classic.
kernel-image-2.4.17-686 - Linux kernel image for version 2.4.17 on
PPro/Celeron/PII/PIII.
kernel-image-2.4.17-686-smp - Linux kernel image 2.4.17 on
PPro/Celeron/PII/PIII SMP.
kernel-image-2.4.17-k6 - Linux kernel image for version 2.4.17 on AMD
K6/K6-II/K6-III
kernel-image-2.4.17-k7 - Linux kernel image for version 2.4.17 on AMD K7
pcmcia-modules-2.4.17-386 - PCMCIA Modules for Linux (kernel
2.4.17-386).

Aunt Tillie's distro autodetects her processor type and installs the
appropriate image. Aunt Tillie's distro provides precompiled,
preconfigured, modular kernels which require no configuration. Aunt
Tillie clicks on the "check for software updates" icon on her desktop
and her distro installs security fixes, new software, and a new kernel.

Aunt Tillie doesn't even have to _know_ she needs a better VM.
 
> But the point of this game is for Aunt Tillie to have more and better
> choices.  Isn't that what we're supposed to be about?

$ apt-cache search kernel-image | wc -l      
     49

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@linuxbrit.co.uk    |
  ^^-^^   `-------------------------------------------------------'

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Dave Jones]

On Mon, Jan 14, 2002 at 12:52:28PM -0500, Eric S. Raymond wrote:
 > She complains of occasional lockups, and that she gets skips when
 > playing her Guy Lombardo MP3s.  Melvin says, over the phone: "Yup,
 > that version had some VM problems.  And you need the low-latency stuff
 > that went in three releases ago.

 ... and the 200 patches that the vendor added that she's become
 so used to just being there...

 > Just click on the 'kernel update' icon on your desktop."

 *sigh*, and the package updater to get a new kernel for $distro
 is insufficient because ?
 distro kernel update has the following advantages.
 - Comes complete with the 200 patches already applied.
 - Is _tested_ by $distrovendor.
 - If it screws up, and Aunt Tillie shelled out for support
   (which of course, she did being the 'needing support' type)
   $distrovendor will help. Ringing support and saying "Melvin
   told me to install a new kernel, and now my box doesn't boot"
   may not be a supportable scenario for all vendors.
 
 > So why doesn't she use Red Hat or Mandrake's RPM update?  Maybe she's
 > running something else.

 Red Hat & Mandrake are not the only distros with online update,
 in fact, it's probably considered a must-have feature for most
 distros these days.

 > (You ain't going to tell me Aunt Tillie is ready
 > for Debian apt-get, either.)

 Wait a minute. Not ready for 'apt-get', but ready to build & run a
 kernel made up of a collection of random patches on Melvin's say-so ?
 
 > Maybe she wants a kernel that's compiled
 > for her AMD Athlon K6 rather than a 386.
 
 Various distro vendors update facilities give you this option.
 
 > OK, so she doesn't know what processor she has
 
 Some even autodetect.
 
 > We have the technology to do all of this now;
 
 Indeed. It's called YaST, Red Carpet, Mandrake Update, apt-get,
 apt-rpm, and a plethora of other such tools.
 
 > It takes a different way of thinking than most hackers are used to.

 Yup. One where reinventing the wheel seems appropriate.

 > We're proud of our mad programming skillz and our ability to wrestle
 > with arcana.  That pride isn't a bad thing -- except when it gets in
 > the way of designing systems that Aunt Tillie can use.

 The systems are designed, and the punchline is, that they work,
 and they're being used out there today.

 Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Larry McVoy]

On Mon, Jan 14, 2002 at 07:38:24PM +0100, Dave Jones wrote:
> On Mon, Jan 14, 2002 at 12:52:28PM -0500, Eric S. Raymond wrote:
>  > She complains of occasional lockups, and that she gets skips when
>  > playing her Guy Lombardo MP3s.  Melvin says, over the phone: "Yup,
>  > that version had some VM problems.  And you need the low-latency stuff
>  > that went in three releases ago.
> 
>  ... and the 200 patches that the vendor added that she's become
>  so used to just being there...

Yeah, what Dave said.  Eric, your approach is pushing Aunt Tillie towards
more variations and what the Aunt Tillie needs is less.   Ditto for the
distro vendors.  They want as few as possible different kernels running
out there, the more variations there the greater the support load.  It's
the *opposite* of what the Linux kernel community wants, they want the 
broadest coverage of combinations they can get, that shows up more bugs.
If a distro vendor could get away with exactly one kernel config, they
would.  Even if it made for a 20MB kernel image, the support tradeoff 
is a win.

Supporting products for Aunt Tillie is very different than supporting
products for a bunch of hackers.  One wants "it works" and the other
wants "the source".
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Henrique de Moraes Holschuh]

On Mon, 14 Jan 2002, Larry McVoy wrote:
> On Mon, Jan 14, 2002 at 07:38:24PM +0100, Dave Jones wrote:
> If a distro vendor could get away with exactly one kernel config, they
> would.  Even if it made for a 20MB kernel image, the support tradeoff 
> is a win.

Looks like Debian's look-mama-I-can-beat-godzila-hands-down 2.4 kernel
packages with everything AND the kitchen sink...  :)  They eat about 20Mb of
diskspace, I think.

Package: kernel-image-2.4.16-k7
Installed-Size: 22976

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

hmh@rcm.org.br (Henrique de Moraes Holschuh) said:

[...]

> Looks like Debian's look-mama-I-can-beat-godzila-hands-down 2.4 kernel
> packages with everything AND the kitchen sink...  :)  They eat about 20Mb of
> diskspace, I think.
> 
> Package: kernel-image-2.4.16-k7
> Installed-Size: 22976

Red Hat's 2.4.6-13 for i686 adds up to 50297287 bytes.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alex Bligh - linux-kernel]

--On Monday, 14 January, 2002 10:53 AM -0800 Larry McVoy <lm@bitmover.com> 
wrote:

> Eric, your approach is pushing Aunt Tillie towards
> more variations and what the Aunt Tillie needs is less.   Ditto for the
> distro vendors.

Not entirely.

If Aunt Tillie has (say) a laptop, I think she is likely to find that no
distribution kernel actually supports all features (sound, APM, etc.)
if the laptop is even moderately new. This from experience with
Redhat & Debian (perhaps the others are miles better). So she
does indeed have a reasonable need to compile a kernel.

However, Eric's approach (dmesg) is still flawed as normally
the way these distros fail is either (a) hanging on boot, or
(b) failing to detect the relevant hardware. Needless to say,
neither failure mode is going to give much use to a configurator
tool which looks at dmesg.

Eric: I think you'd be far better off trying to identify the
machine (and hence get a working .config) rather than the
hardware.

Example: put in some wget based thingy, which goes to some (fixed) web
site, searches for (some extracted or Tillie composed string) which
describes the hardware (bound to have been bought as-is and never opened),
pulls down a set of config files and heuristics to determine between them
(look at BIOS, or 'that model will always show this or that in the PCI
table') and guesses the correct (initial) config as tested by some other
user. This is the automated equivalent of going to www.google.com/linux,
typing your machine name followed by 'kernel .config'. If the site
it contacted was configurable by the distro, you'd then have
the distros praising you in that once they have solved the problem
for one IBM T23, they've solved it for all of them, without doing
a new release. And Aunt Tillie (apart from the module changes whatever)
can be using the kernel version etc. from their distro (recompiled),
rather than the latest 2.[2468].xx with lots of new bugs^Wunwanted
fixes in.

--
Alex Bligh

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Tuesday 15 January 2002 04:38 pm, Alex Bligh - linux-kernel wrote:

> However, Eric's approach (dmesg) is still flawed as normally
> the way these distros fail is either (a) hanging on boot, or
> (b) failing to detect the relevant hardware. Needless to say,
> neither failure mode is going to give much use to a configurator
> tool which looks at dmesg.

"make autoconfigure" looks at a bunch of things, one of which is dmesg.  (It 
also looks at the PCI bus, isapnp, enumerates filesystems in use out of the 
mounted partitions, checks /proc/cpuinfo to see what to optimize for...)

It's actually doing a fairly decent job, although it's not quite ready for 
prime time yet.  (Improving rapidly, of course, as we continue to thump on 
it. :)

> Eric: I think you'd be far better off trying to identify the
> machine (and hence get a working .config) rather than the
> hardware.
>
> Example: put in some wget based thingy, which goes to some (fixed) web
> site, searches for (some extracted or Tillie composed string) which
> describes the hardware (bound to have been bought as-is and never opened),
> pulls down a set of config files and heuristics to determine between them
> (look at BIOS, or 'that model will always show this or that in the PCI
> table') and guesses the correct (initial) config as tested by some other
> user.

Meaning you'll continue to be six months behind the curve, and fail every 
time Dell tweaks its laptop layout.  (Dell does things like switch sound 
chips without switching model numbers ALL THE TIME.)

Are you volunteering to maintain this database?

So no-name assembled white boxes from e-machines and stuff wouldn't be 
supported?

Have you TRIED the current auto-configurator?

> This is the automated equivalent of going to www.google.com/linux,
> typing your machine name followed by 'kernel .config'. If the site
> it contacted was configurable by the distro, you'd then have
> the distros praising you in that once they have solved the problem
> for one IBM T23, they've solved it for all of them, without doing
> a new release.

Assuming every IBM T23 has the same hardware in it, which oddly enough is a 
bit of a gamble.  (OK, IBM is better at this than Dell, largely due to 
inventory management reasons.)  And assuming the finite number of database 
maintainers has yet bought an IBM T23, and that the rest of the world can 
wait until then.

Requiring live network access for the autoconfigurator to work is one heck of 
an extra requirement, though.  Most of the world is still using dialup, you 
know...

> And Aunt Tillie (apart from the module changes whatever)
> can be using the kernel version etc. from their distro (recompiled),
> rather than the latest 2.[2468].xx with lots of new bugs^Wunwanted
> fixes in.

You want to write some other tool.

In order to compile a new kernel and use it on a new machine, you need to 
configure it, which is time consuming and tedious, and can require a bit of 
detective work.  This is a problem that Giacamo and Eric decided to address.

This is NOT the problem you're trying to address.

Aunt Tillie is a side issue.  She's going to continue to run Windows until 
Linux comes preinstalled on her new computer, or until somebody ELSE installs 
it for her and does an awful lot of hand holding.  And what she probably 
really WANTS is an iMac. :)

Autoprobing PCI is -EASY-.  Almost trivial.  USB and PCMCIA/Cardbus were 
DESIGNED to be autoprobed.  Finding out your CPU type and chipset aren't too 
hard either.

It's really the old nasty ISA devices that are a pain to auto-probe, and they 
are finally, mercifully, dying off.  The newer and more naieve the user, the 
less likely they are to have lashed together an old 486 with VESA local bus, 
three different SCSI adapters, a CD-ROM hanging off the sound blaster, and a 
ham radio interface plugged into the parallel port.  Autoprobe really should 
become EASIER as time goes on.

Giacamo and Eric started work on the autoprobe as a way to reduce the number 
of questions the configurator showed people by eliminating hardware that they 
provably do not have, and defaulting the stuff they DO have to on.  But it 
turns out that on any relatively recent machine, it's an easy enough problem 
that you can autoprobe EVERYTHING and build straight from that.  So the Linux 
kernel could finally do "configure; make; make install".

I consider that a neat hack.

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alex Bligh - linux-kernel]

Rob,

>> Example: put in some wget based thingy, which goes to some (fixed) web
>> site, searches for (some extracted or Tillie composed string) which
>> describes the hardware (bound to have been bought as-is and never
>> opened), pulls down a set of config files and heuristics to determine
>> between them (look at BIOS, or 'that model will always show this or that
>> in the PCI table') and guesses the correct (initial) config as tested by
>> some other user.
>
> Meaning you'll continue to be six months behind the curve, and fail every
> time Dell tweaks its laptop layout.  (Dell does things like switch sound
> chips without switching model numbers ALL THE TIME.)
>
> Are you volunteering to maintain this database?

No, noone 'maintains' it; I actually /meant/ search.
So if you run it on a Redhat distribution, it goes queries
redhat first, then lists
  IBM T23 - Alex Bligh
  IBM T23 new version - Rob Landley
...
etc.

IE is the minimum amount of automation to simulate typing the thing
into google. (the advantage of doing this over using google
alone is that X may not be working at this stage and lynx
might daunt Aunt Tillie).

Obviously you will need some magic tag at the top of a config
file to make it easilly identifiable to search engines. And no
doubt some fools will fill files with crap.

> So no-name assembled white boxes from e-machines and stuff wouldn't be
> supported?

Correct; I'm sure the probing configurator has a place too.

> Have you TRIED the current auto-configurator?

No, to be honest. However, now you have set me the challenge, I'll
report back on how well or otherwise it works.

> Assuming every IBM T23 has the same hardware in it, which oddly enough is
> a  bit of a gamble.  (OK, IBM is better at this than Dell, largely due to
> inventory management reasons.)  And assuming the finite number of
> database  maintainers has yet bought an IBM T23, and that the rest of the
> world can  wait until then.

Well, you'd wait until either your distro vendor had done one, or
someone else had posted one and it had reached search-engine
du-jour.

> Requiring live network access for the autoconfigurator to work is one
> heck of  an extra requirement, though.  Most of the world is still using
> dialup, you  know...

True.

>> And Aunt Tillie (apart from the module changes whatever)
>> can be using the kernel version etc. from their distro (recompiled),
>> rather than the latest 2.[2468].xx with lots of new bugs^Wunwanted
>> fixes in.
>
> You want to write some other tool.

Perhaps you are right.

> Giacamo and Eric started work on the autoprobe as a way to reduce the
> number  of questions the configurator showed people by eliminating
> hardware that they  provably do not have, and defaulting the stuff they
> DO have to on.  But it  turns out that on any relatively recent machine,
> it's an easy enough problem  that you can autoprobe EVERYTHING and build
> straight from that.  So the Linux  kernel could finally do "configure;
> make; make install".
>
> I consider that a neat hack.

Sure I agree, if it works; my speculation is that it doesn't, if one
boots with a default vendor kernel, on many machines. I would love
to be proved wrong, so rather than debate further here, I have another
T23 to set up so I'll boot it up from scratch, run the configurator,
and see what happens.

--
Alex Bligh

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Rob Landley]

On Wednesday 16 January 2002 09:33 am, Alex Bligh - linux-kernel wrote:

> IE is the minimum amount of automation to simulate typing the thing
> into google. (the advantage of doing this over using google
> alone is that X may not be working at this stage and lynx
> might daunt Aunt Tillie).

So you're advocating feeding random stuff from the internet directly to end 
users without any sturgeon's law filter at all, and this is an improvement 
over automated probing of mostly standards-compliant busses for known 
hardware?

> Obviously you will need some magic tag at the top of a config
> file to make it easilly identifiable to search engines. And no
> doubt some fools will fill files with crap.

I was specifically thinking Microsoft, actually.  And every script kiddie in 
existence who thinks screwing up the linux automated install gives them 31337 
status.  (A new reason to crack webservers: add links to poison the google 
cache.  Sigh...)

> > So no-name assembled white boxes from e-machines and stuff wouldn't be
> > supported?
>
> Correct; I'm sure the probing configurator has a place too.

I'm all for having a "known strange" list.  Eric volunteered to maintain one 
in regards to DMI, which is sort of per-motherboard anyway.

But I tend to lean in favor of a having a maintainer for a database people 
contribute exceptions to.  Which basically means we might as well just make 
the autoprober smarter via an exception list...

> > Have you TRIED the current auto-configurator?
>
> No, to be honest. However, now you have set me the challenge, I'll
> report back on how well or otherwise it works.

At the moment, "make autoprobe" is a really nice tool for setting 99% of the 
questions in "make menuconfig" to the correct answers.

However, it's also a great tool for squeezing obscure bugs out of the 
database like the fact if you DO switch on a PCMCIA network card that doesn't 
automatically switch on CONFIG_NET.  (Missing dependency, not yet in 2.1.3.  
One of the four questions it gets wrong about my laptop.  Out of a hundred 
and something, that's not bad...)

As a result "make autoconfigure" generally needs a couple of switches 
manually flipped before you get the config you want.  (But we're working on 
it.  More boxes to probe is always a good thing...  Send the results to Eric. 
 Or me, since Eric will be on the road this weekend.  Or that Gicacamo 
Catanazi dude, whose name I am highly unlikely to have spelled correctly 
because the deck is stacked against me here.)

> > Assuming every IBM T23 has the same hardware in it, which oddly enough is
> > a  bit of a gamble.  (OK, IBM is better at this than Dell, largely due to
> > inventory management reasons.)  And assuming the finite number of
> > database  maintainers has yet bought an IBM T23, and that the rest of the
> > world can  wait until then.
>
> Well, you'd wait until either your distro vendor had done one, or
> someone else had posted one and it had reached search-engine
> du-jour.

Sure.  If you want your distribution vendor to build your kernel for you, 
that's great.  We're just trying to give you another option.

> > Giacamo and Eric started work on the autoprobe as a way to reduce the
> > number  of questions the configurator showed people by eliminating
> > hardware that they  provably do not have, and defaulting the stuff they
> > DO have to on.  But it  turns out that on any relatively recent machine,
> > it's an easy enough problem  that you can autoprobe EVERYTHING and build
> > straight from that.  So the Linux  kernel could finally do "configure;
> > make; make install".
> >
> > I consider that a neat hack.
>
> Sure I agree, if it works; my speculation is that it doesn't, if one
> boots with a default vendor kernel, on many machines.

Right now, you're right.  It ALMOST works, but the bugs are still being 
squeezed out.  And about half the bugs are in the configuration rulebase 
rather than in the autoprober.  (It's amazing how many bad combinations CML1 
would allow you to do.  Did you know if you accidentally turn off the 
networking menu in the old menuconfig, there's no way to get it back without 
editing the config file by hand?  Sigh...)

> I would love
> to be proved wrong, so rather than debate further here, I have another
> T23 to set up so I'll boot it up from scratch, run the configurator,
> and see what happens.

Please let me know how it breaks.  (No, I'm not going to say "if", I'm not 
that optimistic yet.  2.2.0 perhaps...)

Rob

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

Alex Bligh - linux-kernel <linux-kernel@alex.org.uk> said:
> Eric: I think you'd be far better off trying to identify the
> machine (and hence get a working .config) rather than the
> hardware.

I've seen machines bought from the very same batch with _completely_
different innards. BTW, around in Chile you mostly get some store-build
machine, for years all in the same box with the same logo outside. Good
luck at finding CornerStoreComputer on your database... and if you do, may
it help find out which mobo was the cheapest around when it was built.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:
> Eli Carter <eli.carter@inet.com>:
> > Could you maybe describe the problem you are trying to solve a bit more
> > clearly than "the hardware-discovery problem for ISA devices"?  If you
> > are trying to discover the ISA devices, but rely upon them having
> > already been discovered, what are you accomplishing?

> Sure.  Let's say Aunt Tillie needs a kernel update.

So Aunt Tillie goes and clicks on "Update distribution", which gets her Red
Hat's up2date or Debian's apt-get or whatever. A reboot later she is happy.

All the nonsense about "faster kernel for K6" and "Nephew Melvin" is just
nonsense. Please do remember the horrors of some of the "latest stable"
kernels, and think thrice before you inflict same on poor Aunt Tillie.

If she wants a kernel for her machine "latest revision", give her a
.configure that builds a fully modular kernel distribution style.

Sure, it would be _way_ cool to have your autodetection stuff. Just:

- ISA is impossible to do right. And on the way out, so irrelevant.
- PCI is rather easy.
- PCMCIA, USB, ... are on the rise. How is your autoconfigurator to detect
  the USB Zip drive Nephew Melvin carries around and uses to backup Aunties
  account from time to time? Or the PCMCIA network card Aunt Tillie is
  keeping in the top drawer for a rainy day? Or the CD burner she plans to
  buy tomorrow?

What would she gain? A smaller kernel (mostly irrelevant, Aunt Tillie sure
hasn't got an 8MB RAM machine), less modules on disk (what, you are
worrying about a few MB on a multi-GB disk?)

As I said before, you are trying to solve a non-problem.

In any case, it's your time. Good luck!
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: ISA hardware discovery -- the elegant solution

[Oliver Xymoron]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
> Yes, but this was always true.

No it's not. You only need a kernel that can run your compiler.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: ISA hardware discovery -- the elegant solution

[Tom Gilbert]

* Oliver Xymoron (oxymoron@waste.org) wrote:
> On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> 
> > Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > > Doesn't this mean that you would need a fully functional kernel
> > > before you get to run the autoconfigurator?
> >
> > Yes, but this was always true.
> 
> No it's not. You only need a kernel that can run your compiler.

It's already been pointed out that the autconfigurator requires a great
many in-kernel features and userspace utilities.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@linuxbrit.co.uk    |
  ^^-^^   `-------------------------------------------------------'

Re: ISA hardware discovery -- the elegant solution

[Andrew Pimlott]

On Mon, Jan 14, 2002 at 11:11:41AM -0500, Eric S. Raymond wrote:
> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> Yes, but this was always true.

I think the point people are getting at is:  If you're re-detecting
things that have already been detected, doesn't it seem you're going
about the problem the wrong way?

Most distributors need to solve essentially the same problem you're
solving (detect hardware and install drivers), but without compiling
a kernel (if only to spare the user the wait).  To the extent that
they are successful (and they will presumably put considerable
effort into it), your compile-time probes are superfluous--you're
better off piggy-backing on the distribution's hardware detection.
Eg, derive your .config from the modules the distribution has
decided to load, or--even simpler--just compile a kernel with the
same .config as the distributor's kernel, and let the boot-time
scripts take care of the rest.  The drawback is that this differs
across distributions--but see below.

Even if you can usually do a better job, you have two major
handicaps:  One, you may have to repeat questions that the
distribution already asked, annoying the user.  Two, if you ever
screw up something the distribution had working, the user will curse
you.

Which leads me to conclude that your compile-time autodetection,
while cool, is a dead-end as far as helping Cousin Billie (though I
do support the ultimate goal of letting him compile a kernel).
There are some scenarios where you win, but not enough IMO.

To correct this, retarget the project to solve the distributors'
problem.  Ie, add a back-end that specifies modules and module
options, instead of a kernel .config.  Assuming you do a good enough
job, and meet the distributor's other requirements (eg, running in
an install environment), then they will use your system for their
install-time hardware detection.  You can store the results in a
standard (across distributions!) format, which administrators will
love (and which can be used by various to-be-written utilities).
Finally, you can later use the same database for compiling a
"stripped-down" custom kernel.

Andrew

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Dave Jones]

On Mon, Jan 14, 2002 at 03:38:44PM -0500, Eric S. Raymond wrote:

 > Right now, neither lsmod nor the boot time messages  necessarily give you that
 > information.

 One of the great things about Linux (or at least I think so) kernel
 is it's incredibly verbose startup.
 If you have a configured network, boot messages WILL tell you
 what driver is controlling that card.  If built as a module
 lsmod WILL tell you.

 > /var/log/dmesg contains no message from the NIC on my motherboard.

 Then that's a driver issue. What NIC ?

 > And going from the driver to the config symbol isn't trivial even
 > if you *have* the lsmod or dmesg information.

 Then we need better descriptions in the CML2 rules.

 > And anyway there are settings you can't even recover by looking at the
 > hardware, such as whether KHTTPD or BSD process accounting were turned
 > on.

 ls /proc/sys/net/khttpd
 ls /proc/sys/kernel/acct

 > Sure, Melvin could remember a whole bunch of state, or a whole bunch
 > of rules for reconstructing it. But isn't sweating that kind of detail
 > exactly what *computers* are for?

 If Melvin really does have a mind like a sieve,he'd  put .config
 somewhere sensible after building a kernel.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Giacomo Catenazzi]

T. A. wrote:

 
>     1. Don't see any reason for the kernel hardware autoconfigurator to be
> included in the kernel.


Linus and Alan last year (end Dec 2000), told that it would nice to have
some kind of autoconfiguration.
The problem was the bug report about non running kernel, because of
false configuration (CPU configuration).
How many people try new kernel with the wrong CPU configuration?
(and mornally user know the name of own CPU, with netcards this is
more difficult).

[ We don't reduce trafic on lkml, because the fewer bug reports
are hidden by this huge flamewar]

> 
>     2. Don't see any reason the kernel hardware autoconfigurator cannot be
> run as root.  Actually see one very good reason why it shouldn't be able to
> be run as a regular user.  Probing certain hardware is inherently dangerous.
> Machine can hang.  Hardware could be probed to death.  Heck a clever coder
> could even make use of the user level access required to allow user hardware
> autoconfiguration.  Wiping disks, destroying flash roms, finding system
> backdoors, etc, etc.


Root will help, but AFAIK, not needed. Forget DMI.
Out detection is 'hang' free. (so a soft detection, but with some
tests, I can say that with this soft detection we can detect nearly
all, without the difficult to write hard probes).

> 
>     3. ISA is pretty much dead outside of certain standard PC equipment.
> And of the remaining ISA out there, most in any machine than can still run a
> Linux kernel effectively is most likely PNP ISA.  Plus there are a few
> fairly common ISA cards that can also be found easily.  It seams that the
> vast majority of Aunt Tillies will be served with just PCI autoconfiguration
> and maybe PNP ISA configuration.

PCI, USB and ISAPNP detection works well.
ISA is a further step.
I will send Eric the new detections and database for new probes (for ISA
and others) drivers. So I hope also the ISA thread will end.

	giacomo

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Alan Cox]

On Tue, Jan 15, 2002 at 02:00:38PM +0100, Giacomo Catenazzi wrote:
> How many people try new kernel with the wrong CPU configuration?
> (and mornally user know the name of own CPU, with netcards this is
> more difficult).

All of us get the CPU wrong. By using modules however I don't have to guess
the PCI devices. My system already did that. I just need the configurator
to hit M a lot and to work out which root devices are for the initrd.

The code for that exists

> PCI, USB and ISAPNP detection works well.
> ISA is a further step.
> I will send Eric the new detections and database for new probes (for ISA
> and others) drivers. So I hope also the ISA thread will end.

I suspect ISA is a dead loss - but again build all the modules, the user
system already has the right ones to load configured.

Alan

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Giacomo Catenazzi]

Alan Cox wrote:

 
> All of us get the CPU wrong. By using modules however I don't have to guess
> the PCI devices. My system already did that. I just need the configurator
> to hit M a lot and to work out which root devices are for the initrd.
> 
> The code for that exists


It is easier to get autoconfigure in linux sources, than
modify the default (and broken) configuration from Linus.
(Sorry Linus :-) )

 	giacomo

Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)

[Horst von Brand]

Giacomo Catenazzi <cate@debian.org> said:
> It is easier to get autoconfigure in linux sources, than
> modify the default (and broken) configuration from Linus.
> (Sorry Linus :-) )

Say again? Then get HPA to give you a space on kernel.org for "Giacomo
Standard Configure Entries" which you update. _Much_ less pain going around
that way.
-- 
Horst von Brand			     http://counter.li.org # 22616