Re: The Kernel (fwd)

[George Bonser <grep@oriole.sbay.org>]

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

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

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

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

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

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.

  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?

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.

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.

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 

  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?


George Bonser 
If NT is the answer, you didn't understand the question. (NOTE: Stolen sig)
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.