Monday, February 11, 2008

Linux the Kernel

When the Kernel went from 2.4.x to 2.6.x we saw a huge jump in the size of the sources. Of course a compiled kernel can be any size the compiler thereof wants it to be beyond the basics that get a usable kernel.

But, not only did the sources size change. Under the hood there were lot of other major tweaks like various sub systems.

As the Linux kernel has grown in size so the complexity of it has grown exponentially. And with complexity comes more and more errors. We can see this, given arbitrary hardware, if we compare kernel 2.4.x against 2.6.x compile time errors or kernel OOPS whilst running.

Given that we _need_ the kernel to grow because 1) We have more users of it now, 2) There is more hardware available now 3) 2*1 = more sources. All well and good. However, as good for Linux based operating systems as that obviously is it comes at a price due to ever increasing code complexity which creates errors/warnings at compile time and kernel OOPSES at run time.

As modular as 2.6.x kernels are, or rather can be, I think we, or rather the kernel coders, can take this modularisation further by splitting off basic kernel functions and hardware functions. I will admit my knowledge in this area is severely limited but that said I am sure this can be done.

What exactly am I talking about? The kernel, which _is_ linux, is the heart of all distributions. Without it distributions would neither function as we know them now nor indeed exist (witness GNU herd) but a radical rethink on how we perceive it is not only due but overdue.

As it stands now to get the latest all singing all dancing kernel sources one must:

1) download a huge archive.
2) build it. Assuming one knows their hardware and general requirements one can then build for oneself a new all dancing all singing kernel.

As far as it goes this is all well and good. But, the first step in that process is were changes could be made. Instead of downloading a huge archive one could:

1) download an archive of just the basics that enable the kernel, once built, to function.
2) Then one could download the various hardware sources, that would be split up into individual archives

As an example. On my main desktop workstation I would:

1) Download an archive of the basic kernel
2) download the driver for my SCSI hardware
3) Download the driver for my VIA hardware
4) Download the driver for my SATA hardware
5) Download the NetFilter sources

And so on.

All archives would extract to linux-2.6.x as they do now. Once everything has been downloaded then the configuration and build process can be done.

I know this all sounds more complex but the idea is to make the main kernel archive smaller and thereby hopefully make gcc spit out less errors/warnings and kernel OOPES less likely.

No comments: