Re: The Kernel (fwd)

[jfm2@club-internet.fr]

> Sender: root@cyberdynamics.com
> Date: Thu, 22 Jan 1998 15:25:53 -0500
> From: Rick Jones <rickya@siservices.net>
> CC: jfm2@club-internet.fr, k.wetzel@welfen-netz.com, starsend@interlog.com,
>         seul-dev-distrib@seul.org
> Content-Type: text/plain; charset=us-ascii
> X-UIDL: c3bc0c1d17bb4707fceae02971ecb568
> 
> George Bonser wrote:
> > 
> > On 22 Jan 1998 jfm2@club-internet.fr wrote:
> > 
> > > Wonderful!  How do you do for reading your SCSI driver if / is in an
> > > SCSI disk?
> 
> If you're talking about installation, / is in a RAM disk soeven if you
> do have to load an additional module from a second disk the OS is in
> memory and not dependant on a floppy.
> 



> If you are talking about day to day booting, why would anybody want to
> use a floppy to boot from anyway?  During installation the install
> program, for Debian, has a preset list of things the average Joe should
> install / has to install, one of them is a kernel binary of which there
> are EIDE and SCSI choices among others.  No need to boot a SCSI kernel
> if you have an EIDE.
> 
> Making a modular kernel is an issue still up in the air.
> 

Let's see.

The user has / on an SCSI disk.  He wants to use Linux.  LILO loads
LINUX usin BIOS: Linux then tries to mount /.  No problem if the
driver is in memory (either because it is compiled in or due to
initrd) but if the driver is a module then the kernel will be unable
to mount / (no SCSI driver in fact the driver is sitting in the SCSI
disk) and Linux will crash.

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

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.


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.

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.

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


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.

Modules dpo not allow optimizations like 386 or Pentium built kernels
so only one kernel would be suboptimal.  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.  


In fact with modules a small number of kernels would allow to
approach the performance of a custom built kernel with a modular
kernel chosen by the user (so avoiding recompiling).

The user would get unconditionally the universal 386 compiled kernel
in order to ever have a backup solution.  And then he would get the
choice for installing an optimized kernel in a short list (under a
dozen, better under half a dozen).  I think my sister would be able to
select Pentium with all the Intel hype in the front panel of the
computer but in case she has a doubt she can cycle in a list of six
kernels and try them until one of them works.  ANd don't forget than
at install time we can read /proc nad know more about her computer
(processor, coprcessor and so on) than what she knows.


I have still not made my mind about if it is really wothwile to have
more than one kernel (I will try to benchmark the issue and evaluate
the problms of keeping several kernels cohernt) but one thing is
certain Simple End User Linux the kernel has to be modular.

-- 
			Jean Francois Martinez

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