Re: The Kernel (fwd)

[jfm2@club-internet.fr]

> On 23 Jan 1998 jfm2@club-internet.fr wrote:
> 
> > 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.
> 
> Yeah, it pares the size of the kernel but it puts it back into the ramdisk
> so the total memory usage increases because, you you pointed out, of the
> ramdisk filesystem overhead.  I have already determined that Debian is in

Please look at the kernel doc.  When the driver for / is loaded and
the real / is mounted then the ram disk is destroyed.  After that the
only penalty you pay is the (small) ram disk driver and the initrd
part.  And this is far less than an array of SCSI drivers.

> fact using initrd.  I will have a look tonight to see what they put in the
> modules directory of that root image that gets loaded to the ramdisk as
> soon as slowpoke gets done with a project. (slowpoke is my sandbox
> machine)
> 

I have looked at the patches in the Debian kernel and in them I found
the kernel config file so I was able to determine what is being
compiled in the kernel shipped with Debian.  They have compiled initrd
but nearly all the SCSI drivers are compiled in.  That makes little
sense to me.  Initrd is only of interest when you are booting with a
modular drive.  I also looked at networking features and most of them
are left out.

I am basing in the 1.3.1 Debian found in Infomagic August.

> > 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.
> 
> Right, I think the trouble is that they can not fit ALL the modules onto
> the one floppy.  There are a ton of modules on the debian floppy ...
> serial, parallel, net cards, tons.  Bruce is pretty good about trying to
> get the install down to a single floppy (except for the base install) ...
> heck, if you have a bootable CDROM, you do not need any floppies for
> Debian.  If your CDROM is not bootable, you will need at least one and
> possibly two floppies. If you have no CDROM, you will need six or possibly
> five and install the rest over FTP
> 

Then they are or were doing it all wrong.  The user is installing. The
drivers who need to be on the boot floppy are the ones needed for
booting and installing: block device drivers and, in case you allow
network installations, network device drivers.  In addition if you
can't include all in one floppy then you minimize the inconvenience
for the user community as a whole by including drivers for commonly
used devices in the first floppy and put the drivers for rarely needed
devices in additional floppies.

> > 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).
> 
> Caldera does have a modules diskette like Debian does.
> 

Only necessary for people needing PCMCIA drivers for installing.

> Also, the latest Debian kernel (2.0.32 in 2.0) DOES have IP-Masquerading
> enabled ... or at least IP firewalling.  As a matter of fact, they now use
> an ipfwadm command to set up some anti-ip spoofing filters on bootup
> (packets to/from 127.0.0.1 should never travel on eth0 ... etc).
> 
> I think that you might want to have a good look at what is currently
> shipping from Debian.  It looks like they are moving in the direction that
> you want it to.
> 

I will look.  But if they are moving that means than they are
unsatisfied with the kernels thay used to ship.


>  
> > 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.
> 
> Have you seen the size of the patches that Debian applies to the standard
> kernel?
> 

Yes nad I looked into them.  Most of the patches volume come from the
fact than Debain has added the experimental MCA support to their
kernels.  Because non-MCA boxes will not be affected by that code I
will not criticize Debian on that subject.

> I will have a look tomarrow sometime and document exactly what comes with
> the kernel.  There is a basic security issue that I worry about if you
> want to install an initrd kernel ... actually, I am not sure that initrd
> looks for file ownership, only file name.
> 

Initrd uses a RAM disk loaded by LILO from a file.  AT the time this
RAM disk is used there are only root processes running.  When the real
/ is mounted then the processes loaded from the ramdisk are supposed
to die.  If root is stupid enough for allowing write access to the
initrd file or for placing in it programs not related to the mounting
of / then it will be his responsibility.

> > 
> > > 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.
> 
> Good point.  Debian tends to be where people go when they get tired of the
> endless hours of Slackware admin or Red Hat's package limitations. Most
> Debian users are refugees from other systems ONLY because of dselect.  The
> only time I have had to recompile is for IP-Masquerading when I used it.
> 
> 

Ok you didn't resist the temptation for sending some shots to other
distributions and hyping about Debian so I will do the same.

