[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bootint big kernels



Dale Scheetz <dwarf@polaris.net> writes:

> On Thu, 11 Jun 1998, Enrique Zanardi wrote:

> > On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> > > The problem is that the Debian installation kernel tries to be all things
> > > to all people. As there are machines that boot from SCSI drives, it was
> > > necessary to have all the scsi controlers "built in" to the kernel, hense
> > > its large size.

> > > We should recommend that everyone, once they have a standard system and
> > > can build a kernel, should build a custom kernel for their machine as
> > > early as possible.

> > > Another solution is the one that slackware provides. They build a "bunch"
> > > of kernels, each one for a specific hardware configuration (broad enought
> > > to cover a range of hardware, and chosen to keep incopatibly drivers out
> > > of the picture {like the wd9000 driver that plonks ethernet cards})

> > I'm working on a better solution that involves using initrd to
> > load the required controllers (built as loadable modules). I've tested
> > using initrd for lowmem installations and it works flawlessly (just have
> > a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
> > weekend).

> I have wondered why we didn't try this once the kernel supported initrd.
> To be honest I haven't figured out yet how to do the device selection,
> other than going through a list of drivers, trying to insmod each one
> until you are successful.

Red Hat does this, we might want to look at their code.  (Even after
the install you end up with both a kernel and an initrd image
containing the exact drivers you need in /boot - they mainly use this
for SCSI drivers - they might also do PCMCIA SCSI there, but I'm not
sure.)

They have a script to rebuild the initrd for newly compiled kernels,
but I usually just compile the drivers in.

> I would love to see your solution for this, even in whatever the current
> state is.

IIRC, they do some of the device selection via /proc/pci. I believe
they do this for ethernet and Video Cards too (to select the right
server) - if it's unsuccessful, you are presented with a list.  

I know UltraPenguin probes the PROM tree for the video cards (again to
select a server), because I sent in a patch for the cgfourteen.

IMHO, the Debian install should detect as much as possible from
/proc/pci (and proc/openprom on the Sparc), and do automatic
configuration from this wherever possible.

> > Using initrd, our default kernel may be reduced to half its current size,
> > as all those different controllers may be built as modules and only the
> > required ones will be loaded at boot time. That will save our users a few
> > hundred KBs of RAM, and will make building a custom kernel a not so
> > needed step.

> Yes, this would be a great improvement over the current situation, making
> the installation kernel appropriate for a system kernel with no
> rebuilding.

It would also make new kernel packages available to a wider audience.
(At least some of those who compile their own may be less likely to.)


Steve
dunham@cps.msu.edu


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: