de-modularising for the win!

[Thorsten Leemhuis]

On 30.09.2008 10:34, Arjan van de Ven wrote:
> On Tue, 30 Sep 2008 01:24:22 -0400
> Jon Masters <jcm at redhat.com> wrote:
>> On Mon, 2008-09-29 at 13:22 +0100, Matthew Garrett wrote:
>>> On Thu, Sep 25, 2008 at 04:09:57PM -0400, Jon Masters wrote:
>>>> I advocate extreme caution before just willy-nilly building
>>>> everything into the kernel. Although this might seem like a great
>>>> idea from the point of view of speeding up boot, there is also
>>>> the pesky issue of users wanting the choice to decide which
>>>> modules get loaded, and more importantly, wanting to override
>>>> those modules with their own. To do this truly "right" we'll need
>>>> to do rebinding of drivers in kernel. That's not always going to
>>>> be easily possible after it's in use.
>>> Linux is not about choice.
>> Well, it should be wherever possible :)
> for certain types of choices the answer is going to be "oh now you need
> to compile your own kernel"; there's just too many config options for
> that not to be the case.
> [...]
> In the RHEL world the rules are a bit different due to the really long
> release cycles (even for hw support updates), but on Fedora.... if you
> are capable of backporting a driver you can also build your own kernel
> or use an rpm provided.

You have a point, but I also tend to disagree a bit, because the 
backporting often is done by other people or the projects around the 
driver.

The alsa-project is a good example. Say you purchase a new motherboard 
and it has a brand new audio codec that is not yet supported by the 
in-kernel drivers. You report that to the alsa-project and they develop 
code to support that codec; a few days or weeks later they might tell 
you to download alsa-driver-1.0.18-alpha1.tar.bz and compile that for 
testing. If certain sound drivers (say snd-hda-intel) or the soundcore 
are compiled into the kernel (like planed for Fedora) then you will 
often be forced to recompile the whole kernel to test the new driver. 
That's a whole lot more complicated then compiling just the 
alsa-drivers, which is not that hard to do these days with current 
Fedora kernels.

The alsa-example also shows that it IMHO still take way to much time for 
a new driver or fixes out to the users. To work further on above 
example: from alsa-driver-1.0.18-alpha1.tar.bz it'll often take a few 
weeks till the code matures and becomes alsa-driver-1.0.18. From there 
is yet again takes a few weeks till those drivers get merged in the 
kernel during the next merge window; from there it takes yet again a few 
weeks until that kernel is ready; from there it yet again takes a few 
weeks until that kernel is shipped as regular fedora-update.  That can 
quickly mean: wait round about half a year for a new alsa-driver(¹) :-/


Okay, the unusual way the alsa-developers work is part of both 
problems... But that's something only they can fix....

CU
knurd

(¹) alsa right now is at alsa-driver-1.0.18rc3 -- 2.6.27 (rawhide/F10) 
will ship with something that is close to alsa-driver-1.0.17; right now 
F9 users since two or three weeks are on 2.6.26, which contains the 
alsa-driver 1.0.16 which were released on February the 5th afaics