Matthew D. Pitts
mpitts@suite224.net
----------
> From: Hendrik Visage <hvisage@iafrica.com>
> To: torvalds@transmeta.com; linux-kernel@vger.rutgers.edu
> 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 http://docs.sun.com 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
> hvisage@iafrica.com
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html