Re: The Kernel (fwd)

[jfm2@club-internet.fr]

> 
> > 
> > Let's see.
> > 
> 
> > There are dozens of SCSI controllers, to make a monolithic kernel to
> > cope with all of them, you will be forced to build a _big_ kernel, a
> > kernel who will probe unexistent devices and will take forever to
> > boot.  Users will hate it.  And we are targeting users unable to
> > recompile it (specially recompiling it properly).
> 
> Look, we are not making an optimum kernel for blazing speed designed to
> be operated by a bleeding edge kernel hacker. There ARE going to be
> compromizes that are going to have to be made in order to make the system
> simple to install.  
> 

In RH all the SCSI drivers are modular so I stripped the modules and
looked the size of the stuff: more than 500K.  That means than if you
compile them in, every IDE user will have 500k of fat.  And than every
SCSI user will have 400K in excess due to drivers for the other SCSI
controllers.  Having 500 K of unsawappabel RAM in excess of what is
needed (a bit less because ramdisk and initrd has some overhead) is
something than makes kernel compiling mandatory for people with 8
megs.  I am going for delivering the best kernel possible to SEUL
users, not the one saving me work or the one decided by others.

> Your logic does not stand up to reality.  I have the Debian kernel as
> installed on one of my systems ... it is SCSI and it does NOT take
> "forever" to boot.  It installed with a single boot floppy (did not need
> the root floppy) and the 5 base diskettes. No figuring out which install

Try a dummy install and when it asks you what CDROM you have then lie
and tell than you have a proprietary CDROM.  It will ask you for
another floppy.  There are distributions who need only one floppy
whatever your CDROM is, or whatever your network card (only PCMCIA
drivers are on an additional floppy) if you are installing with NFS.

> disk to get or which kernel image to load.  It just plain works.  Besides,
> how much are we talking about saving out of the kernel? 1 or 2 K in size?
> 

By the way the same applies to Redhat and Caldera.  Both allow to use
every networking feature (in fact every feature known) out of the box
without recompiling (I notice you did have to recompile for
IP_Masquerading so Debian lacks some exotic networking features out of
the box).

The following sizes are the file sizes of the kernels shipped with
some distributions.  THis is not the same than the memory footprint of
the kernel but this gives an idea:

Caldera kernel 2.0.29:  404158
RedHat5 kernel 2.0.31:  444595
Debian  kernel 2.0.30:  623026

Conclusion: Redhat and Caldera users get smaller kernels than Debian
users.  They also get more networking features.  So more intensive use
of modules makes kernel recompiling less necessary in Caldera or RedHat.

> I hear no great clamor of complaints on Debian-user about systems that
> will not boot it.
> 

How many beginners are using Debian?  The Debian population is
essentially formed by people knowing how to recompile.

> You are going to be very hard pressed to convince me that we are going to
> need more than a single boot floppy.
> 
> > 

You didn't understand me.  There will be only one boot disk.  We need
one kernel able to cope with all hardware and every netowrking
feature.  This will be used for install but will be used at the same
time for installation kernel and the kernel used by people needing
sophisticated networking features like ISPs who will get sqomething
working out of the box.

But those features are not needed by most people, specially SEUL users
so I intend to gave them a second kernel close to optimal based on the
equipment detected (automatic detection) and stripped of features
needed only on routers or disk servers.

They will be able to boot on either one and get a fast and small
kernel as long as they don't need exotic networking features.  The
people in charge of routers are competent enough to recompile a kernel
for obtaining better performance.


> > Now let's think about this.
> > 
> > 
> > The SEUL user should not _have_ to recompile his kernel.  That means
> > than we have to provide it with one reasonably good.
> > 
> 
> Ok, so far so good.
> > 
> > There are three methods for coping with / on an SCSI:
> > 
> > Having a different kernel for each controller.  The Slaackware method.
> > That means complicating the install but could have been fairly smart
> > if Slackware had really adapted to 2.0.  Unfortunately Slackware is
> > in reality a 1.2 distribution with a 2.0 kernel.  The use of modules
> > is minimal and beacuse there are many combinations of network cards
> > and CDROMS thhe Slackware kernels are big enough than the user has to
> > recompile them.
> 
> Not an option as far as I am concerned.
> 
> > 
> > Having only one kernel, no initrd.  The Debian method. That means
> > having every SCSI driver compiled in.  So tghe user is forced to
> > recompile to get rid of unneded fat.  No problem in a true geek
> > distribution.
> >
> 
> Not even a problem at all.  Why? Because the user is not forced to modify
> the kernel if he CHANGES his scsi controller or gets rid of it all
> together.
>  

Initrd users with modular scsi drivers are in the same situation.

