Re: Layout/Setup of Kernel

Matthew D. Pitts (
Fri, 31 Jul 1998 19:04:16 -0400

As has probably been pointed out before, it isn't feasable to do what you
suggest. Linus, as well as others, feel that updating the entire kernel is
more easily done if there is one central coordinator. Also, you can
purchase a CD-ROM from any of the many places that archive the source and
use it, along with the official patches, to upgrade to the most recent
kernel. As far as the unused system types, if they're taking up too much
space, delete them.

Matthew D. Pitts

> From: Hendrik Visage <>
> To:;
> Subject: Layout/Setup of Kernel
> Date: Friday, July 31, 1998 12:42 PM
> Hi There,
> First I have to congratulate the people who have brought Linux to the
> current state of what it is.
> Second, I have to complain about the size of the current 2.1.x
> kernel.... (especially for modem download)
> Reasons:
> 1) More than 10Megs of compressed source code.
> 2) Most of the downloaded stuff aren't needed for the average
> installation (ie. no SCSI or IDE and also only using less than halve the
> SCSI or IDE options, and only using one or two network adapters, not
> every one have a UFS/SYSV filesystem etc. )
> Isn't it time to start a break down of the kernel?
> What I'd like to see is a situation where there actual "kernel" is
> something which contains the stuff necesary to support the device
> drivers. The device drivers are then maintained by there respective
> maintainers and could then be released on a seperate schedule as and
> when changes are needed for then.
> I'd advise people to take a look at under the
> section 9 manual pages to see the Solaris type DDI/DDK.
> If we start using something like this, a device driver developed for
> eg. Solaris SPARC/x86 could then be much easier to port (or even run as
> binary on the relevant architecture) to Linux and vice versa. Something
> by which some OEMs might be quicker to respond to Linux versions...
> In this environment, the "kernel" would then be just enough with enough
> knowledge to load drivers into memory and to provide then with the
> needed support etc. This would most probably include the scheduler, etc.
> Thus, we shouldn't have a option to compile something as a module or
> not, it should be the ONLY option available.
> I do feel that the options regarding the "kernel" should be limited to
> stuff like:
> a) Sparc/x86/68k/ARM/SGI etc.
> aa) Optimization for specific versions
> b) SMP/Uniproc
> c) Debugging
> d) Profiling
> For booting you'll then have to create a boot file for each type of FS,
> like (boote2fs, bootminix, bootnfs etc.) which would create a temporary
> FS for loading the kernel which the kernel would ask for the necessary
> config files and driver files (like the REAL fs driver) to be loaded.
> Having this "single" boot program could also help with other problems
> I've encountered like running lilo (etc.) every time I've created a new
> kernel, whereas this program would need an initial lilo, (stating where
> it lives on the disk) and subsequent new/previous kernels would be
> loaded from this program (given the right boot options like asking for
> the kernel file and directories etc.)
> I do feel that Linux could learn from Solaris (Yes I do like Solaris,
> but prefer Linux at home because of resources) to be much more modular
> and by providing a framework for others to drivers on, rather also
> providing lot's and lot's of drivers with the single xxxxMeg file.
> Greezt
> Hendrik Visage
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> the body of a message to
> Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at