On 30.09.2008 10:34, Arjan van de Ven wrote:
On Tue, 30 Sep 2008 01:24:22 -0400
Jon Masters <jcm@xxxxxxxxxx> 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
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
