>  It's the classical monolithic kernel vs. microkernel war. There are
> advantages and disadvantages in both methods.

Ah ok, so on Windows the kernel includes code to call/use any generic driver 
(that is not part of the kernel itself), but on Linux the kernel actually 
includes the drivers.  And that means if you want to add/remove drivers from 
your system completely, you need to recompile the kernel under Linux.  Is 
that right?

>  For example, one disadvantage of Windows is that each new version of
> Windows always breaks a bunch of old drivers, so when you upgrade Windows
> you may find out that your old peripheral just doesn't work anymore.

Yep, am aware of that, usually with non-so-popular hardware you have to wait 
an age for the developer to release new drivers.

>  When the driver is integrated into the kernel, like in linux, it will
> obviously always work even if the kernel is seriously updated (because
> all the embedded drivers will be updated for the new kernel design as
> well).

When they release a new Linux kernel, how can they be sure that they haven't 
broken some other driver out there that someone wants to compile in with 
this new kernel?  Or is it impossible to develop a driver by yourself 
separate to the Linux kernel?

>  OTOH linux does support kernel modules. For example, if you want to
> install, let's say, the ATI binary driver, you don't need to recompile
> the kernel.

Hmm ok, so under Linux you have the choice of either running a driver as a 
separate module, or compiled in with the kernel?

So what are the benefits of compiling in the driver with the kernel as 
opposed to running it as a module then?

Post a reply to this message