Messages in this thread | | | From | Jared Mauch <> | Subject | Re: 2.1 kernel bloat revisited | Date | 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 Eric.Schenk@dna.lth.se 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 - jared@cic.net - http://www.cic.net/ - visit my personal page at http://puck.nether.net/~jared/ PGP DATA: bits/keyID 768/8FB07FA5 1996/01/23 <jared@puck.nether.net> Key fingerprint = 61 90 2E DD 7A 7E 80 F2 55 C7 48 23 10 CE 2C A7
| |