[nycbug-talk] kernels

[mlists at bizintegrators.com]

On Thu, Jun 03, 2004 at 09:06:54AM -0400, Sunny Dubey wrote:
> On Thursday 03 June 2004 02:07 am, mlists at bizintegrators.com wrote:
> 
> > They seem to have missed one important post on the list.
> > Here it is, from Kamo Hiroyasu <wd at ics.nara-wu.ac.jp>
> > "
> > Chuck, you are misusing the term `monolithic'.  A monolithic kernel
> > with loadable modules is still a monolithic kernel because the loaded
> > codes will run on the kernel space.  It is far from a micro kernel.
> > That implies: you cannot gain any advantage of mocro kernels from
> > loadable modules.
> >
> > Please consult any textbook on operating systems for detail.
> >
> >                 Kamo Hiroyasu
> >                 [Kamo is the family name and Hiroyasu the given name.]
> >
> > "
> >
> > Therefore, Linux kernel is also monolithic.
> >
> 
> I think that some people are missing the fact that it is possible to get 
> around the GPL requirements of the linux kernel.  Essentially what you can 
> do is the following:
> 
> linux-kernel <---> GPL wrapper <---> binary only module
> 
> From what I've seen, the above is usually the case 99% of the time.  You 
> download whatever package and compile the module wrapper against the 
> current kernel headers.
> 
> Additionally as someone who understands the Mandrake Linux installer 
> backwards and forwards [1], I can say that modules become excessively 
> helpful especially when you need to distribute generic kernels, or need a 
> kernel going for the installation process.
> 
> Essentially you can break hardware support down into two categories, the 
> first being "mandatory" (stuff that is needed for installation, like 
> IDE/SCSI, network cards), and the second "optional" (sound cards, printers, 
> etc).  It is the size of the mandatory support that matters greatly because 
> at any given time you have limited amount of space to deal with, yet at the 
> same time the list of "mandatory" stuff keeps growing and growing.
> 
> With the BSDs, the GENERIC kernel essentially supports the mandatory stuff 
> with various optional parts left out.  However with linux distros, we like 
> to ship a kernel with very basic mandatory stuff, and the rest of the 
> mandatory/optional stuff built as modules.  This comes to our advantage for 
> various reasons.  The first being that people aren't loading what they 
> don't need to be.  (Not that there is anything wrong with loading what you 
> don't need, but the less running in kernel space, the better).  Secondly 
> (IMO) you are given a chance to load the module with modified arguments as 
> opposed to having to manually type such at the bootloader or having GENERIC 
> use whatever defaults it was compiled with.  Lastly, modules are helpful 
> because in the event there is a bug, or just unsupported hardware, most 
> distros will allow you to load your own modules during the installation 
> period (this has saved my ass numerous times).

Sounds good, someone likes modules, someone doesn't, I only wanted to
point out that even with modules, Linux as a kernel is monolithic.

> 
> > I'm very gratefull for OpenBSD's integrity, meaning things like binary
> > only drivers will never be accepted.
> 
> I don't see how this is true.
> 
> Sure binary only modules may not be possible, but binary only patches are 
> very much possible.  Additionally thanks to the liberal BSD license, this 
> becomes more so possible as opposed to the requirements of the GPL.

I think binary patches and binary kernel modules are very different.
Unless there is a source, or it complies with OpenBSD goals, they will
not accept anything kernel or userland related. Even with source, and a
bad license, they will not accept it. This is what I meant when I said
the above.
Binary patches patch already what is in the system. My comment only
related to things like binary-only NV drivers, for example.

-bruno