It has been evident at one time, when Debianists pressured for
choosing the distrib by vote instead of examination, than over 50% of
the people in this list were using Debian.  That is several times over
the Debian share in the Linux population.  If Debian is so good why
such an overreprsentation of Debian users in a list formed by people
unhappy with present distributions?

And now than both of us have behaved like kids, let's stop this before
it becomes a distribution war as silly as editor wars.  I propose the
following code of conduct.  No shots at any distribution.  No hype.
No "It must be right because that is the way in my distribution", back
assertions with facts.  No unsubstantiated comparisons.  Critics and
appraisals admitted only if really substantiated.  This is not an
advocacy mail list and I hate civil wars.  If one of us contravenes to
this he will have to post a (long) text so flattering about one of
Microsoft "operating systems" than not even the MS Journal would
publish it.

> > 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.
> 
> Sounds good ... that is something that can be worked on.  Once a method
> for making boot disks for Debian 2.0 is released you should start working
> on it.  You can grab Debian's kernel source package and the debian patch
> and start looking at it now. We have a lot of other work to do before we
> start to modify the kernel but it IS something that is going to need
> doing.
> 
> > 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.
> 
> I agree with that. Lets keep in mind though that a prime application for
> Linux is as a dial-on-deman IP-Masquerading router for homes with more
> than one computer and only one phone line.
> 

The other kernel (the one they used for installing) would provide
those features.  People having a small LAN at home would know how to
recompile a kernel if they want further optimization..  They could be
beginners but they certainly have computing experience possibly even
Unix experience.

> > 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.
> 
> 
> I fail to see why.  It is a modular initrd kernel. It might have some

A big kernel and at the same time an underpowered kernel in the
networking aspect translate in many users _having_ to recompile it.
This is not what we want in an end user distribution.

> things built in that other modularize for performace reasons ... sometimes
> the time it takes for a module to get loaded causes bad things to happen.

Some slow CDROMs can take too much time to reset, so if you are
loading the driver with kerneld the mounting tending to fail because
the kernel did not wait long enough to give them time to finish the
reset.

Notice than this a factor only if you are using kerneld, ie the mount
command will be the causal factor for the loading of the module.
Notice than the drivers are being fixed.  And than this is not a
problem if you load the drivers for your hardware at boot time instead
of using kerneld.

> There might have been a tradeoff in general system performace from having
> something built into the kernel vs. having it as a module.
> 

The tradeoff is in average 2K by module because modules are page
aligned.  Add a (small) bit of code for the module registering itself.
So some people think than it is to be smart to recompile their kernels
just for getting a monolitical kernel including drivers for all the
hardware they use permanently.  In the very improbable case they save
20 modules the memory savings are just a bit over 40K.  A triffle.


> For example, when someone installs a new kernel image on debian, it erases
> the module deps so that they are rebuilt on bootup. If you have a modular
> disk driver and you erase the module deps, you can not load that module.
> You might not be able to shut down cleanly. 
> 

The disk driver must be in the initrd file.  And a wise user keeps a
second kernel in case he forgets something vital like ELF support.

> There might be very good reasons why things like this are done.  They are
> likely tradeoffs that cause a little inconveniance in one place but offer
> what was decided to be a greater benefit in another.
> 

There were perhaps very good reasons for Debian shipping in its 1.3.1
version a kernel who was one of the biggest in contemporary
distributions and at the same time one stripped of most networking
features (see above for a justification) but I am too dumb to
understand them.

My personal opinion is than the real reason is than packagers
envisionned a Debian user being a hacker who will compile his kernel
anyway and for whom this would not be a problem.

Other distributions wanted than if Linux was used as a network server,
router or firewall it had to work out of the box because their
targets were corporate users and than the person in charge would not
necessarily be a long time Linux user.

And because the SEUL user will probably lack the skills needed for
recompiling, the primary SEUL goal in this area is giving the best and
leaner out of the box kernel than the current Linux version allows to
provide.  If the Debian 2.0 kernel is close to this ideal then it will
be usable but if it is close to 1.3 then it is not for us.

-- 
			Jean Francois Martinez

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