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

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

[Giacomo Catenazzi]

Marco Colombo wrote:

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


The main discussion was in kbuild-devel list.

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

Maybe this force kernel maintainer to merge the tested and trusted
distribution patches into the main kernel's branches.

Anyway, the target of Linux changes. If was a toy for hacker 10 year
ago, maybe in future will be the toy for Aunt Tillies. So:
Forget aunts and the other scenarios of Eric.
Let talk about what autoconfigure can do yet (aka the creation of
a /proc/drivers (better in /dev) with a list of all running
kernel drivers. aka how the modules will be in the next months)

	giacomo

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

[Marco Colombo]

On Tue, 15 Jan 2002, Giacomo Catenazzi wrote:

> 
> 
> Marco Colombo wrote:
> 
>  
> > 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").
> 
> 
> The main discussion was in kbuild-devel list.

Uh, my mailbox hurts just at the thought of even more posting on the suject.

> > 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.
> 
> Maybe this force kernel maintainer to merge the tested and trusted
> distribution patches into the main kernel's branches.

Which means, in Alan's (and Yoda's) words, even more perturbations of the
Source. I don't really like the idea of kernel maintainers forced into
anything...

Kernel tarballs are for hackers. Marcelo can't test any configuration
the autoconfigurator can produce. So basically it means an untested
kernel. Running untested kernel isn't a job for Joe User, and never
will be.

Some distro vendor may be interested in an easy, do-it-yourself kernel
compilation & customization tool. It brings almost nothing to kernel
developers.

Vendors and kernel developers have different goals. That horrible hack
that fixes some bug or misbehavior fits fine into a vendor kernel, and
has no place in Marcelo's tree; the same for that C++ written, cross OS
crap driver for hardware XYZ. Users want it, vendors provide it.
Different goals, different targets.

> Anyway, the target of Linux changes. If was a toy for hacker 10 year
> ago, maybe in future will be the toy for Aunt Tillies. So:
> Forget aunts and the other scenarios of Eric.
> Let talk about what autoconfigure can do yet (aka the creation of
> a /proc/drivers (better in /dev) with a list of all running
> kernel drivers. aka how the modules will be in the next months)

Creating .config (or whatever) is an userland issue, IMHO. /proc/driver
and the like is another issue, as it can be useful in general. 

Autoconfiguration is nice. But please move the topic elsewhere.

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

[Giacomo Catenazzi]

Marco Colombo wrote:

>>
>>The main discussion was in kbuild-devel list.
>>
> 
> Uh, my mailbox hurts just at the thought of even more posting on the suject.
> 


In kbuild: less people, less traffic, more discussion, less flames

> Kernel tarballs are for hackers. Marcelo can't test any configuration
> the autoconfigurator can produce. So basically it means an untested
> kernel. Running untested kernel isn't a job for Joe User, and never
> will be.


Also what are the stable series?

But you think your distribution test the kernel in all possible
use? With all possible hardware configuration?
Autoconfiguration will configure a compile and booting kernel.
(but on old machine). Neither vendor can assure you that the kernel
will work for a particolar permutation of hardware, and mainly
it is indipendent from configuration.


> Vendors and kernel developers have different goals. That horrible hack
> that fixes some bug or misbehavior fits fine into a vendor kernel, and
> has no place in Marcelo's tree; the same for that C++ written, cross OS
> crap driver for hardware XYZ. Users want it, vendors provide it.
> Different goals, different targets.


Change distribution. In Debian/unstable developers and distribution are
hardly linked!
Why do you need someone in the 'layer' between developers
and user?


> Autoconfiguration is nice. But please move the topic elsewhere.


Right. Let stop it


	giacomo

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

[Marco Colombo]

On Tue, 15 Jan 2002, Giacomo Catenazzi wrote:

> 
> 
> Marco Colombo wrote:
> 
> >>
> >>The main discussion was in kbuild-devel list.
> >>
> > 
> > Uh, my mailbox hurts just at the thought of even more posting on the suject.
> > 
> 
> 
> In kbuild: less people, less traffic, more discussion, less flames
> 
> > Kernel tarballs are for hackers. Marcelo can't test any configuration
> > the autoconfigurator can produce. So basically it means an untested
> > kernel. Running untested kernel isn't a job for Joe User, and never
> > will be.
> 
> 
> Also what are the stable series?

The *starting* point to build a working solution. And stable != supported.
The "working solution" being a distro kernel (well, the whole thing really),
which happens to be supported (and supportable), too...

> But you think your distribution test the kernel in all possible
> use? With all possible hardware configuration?

They *virtually* do. Why do they have (slightly) DIFFERENT hardware
compatibility lists? I don't care if they do really test a given HW
configuration as long as they support it.  You can't ask Marcelo to
actively support any HW conf. I'd expect him to "support" just the HW
he uses to build tarballs.

