Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 01:25:50PM -0400, Bill Nottingham wrote: > Dave Jones ([EMAIL PROTECTED]) said: > > On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: > > > Bill Nottingham wrote: > > > > See various and sundry plumber's conf discussions. > > > > > > > > Comments? (The netfilter stuff needs further investigation.) > > > > > > Also, please add these, since they're nearly always loaded (patch is on > > > top of yours): > > > > I think this makes sense to do now as a stop-gap, but one day, > > I hope we can get to a situation where we do modprobe of such > > things based on a config file instead of always doing it. > > Ideally the DM layer would be able to request_module() the map type > whenever necessary. Wherever possible, yes that would be even better. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Dave Jones ([EMAIL PROTECTED]) said: > On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: > > Bill Nottingham wrote: > > > See various and sundry plumber's conf discussions. > > > > > > Comments? (The netfilter stuff needs further investigation.) > > > > Also, please add these, since they're nearly always loaded (patch is on > > top of yours): > > I think this makes sense to do now as a stop-gap, but one day, > I hope we can get to a situation where we do modprobe of such > things based on a config file instead of always doing it. Ideally the DM layer would be able to request_module() the map type whenever necessary. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: > Bill Nottingham wrote: > > See various and sundry plumber's conf discussions. > > > > Comments? (The netfilter stuff needs further investigation.) > > Also, please add these, since they're nearly always loaded (patch is on > top of yours): I think this makes sense to do now as a stop-gap, but one day, I hope we can get to a situation where we do modprobe of such things based on a config file instead of always doing it. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 01:06:57PM -0400, Peter Jones wrote: > -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-mirror.ko > -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-snapshot.ko > -rwxr--r-- 1 root root 7.0K 2008-09-23 21:38 dm-zero.ko > > 57kB or so max. But at the same time, these are loaded on nearly every > Fedora system, and loaded as modules they're taking up at least 64kB . > Groovy. Didn't mean it specifically for this case, but just in general it would be good to see the size increase we're going to be looking at. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Kyle McMartin wrote: On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 100644 --- a/config-generic +++ b/config-generic @@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set -CONFIG_DM_MIRROR=m +CONFIG_DM_MIRROR=y CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m CONFIG_DM_MULTIPATH_HP=m CONFIG_DM_MULTIPATH_RDAC=m -CONFIG_DM_SNAPSHOT=m +CONFIG_DM_SNAPSHOT=y CONFIG_DM_UEVENT=y -CONFIG_DM_ZERO=m +CONFIG_DM_ZERO=y Not that I object to this or anything of the sort, but it would be nice if when people were asking for things to be built-in, to see the size difference on vmlinux on a Fedora build with it enabled. Well, I haven't done a build (on a slow laptop right now) but these modules don't have anything funny going wrt compiling differently when modular. So that means: -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-mirror.ko -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-snapshot.ko -rwxr--r-- 1 root root 7.0K 2008-09-23 21:38 dm-zero.ko 57kB or so max. But at the same time, these are loaded on nearly every Fedora system, and loaded as modules they're taking up at least 64kB . -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: > Bill Nottingham wrote: >> See various and sundry plumber's conf discussions. >> >> Comments? (The netfilter stuff needs further investigation.) > > Also, please add these, since they're nearly always loaded (patch is on > top of yours): > > diff --git a/config-generic b/config-generic > index 0f43c42..de33831 100644 > --- a/config-generic > +++ b/config-generic > @@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y > CONFIG_DM_CRYPT=m > CONFIG_DM_DEBUG=y > # CONFIG_DM_DELAY is not set > -CONFIG_DM_MIRROR=m > +CONFIG_DM_MIRROR=y > CONFIG_DM_MULTIPATH=m > CONFIG_DM_MULTIPATH_EMC=m > CONFIG_DM_MULTIPATH_HP=m > CONFIG_DM_MULTIPATH_RDAC=m > -CONFIG_DM_SNAPSHOT=m > +CONFIG_DM_SNAPSHOT=y > CONFIG_DM_UEVENT=y > -CONFIG_DM_ZERO=m > +CONFIG_DM_ZERO=y > Not that I object to this or anything of the sort, but it would be nice if when people were asking for things to be built-in, to see the size difference on vmlinux on a Fedora build with it enabled. regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 100644 --- a/config-generic +++ b/config-generic @@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set -CONFIG_DM_MIRROR=m +CONFIG_DM_MIRROR=y CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m CONFIG_DM_MULTIPATH_HP=m CONFIG_DM_MULTIPATH_RDAC=m -CONFIG_DM_SNAPSHOT=m +CONFIG_DM_SNAPSHOT=y CONFIG_DM_UEVENT=y -CONFIG_DM_ZERO=m +CONFIG_DM_ZERO=y # # Fusion MPT device support ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Oct 02, 2008 at 03:18:37PM -0400, Chuck Ebbert wrote: > There will be complaints if we do anything that keeps people from building and > running ALSA on the released kernel. The failure here is that the only way to make HDA work is rebuilding kernel modules, not that rebuilding kernel modules becomes harder. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Oct 02, 2008 at 03:18:37PM -0400, Chuck Ebbert wrote: > On Wed, 1 Oct 2008 19:51:30 -0400 > Kyle McMartin <[EMAIL PROTECTED]> wrote: > > > > > > > I've got to agree, for ALSA who provide a turnkey package that lets people > > > test the latest drivers. Our users do compile that package and report back > > > whether it fixes their problems. We probably shouldn't build any sound > > > drivers > > > in so they can keep doing that. > > > > > > > Heh, we come back to this again... Why can't we do a debug/nodebug style > > split for rawhide's built-in-ness? For release we do what's best for > > the silent (core sound modules built in, drivers not, since they're pigs.) > > majority... > > > > There will be complaints if we do anything that keeps people from building and > running ALSA on the released kernel. > There will be complaints if we keep booting in 1 minute when everyone else takes 20 seconds. Guess who will be more numerous? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Wed, 1 Oct 2008 19:51:30 -0400 Kyle McMartin <[EMAIL PROTECTED]> wrote: > > > > I've got to agree, for ALSA who provide a turnkey package that lets people > > test the latest drivers. Our users do compile that package and report back > > whether it fixes their problems. We probably shouldn't build any sound > > drivers > > in so they can keep doing that. > > > > Heh, we come back to this again... Why can't we do a debug/nodebug style > split for rawhide's built-in-ness? For release we do what's best for > the silent (core sound modules built in, drivers not, since they're pigs.) > majority... > There will be complaints if we do anything that keeps people from building and running ALSA on the released kernel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Wed, 01 Oct 2008 21:18:07 -0400 Jon Masters <[EMAIL PROTECTED]> wrote: > FWIW, a couple of us are looking at ways to speed up modprobe. and just to be clear: the boot time cost of modules is only partially because of modprobe speed issues. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Wed, 01 Oct 2008 21:18:07 -0400 Jon Masters <[EMAIL PROTECTED]> wrote: > On Wed, 2008-10-01 at 19:51 -0400, Kyle McMartin wrote: > > > Heh, we come back to this again... Why can't we do a debug/nodebug > > style split for rawhide's built-in-ness? For release we do what's > > best for the silent (core sound modules built in, drivers not, > > since they're pigs.) majority... > > That's a beautifully elegant idea Kyle! Another kernel subpackage that > remains modular (maybe even more modular too) while the main kernel > can then be more aggressive about de-modularizing some things. > > FWIW, a couple of us are looking at ways to speed up modprobe. to be honest, how about applying the patches that already do this and have been there for 10+ months? -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Wed, 2008-10-01 at 19:51 -0400, Kyle McMartin wrote: > Heh, we come back to this again... Why can't we do a debug/nodebug style > split for rawhide's built-in-ness? For release we do what's best for > the silent (core sound modules built in, drivers not, since they're pigs.) > majority... That's a beautifully elegant idea Kyle! Another kernel subpackage that remains modular (maybe even more modular too) while the main kernel can then be more aggressive about de-modularizing some things. FWIW, a couple of us are looking at ways to speed up modprobe. * We clearly need a hashed index table to speedup loading, but some of the existing patches add a bunch of complexity for no real speedup. * Add a daemon mode that prevents modprobe having to reload its metadata hundreds of times and then run this daemon only during startup to handle the modprobe storm (and other times only by option). Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Wed, Oct 01, 2008 at 06:34:18PM -0400, Chuck Ebbert wrote: > On Tue, 30 Sep 2008 11:10:35 +0200 > Thorsten Leemhuis <[EMAIL PROTECTED]> wrote: > > > 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. > > > > I've got to agree, for ALSA who provide a turnkey package that lets people > test the latest drivers. Our users do compile that package and report back > whether it fixes their problems. We probably shouldn't build any sound drivers > in so they can keep doing that. > Heh, we come back to this again... Why can't we do a debug/nodebug style split for rawhide's built-in-ness? For release we do what's best for the silent (core sound modules built in, drivers not, since they're pigs.) majority... regards, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 30 Sep 2008 11:10:35 +0200 Thorsten Leemhuis <[EMAIL PROTECTED]> wrote: > 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. > I've got to agree, for ALSA who provide a turnkey package that lets people test the latest drivers. Our users do compile that package and report back whether it fixes their problems. We probably shouldn't build any sound drivers in so they can keep doing that. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 30 Sep 2008 10:33:14 -0400 Jon Masters <[EMAIL PROTECTED]> wrote: > Just because we can build our own kernels with whatever patches does > not mean that all users who want to add a driver are capable of this. please don't turn this discussion into the ridiculous. Adding a module is always possible, nobody is even thinking about suggesting to turn CONFIG_MODULES off. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, Sep 30, 2008 at 10:38:12AM -0400, Jon Masters wrote: > Nope. I'm just taking the viewpoint that users shouldn't be artificially > restricted from doing so. At the point where someone suggests building something into the kernel purely in order to prevent users building an out of tree module, I think we should worry about that argument. Until then? -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Jon Masters ([EMAIL PROTECTED]) said: > > Really? Do you have actual stats for the number (percentage) of Fedora > > users that *actually* need to update their modules (as opposed to following > > some blindly ridiculous message-board advice...) > > Nope. I'm just taking the viewpoint that users shouldn't be artificially > restricted from doing so. I know this isn't the case right now ... come back when there's actual data and a usage case. > proposed modules being built-in are fairly harmless, but I'm raising > this now before users can't build their own graphics drivers or whatever > else they would like to add to their system, based on choice. Linux is not about choice. Giving users the choice between 3 versions of a driver, or ten different desktops, or three different printing systems only means that *you've* made the choice to have your OS fail. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, Sep 30, 2008 at 10:33:14AM -0400, Jon Masters wrote: > Yay! So then one day we can look forward to everything being built in > and a user wanting to build a webcam driver having to build their own > kernel too. Then we'll really have won because that user - who can > follow some straightforward instructions on a website showing them how > to build a driver and install it - will give up and go use Ubuntu. I don't think anyone's argued for building an entirely static kernel. Where there's a significant advantage to building something in (and Arjan has shown that there is), we should do it. If there isn't, we shouldn't. I really don't think there's any reason the vast majority of our users would want to replace their AHCI driver, and the -hda one needs solving in some way other than "Download and rebuild ALSA" anyway. > Just because we can build our own kernels with whatever patches does not > mean that all users who want to add a driver are capable of this. If users are capable of following the documentation for building an out of tree module, they're capable of following the documentation describing how to produce a modified kernel. The ones who aren't are, I'm willing to bet, a smaller number than the users who would be attracted by increased boot speeds. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 2008-09-30 at 10:33 -0400, Bill Nottingham wrote: > Jon Masters ([EMAIL PROTECTED]) said: > > Which means that third parties will end up getting into the kernel > > rebuilding business if their modules are unloadable. Suddenly you have > > users running many different builds of the same Fedora kernel, and > > asking for help on mailing lists, and all of that goodness. > > Really? Do you have actual stats for the number (percentage) of Fedora > users that *actually* need to update their modules (as opposed to following > some blindly ridiculous message-board advice...) Nope. I'm just taking the viewpoint that users shouldn't be artificially restricted from doing so. I know this isn't the case right now, and the proposed modules being built-in are fairly harmless, but I'm raising this now before users can't build their own graphics drivers or whatever else they would like to add to their system, based on choice. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Jon Masters ([EMAIL PROTECTED]) said: > Which means that third parties will end up getting into the kernel > rebuilding business if their modules are unloadable. Suddenly you have > users running many different builds of the same Fedora kernel, and > asking for help on mailing lists, and all of that goodness. Really? Do you have actual stats for the number (percentage) of Fedora users that *actually* need to update their modules (as opposed to following some blindly ridiculous message-board advice...) Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 2008-09-30 at 10:25 -0400, Kyle McMartin wrote: > if a user is rebuilding their libata subsystem and replacing the > modules, or replacing their alsa modules, or whatnot, they've already > voided the "i'd like to help you" implied contract in open source, so > they should just go run and support their own kernel. Yay! So then one day we can look forward to everything being built in and a user wanting to build a webcam driver having to build their own kernel too. Then we'll really have won because that user - who can follow some straightforward instructions on a website showing them how to build a driver and install it - will give up and go use Ubuntu. Just because we can build our own kernels with whatever patches does not mean that all users who want to add a driver are capable of this. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, Sep 30, 2008 at 01:34:33AM -0700, Arjan van de Ven wrote: > 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. > Of course for the normal, common scenarios that's not the right answer, > but "I would like to replace core component FOO" it's perfectly fine. > > Users don't replace their AHCI driver much (and if they do, even today, > they're likely to just build their own whole kernel, or use a rawhide > kernel rpm) > > 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. > if a user is rebuilding their libata subsystem and replacing the modules, or replacing their alsa modules, or whatnot, they've already voided the "i'd like to help you" implied contract in open source, so they should just go run and support their own kernel. every patch in the fedora kernel has this implicit "i take responsibility if this breaks" property. of course, we're talking about /fedora/ here, not rhel. obviously the support reqiurements are vastly different for rhel. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 2008-09-30 at 01:34 -0700, Arjan van de Ven wrote: > for certain types of choices the answer is going to be "oh > now you need to compile your own kernel"; Yay! > In the RHEL world the rules are a bit different due to the > really long release cycles (even for hw support updates) Indeed, and it'll be amusing if we ever get to a point where RHEL users can update their modules but Fedora users can't :) > but on Fedora if you are capable of backporting a driver > you can also build your own kernel or use an rpm provided. Which means that third parties will end up getting into the kernel rebuilding business if their modules are unloadable. Suddenly you have users running many different builds of the same Fedora kernel, and asking for help on mailing lists, and all of that goodness. I'm just saying some caution is a good thing before everything gets built into the kernel image. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On 30.09.2008 10:34, Arjan van de Ven wrote: On Tue, 30 Sep 2008 01:24:22 -0400 Jon Masters <[EMAIL PROTECTED]> 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Tue, 30 Sep 2008 01:24:22 -0400 Jon Masters <[EMAIL PROTECTED]> 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. Of course for the normal, common scenarios that's not the right answer, but "I would like to replace core component FOO" it's perfectly fine. Users don't replace their AHCI driver much (and if they do, even today, they're likely to just build their own whole kernel, or use a rawhide kernel rpm) 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. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 :) Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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. -- Matthew Garrett | [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) I'm ok with all of these specific config changes, but I'd like to repeat what I said in Kyle's session about demodularising in general. 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. And while we might not love binary drivers, note that it is the user's choice to make. If they want to load proprietary (or just out of tree drivers) then we should not go out of our way to intentionally make this difficult for them. i.e. let's no go building in particular graphics drivers for political reasons...I'm pre-empting discussion there :) So, anyway, Bill's got a good base set of common options. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Arjan van de Ven wrote: On Fri, 19 Sep 2008 13:02:54 +0200 Gerd Hoffmann <[EMAIL PROTECTED]> wrote: Bill Nottingham wrote: - killing the initrd for that general 90% case can be a big win You aren't going to kill the initrd for a default fedora install due to root-on-lvm. why do we have root-on-lvm by default on laptops again? Because lots of Fedora developers multi-boot and/or use virtualization on their laptops, and lay users can't tell the difference. That said, I'm all in favor of having installation profiles for laptops, desktops, workstations, servers, etc. with their own sets of defaults. I'm just not enough in favor of it to learn the anaconda innards and do it, which is probably the same reason nobody else has done it either. -- Chris ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, Sep 19, 2008 at 08:02:47AM -0400, Josh Boyer wrote: > >-CONFIG_IEEE80211=m > >+CONFIG_IEEE80211=y > > CONFIG_IEEE80211_DEBUG=y > > CONFIG_IEEE80211_CRYPT_WEP=m > > CONFIG_IEEE80211_CRYPT_CCMP=m > > Do we have a way to _not_ do this on secondary architectures? the per-arch config fragments will always override options in config-generic, so yes. > >-CONFIG_SND_HDA_INTEL=m > >+CONFIG_SND_HDA_INTEL=y > > CONFIG_SND_HDA_HWDEP=y > > CONFIG_SND_HDA_CODEC_REALTEK=y > > CONFIG_SND_HDA_CODEC_ANALOG=y > >@@ -2545,7 +2545,7 @@ > > CONFIG_SND_HIFIER=m > > CONFIG_SND_ICE1712=m > > CONFIG_SND_ICE1724=m > >-CONFIG_SND_INTEL8X0=m > >+CONFIG_SND_INTEL8X0=y > > See... like these two. Not going to be in any ppc box, ever. Why include > them in the generic kernel config? I think they should be moved to > config-x86-generic.config instead. They got dumped in config-generic instead of duping them in config-x86[64] and config-ia64, but yeah, could do. if the options don't exist on an arch though it's competely benign regardless of what they get set to. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Fri, 19 Sep 2008 13:02:54 +0200 Gerd Hoffmann <[EMAIL PROTECTED]> wrote: > Bill Nottingham wrote: > > - killing the initrd for that general 90% case can be a big win > > You aren't going to kill the initrd for a default fedora install due > to root-on-lvm. why do we have root-on-lvm by default on laptops again? -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Gerd Hoffmann wrote: Bill Nottingham wrote: - killing the initrd for that general 90% case can be a big win You aren't going to kill the initrd for a default fedora install due to root-on-lvm. For the people who care the most about this, putting / on a partition is a very low hurdle compared to the other things they're trying to accomplish. -- Chris ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) > @@ -1284,7 +1284,7 @@ > CONFIG_WLAN_80211=y > # CONFIG_PCMCIA_RAYCS is not set > > -CONFIG_MAC80211=m > +CONFIG_MAC80211=y > CONFIG_MAC80211_QOS=y > CONFIG_MAC80211_RC_DEFAULT_PID=y > # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set This helps a lot of drivers, but I have no idea what percentage of Fedora users that represents. Do we know what percentage that _should_ be? Do we have smolt data to support meeting that percentage? I suspect that this is just a waste of memory for most desktop (as opposed to laptop) users. Also, as someone pointed out it is still common practice for people to run the compat-wireless package of back-ported drivers (and the matching mac80211 components). This might make life more difficult for those users. (NOTE: these are not the typical "out of tree" drivers -- they are in-tree, just a different, later tree.) Finally, _if_ we build these in then we should probable build-in the crypto modules that mac80211 requests... > @@ -1299,7 +1299,7 @@ > # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set > # CONFIG_MAC80211_DEBUG is not set > > -CONFIG_IEEE80211=m > +CONFIG_IEEE80211=y > CONFIG_IEEE80211_DEBUG=y > CONFIG_IEEE80211_CRYPT_WEP=m > CONFIG_IEEE80211_CRYPT_CCMP=m This only helps two drivers, ipw2100 and ipw2200. I don't think this is worthwhile. And FWIW, I ACK all the non-wireless bits! :-) John -- John W. Linville [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: >See various and sundry plumber's conf discussions. > >Comments? (The netfilter stuff needs further investigation.) > >Bill >? patch-2.6.27-rc1-git2.bz2 >? patch-2.6.27-rc1.bz2 >Index: config-generic >=== >RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v >retrieving revision 1.166 >diff -u -r1.166 config-generic >--- config-generic 9 Sep 2008 06:16:19 - 1.166 >+++ config-generic 18 Sep 2008 19:12:12 - >-CONFIG_MAC80211=m >+CONFIG_MAC80211=y > CONFIG_MAC80211_QOS=y > CONFIG_MAC80211_RC_DEFAULT_PID=y > # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set >@@ -1299,7 +1299,7 @@ > # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set > # CONFIG_MAC80211_DEBUG is not set > >-CONFIG_IEEE80211=m >+CONFIG_IEEE80211=y > CONFIG_IEEE80211_DEBUG=y > CONFIG_IEEE80211_CRYPT_WEP=m > CONFIG_IEEE80211_CRYPT_CCMP=m Do we have a way to _not_ do this on secondary architectures? >@@ -2528,7 +2528,7 @@ > CONFIG_SND_ES1968=m > CONFIG_SND_FM801=m > CONFIG_SND_FM801_TEA575X_BOOL=y >-CONFIG_SND_HDA_INTEL=m >+CONFIG_SND_HDA_INTEL=y > CONFIG_SND_HDA_HWDEP=y > CONFIG_SND_HDA_CODEC_REALTEK=y > CONFIG_SND_HDA_CODEC_ANALOG=y >@@ -2545,7 +2545,7 @@ > CONFIG_SND_HIFIER=m > CONFIG_SND_ICE1712=m > CONFIG_SND_ICE1724=m >-CONFIG_SND_INTEL8X0=m >+CONFIG_SND_INTEL8X0=y See... like these two. Not going to be in any ppc box, ever. Why include them in the generic kernel config? I think they should be moved to config-x86-generic.config instead. josh ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Dave Jones wrote: > how many do you typically need btw? I usually set it to 64 when I find the default 8 devices are not enougth. Frequently happens to me in case I loop-mount a collection of install iso images on a machine. I didn't hit the 64 limit yet. I've already needed more than 32. That was a while back though, with a collection of CDs instead of one DVD per distro ... cheers, Gerd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Bill Nottingham wrote: > - killing the initrd for that general 90% case can be a big win You aren't going to kill the initrd for a default fedora install due to root-on-lvm. cheers, Gerd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Chris Snook ([EMAIL PROTECTED]) said: >> See various and sundry plumber's conf discussions. > > Links please? Not sure where things are being posted. Summary: - modules are wasteful (you lose a good chunk of code size savings in page round up) - modules are slow (well, modprobe is) - for the modules that are used by 90% of machines, what's the point of having them static? - killing the initrd for that general 90% case can be a big win >> Comments? (The netfilter stuff needs further investigation.) > > -CONFIG_BLK_DEV_LOOP=m > +CONFIG_BLK_DEV_LOOP=y > -CONFIG_SCSI=m > +CONFIG_SCSI=y > -CONFIG_BLK_DEV_SR=m > +CONFIG_BLK_DEV_SR=y > -CONFIG_ATA_PIIX=m > +CONFIG_ATA_PIIX=y > -CONFIG_SATA_AHCI=m > +CONFIG_SATA_AHCI=y > -CONFIG_BLK_DEV_DM=m > +CONFIG_BLK_DEV_DM=y > > If this is going to make it easier to do fancy things in the initrd, I'm > all for it. If it's just a TLB thing, I don't think it's worth it. Fancy things by not having the initrd. > -CONFIG_MAC80211=m > +CONFIG_MAC80211=y > -CONFIG_IEEE80211=m > +CONFIG_IEEE80211=y > > Won't this make it harder for people to test experimental wireless > drivers? Unless the vendors start opening specs, we're going to have a > perpetual need to play around in this area with each new hardware rev. How so? There's one version shared among all the in-tree modules. If you're developing the kernel, you're already rebuilding, so you can do whatever. > -CONFIG_SND=m > +CONFIG_SND=y > -CONFIG_SND_SEQUENCER=m > +CONFIG_SND_SEQUENCER=y > -CONFIG_SND_MIXER_OSS=m > -CONFIG_SND_PCM_OSS=m > +CONFIG_SND_MIXER_OSS=y > +CONFIG_SND_PCM_OSS=y > -CONFIG_SND_RTCTIMER=m > +CONFIG_SND_RTCTIMER=y > -CONFIG_SND_HDA_INTEL=m > +CONFIG_SND_HDA_INTEL=y > -CONFIG_SND_INTEL8X0=m > +CONFIG_SND_INTEL8X0=y > > For the love of god, no. We have lots of sound problems that require > modprobe magic to troubleshoot and work around. Fix the [EMAIL PROTECTED] driver, then! (FWIW, the only sound problems I've seen recently is that the volume restore scripts got broken.) > This will require people > to rebuild their kernel just to test sound fixes, which will scare away > an awful lot of testers and inconvenience the rest. How often are we shipping random source patches to Fedora users, who would have to install kernel-devel and kernel-source anyway, causing them to download just as much data as a new test kernel? Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
> [1] Or someone can dig up the patches for dynamic loop allocation and > finish them off :-) Already exists. Try 'mknod loop23 ; losetup ...'... Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Chris Snook wrote: > Eric Sandeen wrote: >> Chris Snook wrote: >>> -CONFIG_EXT3_FS=m >>> +CONFIG_EXT3_FS=y >>> >>> I've been wondering for years why we weren't already doing this. >> see above, but I can live with it. Will we add ext4 and xfs (and >> reiserfs and jfs) too? > > Having one root-suitable filesystem built-in makes it easier to do a lot of > atypical boot configurations, which are becoming rather interesting thanks to > virtualization. If we're going to pick one, I think ext3 makes the most > sense. > I don't see a lot of benefit to building in xfs, reiserfs, or jfs, and I > think > we should definitely keep ext4 modular in its current stage of development. > > -- Chris Yeah, I agree, that's fair. (I wasn't really too serious about linking in every fs ...) Optimizing for the common case(s) makes sense. -Eric ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Eric Sandeen wrote: Chris Snook wrote: -CONFIG_EXT3_FS=m +CONFIG_EXT3_FS=y I've been wondering for years why we weren't already doing this. see above, but I can live with it. Will we add ext4 and xfs (and reiserfs and jfs) too? Having one root-suitable filesystem built-in makes it easier to do a lot of atypical boot configurations, which are becoming rather interesting thanks to virtualization. If we're going to pick one, I think ext3 makes the most sense. I don't see a lot of benefit to building in xfs, reiserfs, or jfs, and I think we should definitely keep ext4 modular in its current stage of development. -- Chris ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 2008-09-18 at 19:57 -0400, Dave Jones wrote: > On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote: > > On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote: > > > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: > > > > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > > > > See various and sundry plumber's conf discussions. > > > > > > > > If we build in the loop module, we need to bump the default of number > of > > > > loopdevs[1] to keep things happier for live images. Right now, we > just > > > > set maxloop in modprobe.conf > > > > > > does it not appear configurable in sysfs someplace? > > > > Unless something has changed from when I looked last, no. The devices > > are statically allocated on module(/built-in) load and that's as many as > > you get. > > how many do you typically need btw? Been bumping to 16 on live images as the compromise between "we're using a bunch just to get things working at all" vs "not using more is just sucking up memory" Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote: > On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote: > > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: > > > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > > > See various and sundry plumber's conf discussions. > > > > > > If we build in the loop module, we need to bump the default of number of > > > loopdevs[1] to keep things happier for live images. Right now, we just > > > set maxloop in modprobe.conf > > > > does it not appear configurable in sysfs someplace? > > Unless something has changed from when I looked last, no. The devices > are statically allocated on module(/built-in) load and that's as many as > you get. how many do you typically need btw? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. If we build in the loop module, we need to bump the default of number of loopdevs[1] to keep things happier for live images. Right now, we just set maxloop in modprobe.conf Jeremy [1] Or someone can dig up the patches for dynamic loop allocation and finish them off :-) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote: > On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote: > > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: > > > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > > > See various and sundry plumber's conf discussions. > > > > > > If we build in the loop module, we need to bump the default of number of > > > loopdevs[1] to keep things happier for live images. Right now, we just > > > set maxloop in modprobe.conf > > > > does it not appear configurable in sysfs someplace? > > Unless something has changed from when I looked last, no. The devices > are statically allocated on module(/built-in) load and that's as many as > you get. ok, should be easy enough hack in anyway. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote: > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: > > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > > See various and sundry plumber's conf discussions. > > > > If we build in the loop module, we need to bump the default of number of > > loopdevs[1] to keep things happier for live images. Right now, we just > > set maxloop in modprobe.conf > > does it not appear configurable in sysfs someplace? Unless something has changed from when I looked last, no. The devices are statically allocated on module(/built-in) load and that's as many as you get. Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote: > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > See various and sundry plumber's conf discussions. > > If we build in the loop module, we need to bump the default of number of > loopdevs[1] to keep things happier for live images. Right now, we just > set maxloop in modprobe.conf does it not appear configurable in sysfs someplace? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 06:35:19PM -0400, Dave Jones wrote: > On Thu, Sep 18, 2008 at 04:27:50PM -0500, Matt Domsch wrote: > > > This _is_ Fedora we're talking about, not RHEL, right? :-) > > /me has had to replace way too many kernel modules from RHEL, which > > can't be done if it's built-in. > > The thing is, Dell or any other vendor having to ship their > own module is to me a sign of a failing in the RHEL process that we > can't get fastpath pre-next-U release packages out fast enough. > THAT should be fixed rather than holding back Fedora > (or even RHEL, as it would be a shame that it couldn't take > advantage of these wins) (brief digression of Fedora is not RHEL, yes, we know, that's a good thing...) It's less a problem of fasttrack, it's more like the z-stream stuff. Where we've had to replace modules (or hey, subsystems a couple times) it was to keep the exact same kernel, but overlay specific targeted "fixes". Dell doesn't respin the whole factory install image very often (generally only respin once during the sales life of a given RHEL version), we replace the specific bits that we absolutely must, and nothing else, while at the same time ensuring those same fixes are in the next update kernel. This way, customers who are sticking to one specific kernel for whatever reasons can get the fix they need, while customers pulling the latest updates from Red Hat get those same fixes. This said, while I've replaced the MD, USB, and SATA subsystems a few times, and the SCSI layer, I don't recall having to replace ext* (knock on wood). -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 100644 --- a/config-generic +++ b/config-generic @@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set -CONFIG_DM_MIRROR=m +CONFIG_DM_MIRROR=y CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m CONFIG_DM_MULTIPATH_HP=m CONFIG_DM_MULTIPATH_RDAC=m -CONFIG_DM_SNAPSHOT=m +CONFIG_DM_SNAPSHOT=y CONFIG_DM_UEVENT=y -CONFIG_DM_ZERO=m +CONFIG_DM_ZERO=y # # Fusion MPT device support ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Dave Jones wrote: On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) looks like some of the lower-hanging fruit. definite room for further expansion. how well will mkinitrd cope when modules it always loads don't exist any more? any nasty hardcoded bits there? The biggest issue there will be that we've got a list of stuff that's supposed happen before scsi loads... but in reality, I don't think we care. If you can build me a scratch kernel once we're done deciding what to demodularize, fixing mkinitrd afterwards shouldn't be a very difficult task. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Chris Snook wrote: > Bill Nottingham wrote: >> See various and sundry plumber's conf discussions. > -CONFIG_MAC80211=m > +CONFIG_MAC80211=y > -CONFIG_IEEE80211=m > +CONFIG_IEEE80211=y > > Won't this make it harder for people to test experimental wireless drivers? > Unless the vendors start opening specs, we're going to have a perpetual need > to > play around in this area with each new hardware rev. I have this concern (brought it up before with Arjan too...) about filesystem stuff. For testing this means I can't lazily load my own custom modules into a pre-built kernel but oh well... it does make it harder to deliver test modules to users though. > -CONFIG_SND=m > +CONFIG_SND=y > -CONFIG_SND_SEQUENCER=m > +CONFIG_SND_SEQUENCER=y > -CONFIG_SND_MIXER_OSS=m > -CONFIG_SND_PCM_OSS=m > +CONFIG_SND_MIXER_OSS=y > +CONFIG_SND_PCM_OSS=y > -CONFIG_SND_RTCTIMER=m > +CONFIG_SND_RTCTIMER=y > -CONFIG_SND_HDA_INTEL=m > +CONFIG_SND_HDA_INTEL=y > -CONFIG_SND_INTEL8X0=m > +CONFIG_SND_INTEL8X0=y > > For the love of god, no. We have lots of sound problems that require > modprobe > magic to troubleshoot and work around. This will require people to rebuild > their kernel just to test sound fixes, which will scare away an awful lot of > testers and inconvenience the rest. does sound have to be initialized as part of the boot process? > -CONFIG_EXT3_FS=m > +CONFIG_EXT3_FS=y > > I've been wondering for years why we weren't already doing this. see above, but I can live with it. Will we add ext4 and xfs (and reiserfs and jfs) too? -Eric ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Bill Nottingham wrote: See various and sundry plumber's conf discussions. Links please? Comments? (The netfilter stuff needs further investigation.) -CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP=y -CONFIG_SCSI=m +CONFIG_SCSI=y -CONFIG_BLK_DEV_SR=m +CONFIG_BLK_DEV_SR=y -CONFIG_ATA_PIIX=m +CONFIG_ATA_PIIX=y -CONFIG_SATA_AHCI=m +CONFIG_SATA_AHCI=y -CONFIG_BLK_DEV_DM=m +CONFIG_BLK_DEV_DM=y If this is going to make it easier to do fancy things in the initrd, I'm all for it. If it's just a TLB thing, I don't think it's worth it. -CONFIG_MAC80211=m +CONFIG_MAC80211=y -CONFIG_IEEE80211=m +CONFIG_IEEE80211=y Won't this make it harder for people to test experimental wireless drivers? Unless the vendors start opening specs, we're going to have a perpetual need to play around in this area with each new hardware rev. -CONFIG_SND=m +CONFIG_SND=y -CONFIG_SND_SEQUENCER=m +CONFIG_SND_SEQUENCER=y -CONFIG_SND_MIXER_OSS=m -CONFIG_SND_PCM_OSS=m +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y -CONFIG_SND_RTCTIMER=m +CONFIG_SND_RTCTIMER=y -CONFIG_SND_HDA_INTEL=m +CONFIG_SND_HDA_INTEL=y -CONFIG_SND_INTEL8X0=m +CONFIG_SND_INTEL8X0=y For the love of god, no. We have lots of sound problems that require modprobe magic to troubleshoot and work around. This will require people to rebuild their kernel just to test sound fixes, which will scare away an awful lot of testers and inconvenience the rest. -CONFIG_EXT3_FS=m +CONFIG_EXT3_FS=y I've been wondering for years why we weren't already doing this. -- Chris ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) looks like some of the lower-hanging fruit. definite room for further expansion. how well will mkinitrd cope when modules it always loads don't exist any more? any nasty hardcoded bits there? Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 04:27:50PM -0500, Matt Domsch wrote: > This _is_ Fedora we're talking about, not RHEL, right? :-) > /me has had to replace way too many kernel modules from RHEL, which > can't be done if it's built-in. The thing is, Dell or any other vendor having to ship their own module is to me a sign of a failing in the RHEL process that we can't get fastpath pre-next-U release packages out fast enough. THAT should be fixed rather than holding back Fedora (or even RHEL, as it would be a shame that it couldn't take advantage of these wins) Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 05:14:14PM -0400, Tom spot Callaway wrote: > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > See various and sundry plumber's conf discussions. > > > > Comments? (The netfilter stuff needs further investigation.) > > Fly on the wall here, but wouldn't demodularizing the SCSI stack cause > problems down the road for RHEL, for third party SCSI/FC drivers? if a vendor is shipping their own scsi_mod or other part of the scsi layer to replace modules we ship, they may be DOING IT WRONG. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 18 Sep 2008 16:27:50 -0500 Matt Domsch <[EMAIL PROTECTED]> wrote: > In this most drivers are still modular, just the often-used hotpaths > are built-in, right? This avoids extra TLB lookups? Whatever > happened to mapping modules into the extra space at the end of the > kernel's 2MB TLB entries, to get the same benefit? it's a lot more than that; it's also about boot speed; module loading is just slow by nature, and while it can be made a bit faster, fundamentally, avoiding it for common cases is just the better solution. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Tom spot Callaway ([EMAIL PROTECTED]) said: > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > See various and sundry plumber's conf discussions. > > > > Comments? (The netfilter stuff needs further investigation.) > > Fly on the wall here, but wouldn't demodularizing the SCSI stack cause > problems down the road for RHEL, for third party SCSI/FC drivers? Well, that option doesn't appear to actually do anything, considering the fact that it's set to 'm' now and the scsi core isn't actually modular. So we may be able to ignore that one. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 18 Sep 2008 17:14:14 -0400 "Tom \"spot\" Callaway" <[EMAIL PROTECTED]> wrote: > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > > See various and sundry plumber's conf discussions. > > > > Comments? (The netfilter stuff needs further investigation.) > > Fly on the wall here, but wouldn't demodularizing the SCSI stack cause > problems down the road for RHEL, for third party SCSI/FC drivers? Fedora != RHEL In RHEL the performance / update tradeoff is likely different than for Fedora. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) This _is_ Fedora we're talking about, not RHEL, right? :-) /me has had to replace way too many kernel modules from RHEL, which can't be done if it's built-in. But Fedora, where we could ship a new kernel every day if we had to? Sure. In this most drivers are still modular, just the often-used hotpaths are built-in, right? This avoids extra TLB lookups? Whatever happened to mapping modules into the extra space at the end of the kernel's 2MB TLB entries, to get the same benefit? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote: > See various and sundry plumber's conf discussions. > > Comments? (The netfilter stuff needs further investigation.) Fly on the wall here, but wouldn't demodularizing the SCSI stack cause problems down the road for RHEL, for third party SCSI/FC drivers? ~spot ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
de-modularising for the win!
See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Bill ? patch-2.6.27-rc1-git2.bz2 ? patch-2.6.27-rc1.bz2 Index: config-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v retrieving revision 1.166 diff -u -r1.166 config-generic --- config-generic 9 Sep 2008 06:16:19 - 1.166 +++ config-generic 18 Sep 2008 19:12:12 - @@ -333,7 +333,7 @@ CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m -CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y @@ -427,7 +427,7 @@ # # SCSI device support # -CONFIG_SCSI=m +CONFIG_SCSI=y CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_PROC_FS=y @@ -448,7 +448,7 @@ CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m -CONFIG_BLK_DEV_SR=m +CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=m @@ -508,11 +508,11 @@ CONFIG_ATA=y CONFIG_ATA_SFF=y -CONFIG_ATA_PIIX=m +CONFIG_ATA_PIIX=y CONFIG_ATA_ACPI=y CONFIG_BLK_DEV_SX8=m CONFIG_PDC_ADMA=m -CONFIG_SATA_AHCI=m +CONFIG_SATA_AHCI=y CONFIG_SATA_INIC162X=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m @@ -636,7 +636,7 @@ CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m -CONFIG_BLK_DEV_DM=m +CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set @@ -790,7 +790,7 @@ CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m -CONFIG_NETFILTER_XTABLES=m +CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m @@ -808,7 +808,7 @@ CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m -CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m @@ -841,7 +841,7 @@ # # IP: Netfilter Configuration # -CONFIG_NF_CONNTRACK_ENABLED=m +CONFIG_NF_CONNTRACK_ENABLED=y CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y @@ -857,8 +857,8 @@ CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m -CONFIG_NF_CONNTRACK_IPV4=m -CONFIG_NF_CONNTRACK_IPV6=m +CONFIG_NF_CONNTRACK_IPV4=y +CONFIG_NF_CONNTRACK_IPV6=y CONFIG_NF_NAT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_CT_PROTO_DCCP=m @@ -1284,7 +1284,7 @@ CONFIG_WLAN_80211=y # CONFIG_PCMCIA_RAYCS is not set -CONFIG_MAC80211=m +CONFIG_MAC80211=y CONFIG_MAC80211_QOS=y CONFIG_MAC80211_RC_DEFAULT_PID=y # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set @@ -1299,7 +1299,7 @@ # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set # CONFIG_MAC80211_DEBUG is not set -CONFIG_IEEE80211=m +CONFIG_IEEE80211=y CONFIG_IEEE80211_DEBUG=y CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m @@ -2461,17 +2461,17 @@ # # Advanced Linux Sound Architecture # -CONFIG_SND=m +CONFIG_SND=y CONFIG_SND_VERBOSE_PROCFS=y -CONFIG_SND_SEQUENCER=m +CONFIG_SND_SEQUENCER=y CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y CONFIG_SND_OSSEMUL=y -CONFIG_SND_MIXER_OSS=m -CONFIG_SND_PCM_OSS=m +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y CONFIG_SND_PCM_OSS_PLUGINS=y -CONFIG_SND_RTCTIMER=m +CONFIG_SND_RTCTIMER=y CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_SND_SUPPORT_OLD_API is not set @@ -2528,7 +2528,7 @@ CONFIG_SND_ES1968=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y -CONFIG_SND_HDA_INTEL=m +CONFIG_SND_HDA_INTEL=y CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y @@ -2545,7 +2545,7 @@ CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m -CONFIG_SND_INTEL8X0=m +CONFIG_SND_INTEL8X0=y CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y @@ -2886,7 +2886,7 @@ CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y -CONFIG_EXT3_FS=m +CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y @@ -3199,6 +3199,7 @@ # CONFIG_CRYPTO=y CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_MANAGER=m # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AES=m Index: config-x86-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-x86-generic,v retrieving revision 1.47 diff -u -r1.47 config-x86-generic --- config-x86-generic 27 Jul 2008 07:22:15 - 1.47 +++ config-x86-generic 18 Sep 2008 19:12:12 - @@ -127,12 +127,12 @@ CONFIG_X86_MPPARSE=y CONFIG_ACPI=y -CONFIG_ACPI_AC=m +CONFIG_ACPI_AC=y # CONFIG_ACPI_ASUS is not set CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y -CONFIG_ACPI_BATTERY=m -CONFIG_ACPI_BAY=m +CONFIG_ACPI_BATTERY=y +CONFIG_ACPI_BAY=y CONFIG_ACPI_BLACKLIST_YEAR=1999 CONFIG_ACPI_
