On 30.09.2008 10:34, Arjan van de Ven wrote:
On Tue, 30 Sep 2008 01:24:22 -0400 Jon Masters jcm@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