> Autoconfiguration will configure a compile and booting kernel.
> (but on old machine). Neither vendor can assure you that the kernel
> will work for a particolar permutation of hardware, and mainly
> it is indipendent from configuration.

Uh? After autoconfiguration you *hope* the kernel boots. In late 2.2
times, vanilla 2.2 used to be almost useless for just less-than-naive
users. Think of RAID @ redhat, or ReiserFS @ suse.
BTW, if I buy a RH Linux CD set (+support), and install it on a PC made
by parts all included in RH HW compatibility list, I expect:
1) it to work;
2) failing 1), Red Hat to solve any problem when I call them for support;
3) failing 2), Red Hat to return the money for the CDs.
That's what vendors are for.

> > Vendors and kernel developers have different goals. That horrible hack
> > that fixes some bug or misbehavior fits fine into a vendor kernel, and
> > has no place in Marcelo's tree; the same for that C++ written, cross OS
> > crap driver for hardware XYZ. Users want it, vendors provide it.
> > Different goals, different targets.
> 
> 
> Change distribution. In Debian/unstable developers and distribution are
> hardly linked!

Are you suggesting that Joe User should run Debian/*unstable*? What
it Debian/stable for, then?

> Why do you need someone in the 'layer' between developers
> and user?

The user isn't expected to do any QA. And Marcelo and other kernel
maitainers aren't, either. 

> > Autoconfiguration is nice. But please move the topic elsewhere.
> 
> Right. Let stop it

No problem for me. Feel free to answer me privately, as the above is 
hardly kernel-related (it applies to any other piece of software).

> 
> 	giacomo

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

[Zwane Mwaikambo]

This all sounds like distro work to me. Distributions could put the
userland apps in place to allow "automagic" tuning, recompilation etc
based on questions asked of the user. This Supe-Me-Up app could even
download the latest _Distro_Tested_ kernel and use that as the basis of
the new tuned one. Really i don't see what any of this has to do with
Linux Kernel. Eric i'm not putting down your excellent work, but i really
don't see where this is going, Normal users should _never_ have to use
kernel.org trees.

Regards,
	Zwane Mwaikambo

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

[Reid Hekman]

On Tue, 2002-01-15 at 04:40, Zwane Mwaikambo wrote:
> Normal users should _never_ have to use
> kernel.org trees.

Yikes! Sayings about never saying "never" aside... I should think the
goal is for everyone to be able to use kernel.org trees with reasonable
expectations. I'd like to see the day when distros can include a
pristine tree. I don't expect it, and the need for outside trees isn't
going away, but I'd like to see kernel.org be the canonical Linux for
more production systems, development starts, and non-i386 arch's.

With respect to Aunt Tillie, hardware discovery and kernel configuration
are separate issues. Can't the hardware probes be a separate package?
The autoconfigurator I think will be useful, but can't the configurator
just be dependent on outside packages like other functionality is
dependent on isdn4k-utils or iptables? 

Regards,
Reid "thinking this is getting offtopic" Hekman 
--
Current: reid.hekman@ndsu.nodak.edu
Permanent: hekman@acm.org 

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

[Bill Davidsen]

On Tue, 15 Jan 2002, Reid Hekman wrote:

> On Tue, 2002-01-15 at 04:40, Zwane Mwaikambo wrote:
> > Normal users should _never_ have to use
> > kernel.org trees.
> 
> Yikes! Sayings about never saying "never" aside... I should think the
> goal is for everyone to be able to use kernel.org trees with reasonable
> expectations. I'd like to see the day when distros can include a
> pristine tree. I don't expect it, and the need for outside trees isn't
> going away, but I'd like to see kernel.org be the canonical Linux for
> more production systems, development starts, and non-i386 arch's.

Slackware has run stock kernels in some releases. Whenever possible I
prefer to run a stock kernel, since I can then avoid finding out that an
application isn't portable after all :-( Done that, didn't polish my
reputation or improve my disposition.

I would say that very few normal users are running applications so close
to the cutting edge that they need kernel patches to make them work.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

[Mark H. Wood]

On 15 Jan 2002, Reid Hekman wrote:

> On Tue, 2002-01-15 at 04:40, Zwane Mwaikambo wrote:
> > Normal users should _never_ have to use
> > kernel.org trees.
>
> Yikes! Sayings about never saying "never" aside... I should think the
> goal is for everyone to be able to use kernel.org trees with reasonable
> expectations.

Yikes indeed.  What's a distribution?  Oh, wait, I recall sometime back in
the last century I downloaded some diskette images called "Slackware 1.2".
I guess that's my distribution.  Since then I've replaced every single bit
outside of a few /etc/rc.d scripts, installed a dozen locally-built kernel
upgrades, etc.

Now that I think of it, what's a normal user?

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Our lives are forever changed.  But *that* is exactly as it always was.