Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Bill Nottingham ([EMAIL PROTECTED]) said: Here you go; sorts them into two piles (networking and block), and expands the symbol list to catch some of the missing modules such as ahci and some of the wireless drivers. ... committed. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
On Fri, 2007-07-27 at 12:28 -0400, Bill Nottingham wrote: Jon Masters ([EMAIL PROTECTED]) said: On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote: Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation. It can be done in module-init-tools, and probably should be. Let me take a look. Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules. I'm thinking about it ;-) Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
On Fri, 2007-07-27 at 12:28 -0400, Bill Nottingham wrote: Jon Masters ([EMAIL PROTECTED]) said: On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote: Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation. It can be done in module-init-tools, and probably should be. Let me take a look. Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules. When davej and I talked about it, we decided probably not. And maintaining two lists of it is insane, so we decided putting the info in the kernel package wasn't a bad thing. Especially as that's where you'll know when you need to change it Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
On Fri, 2007-07-27 at 13:43 -0400, Bill Nottingham wrote: Jeremy Katz ([EMAIL PROTECTED]) said: Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules. When davej and I talked about it, we decided probably not. And maintaining two lists of it is insane, so we decided putting the info in the kernel package wasn't a bad thing. Especially as that's where you'll know when you need to change it But that means any time the symbol list changes, you'll need to rebuild the kernel ; you effectively have a DOA kernel for the installer. Lots of things can lead to a DOA kernel. It's not like the symbols we're talking about here are things that change frequently. And it's more likely to actually get *done* if it's in the same place that the changes occur. Otherwise, no one's going to tell us that the symbol list changed until someone happens and we're in exactly the same place we are now. There is zero reason why this information should be maintained within the installer,etc If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours. There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Jeremy Katz ([EMAIL PROTECTED]) said: Depends on how many copies of the qlogic driver there are ;-) RHEL live CDs? What's that? (Actually, I lied - drivers/block + drivers/scsi is 1.3M compressed.) I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here OK. I'll tweak the stuff in the spec and send it here for comments. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Jeremy Katz ([EMAIL PROTECTED]) said: If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours. There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there In that case, I strongly suggest combining the libata and scsi lists into a single list for block devices - I doubt the 1M savings on the livecd is really worth splitting hairs here. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
On Fri, 2007-07-27 at 14:03 -0400, Bill Nottingham wrote: Jeremy Katz ([EMAIL PROTECTED]) said: If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours. There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there In that case, I strongly suggest combining the libata and scsi lists into a single list for block devices - I doubt the 1M savings on the livecd is really worth splitting hairs here. Depends on how many copies of the qlogic driver there are ;-) Especially since we'll have to be pulling in firmware, etc eventually. I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
