Re: 2.1 kernel bloat revisited

Jared Mauch (
Tue, 1 Apr 1997 22:36:10 -0500 (EST)

One solution would to be to go the solaris way, and have kernel
modules for everything. The redhat distribution has been doing
that, creating an inital ramdisk to load scsi controler drivers, and
other stuff.

If the symbols don't change, you can do this without a problem,
but if they do change enough, you won't be able to load or even boot
your system with the new kernel. I ran into this when upgrading the
kernel on one of my main linux machines with the redhat stuff rpm -U'ing
the kernel and kernel modules rpms, but it didn't redo the ramdisk properly
which caused a big problem when I rebooted and it attempted to load the
scsi driver.

As for kernel source bloat, since you have many architectures, and
it seems like there's a new one every 6 months or so, and as you add the
assembler of the inital parts of this code, and other such, you're going to
see a big increase in the source size. That's partially what the diffs are
for, you can grab those changes, patch it in, do a little rebuild, and you're
done. If you were to take solaris x86 and sparc sources and add them all up,
drivers for all cards that folks have written, such as add on fddi sbus
cards, and various other hardware that linux all has native in the source
tree, I'm sure you'll have at least the same amount of source, and probally
see even more bloat.

- Jared

Ben Clifford graced my mailbox with this long sought knowledge:
> On Sat, 29 Mar 1997 wrote:
> > (Not to take away from Andi's point to much, the kernel is growing
> > and we should probably take a look at the reasons.)
> Has anyone ever considered making some form of linker that would allow
> compiled modules to be statically linked into the kernel, rather than having
> them as an integral part of the kernel source.
> Allowing them to be statically linked would allow them to be used during
> the boot process, whilst they could still be compiled separately (ie from
> separate source trees).
> Comments?

Jared Mauch - CICNet - - - visit my personal
page at
PGP DATA: bits/keyID 768/8FB07FA5 1996/01/23 <>
Key fingerprint =  61 90 2E DD 7A 7E 80 F2  55 C7 48 23 10 CE 2C A7