> > Having only one kernel and using initrd (RedHat).  This way you can
> > load the SCSI driver from initrd and still get a pretty lean and fast
> > kernel (not optimal but good enough than the user will not be forced
> > to recompile).
> 
> What is this obsession that you have with the kernel?  Why this obsession
> with not having a single extra SCSI disk controller driver present?
> Doesn't the same problem hold true with IDE controllers? Do we REALLY need
> support for every type of IDE controller in there?  We could save 500
> bytes by removing one driver or maybe a whole K by removing another.

I am obsessed with making kernel compiling an exercise for snobs
because people get one good enough.  I do not want a beginner _having_
to do one.  And in fact I think than kernel compiling mythology is
harmful to the spreading of Linux: it gives it a geek reputation
frightening for normal people.


> 

> The ENTIRE libc6 kernel for Debian-2.0 is only 675K
> 
> About 1/2 of 1Meg.  You are not going to shrink it much and if you did
> manage to pull some more out of it, it is not going to be enough to add
> something else of significance.
> 

We were speaking of kernels not of libc.

>   In afct we can improve that: because IDE driver is not
> > modular in 2.0 (it will be in 2.2) SCSI users will have it they want
> > or not, and for IDE users the initrd driver will be useless.  So
> > perhaps we can optimize by having an IDE kernel and an SCSI kernel,
> > but only the later would use initrd.
> 
> If it is not broken, why fix it?  Is there any compelling need to make the
> boot process more complicated?  I mean any compelling need besides your
> simply not being able to stand it knowing there might be an extra SCSI
> driver in there?
> 

About having a dozen additional drivers compiled in.  More than that
in 2.2.

> Let me put it rather bluntly ... as far as I know, until I hear different,
> our first unstable release IS GOING TO BE Debian 2.0 based. AFTER we get
> the Core spec and the Base spec written, IF there are compelling reasons
> to change it, we can. It is, quite frankly low on the list of
> priorities since we have not had any trouble with people booting the
> system.
> 

If you are blunt I will be.  The Debian kernel in Debian 1.3 is one of
the worse 2.0 kernels I have seen for targetting an end user.  And I
know many.  So either the Debian 2.0 kernel is _very_ different of the
one I have seen in 1.3 or I will do my best for SEUl having his own
kernel.  Differences are far too great between what I think it is
needed and what I have sen in 1.3 and I consider the matter far too
important for me accepting the same kind of stuff than what I have
seen in 1.3.

The reasons Omega gave for using Debian (not ideal in short term but
better due to cooperation) are only valid if Debian people begin to
think a bit in end users.

> Lets get a system build first useing debian as a base and THEN modify it.
> I would say modifying the boot process and kernel type might come sometime
> AFTER we have a smooth install and package
> selection/installation/configuration process.  In other words, you are
> suggesting 1) Fixing a non-problem at this point 2) Improving something
> that does not exist yet.
> 

I am targetting what I want. 

> If you want to go over to debian and get them to change their kernel,
> fine. ... heck, what you describe might already be in the works ... have
> you checked?
> 
> I see no current problems with the kernel so I see no great reason to
> devote any more time to the issue until it becomes a problem or until
> other more pressing issues are taken care of.
> 
>  
> > About the kernel being or not being modular the
> answer is simple.
> > When thinking about SEUL I base on what my sister (an accountant, ie
> > an end user) would be able to do.  She would not be able to compile a
> > kernel.  That means than the kernel has to be modular.
> 
> I have not had to recompile a Debian Kernel for a while.  And when I did
> it was to add IP-Masquerading. I have not had to add device support.
> 
> > Modules dpo not allow optimizations like 386 or Pentium built kernels
> > so only one kernel would be suboptimal.
> 
> If you are using GCC, there really is not much optimization for 586
> anyway.  You get most of it in the 386-->486 
> 

In 2.0 kernels the only differnce between a Pentium and Pentium Pro
kernel is the way memory is copied.  And GCC is used with the same
flags so it generates the same code.  A 386 checks page protection
only at ring three so the kernel have to check in software.

But there are some improvements to quntify and benchmark: how much
memory do you save by removing exotic networking, FPU emulation
(unneeded with modern computers) and so on.  I am not going to put
multiple kernels if the savings are only 50K.  But my experience is
than they are far more than that.


>   If we really want to give an
> > optimized kernel we have to give more than one.  But if we use
> > monolitic kernels we cannot at the same time keep this number small
> > while having reasonably good kernels.  And I do not want than like in
> > 1.2 times the user getting dozens of fat and slow booting kernels.  
> 
> 
> Again ... you sound like someone without a lot of experiance booting
> Debian kernels/.  I do nto find mine particularly slow compared to a
> Calera kernel.  I think you are making a lot of assumptions.  Why not stip
> Red Hat off that system of yours install Debian and give us a hand?
> 

You see.  I _did_ that a few months ago in my second disk.  Of course
time made some memories flaky and I becauuse I also tried Debain 1.2
perhaps some things I attribute to 1.3 were 1.2 so I booted it this
afternoon.  You are right Debian kernel is not a slow booter.  But it
is over two megs.  And I think we can do a lot better.

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================