/lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?]
Jeremy Katz ([EMAIL PROTECTED]) said: > On Thu, 2007-07-26 at 11:18 -0400, Bill Nottingham wrote: > > Chuck Ebbert ([EMAIL PROTECTED]) said: > > > The arcmsr driver is in-kernel but you can't install to a > > > system using it for the main disk controller: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 > > > > > > Ditto for the uli526x network driver, network installs are > > > impossible on systems using that: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 > > > > > > The kernel has the drivers available, but people are reporting > > > these as kernel bugs... > > > > module-info in the anaconda package. > > I should get back to trying to auto-generate this now that we have the > modules.scsi, etc files in place... I have code working for this at the moment... however, it seems wrong. Right now it's based on the modules.scsi, modules.networking, etc. that are shipped in very very recent kernel packages. Looking at how it's done now, we have: # Generate a list of modules for SCSI, sata/pata, and networking. touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking for i in `cat modnames | grep drivers | grep -v drivers\/ata` do if [ $(nm $i |grep --count scsi_add_host) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi fi done for i in `cat modnames | grep drivers | grep -v drivers\/scsi` do if [ $(nm $i |grep --count blk_init_queue) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi fi done for i in `cat modnames | grep drivers\/ata` do if [ $(nm $i |grep --count ata_device_add) -ne 0 -o $(nm $i |grep --count ata_pci_init_one) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata fi done for i in `cat modnames |grep drivers` do if [ $(nm $i |grep --count register_netdev) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking fi done in the kernel spec file. This has the following issues: 1) it's not complete (relatively easily fixed, but leads to...) 2) you can't ever fix the list for kernels that have these lists wrong without rebuilding them. That's bad. 3) anything that uses this will never work on a) older kernels b) 'upstream' kernels, etc. 4) there's a rather arbitrary ata vs. scsi distinction here that seems solely designed to cull the module list for the live CD. Seems strange to me. 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. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On 26.07.2007 17:40, David Woodhouse wrote: > On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: >> On 26.07.2007 17:26, David Woodhouse wrote: >>> On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: >>> [...] > People can go and implement kmod stuff in their own repositories -- we > _really_ don't want to be putting the 'Fedora' name on it. > > If it's good enough for Fedora, it's good enough for the kernel RPM. > If not, let them do it elsewhere. I see your point, nevertheless I think we should have kmods (and other experimental stuff) in a special testing repo For me the whole thing is connected to current "target audience" discussion on FAB. Fedora is trying to do lots stuff right, even if it's bad for Fedora (firefox.x86_64 by default, no kmods that don't head upstream, ...). That actually something I why I like Fedora and that's why I agree with you in the "don't put the 'Fedora' name on it". Nevertheless a lot of users and maintainers often fail to understand our high standards. I'd like to give those users a solution and educate them while at it. And I want to get the maintainers involved in that testing ground as they might grow up and soon do other stuff in the project, which will help us growing. CU thl ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
David Woodhouse wrote: On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: I tend to say that approach is fine for you, Hans and some other developers that are familiar with kernel-coding as those people have shown to be able to get code upstream and know how to work with upstream. Yes, although I'd phrase it as "that approach is fine for anyone who we'd actually want maintaining kernel code with the 'Fedora' name on it". But the code in question IMHO should show potential for a nearby upstream merge before it's being added. Absolutely. But users and packagers want some modules that do not head upstream in the near future -- let's take the lirc kernel-modules as example, where the lirc-upstream afaik is not actively working on getting the code into linus kernel. Nobody else is doing that either. I'd prefer to not have stuff like that in fedora's kernel rpm, as that could soon and in a major maintenance nightmare, which we all want to avoid afaics. It doesn't become any _less_ of a nightmare just because you ship it separately. If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all. I must say I like this approach, it avoids the whole problem of having to rebuild kmods all the time and of wether to delay kernel security updates until all kmods are fixetd etc. I do think however that this might cause some pain for Dave Jones, whose job already is hard. Maybe we should ask him what he thinks about this? Regards, Hans ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Who decides what drivers go on the install disk?
On Thu, 2007-07-26 at 11:18 -0400, Bill Nottingham wrote: > Chuck Ebbert ([EMAIL PROTECTED]) said: > > The arcmsr driver is in-kernel but you can't install to a > > system using it for the main disk controller: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 > > > > Ditto for the uli526x network driver, network installs are > > impossible on systems using that: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 > > > > The kernel has the drivers available, but people are reporting > > these as kernel bugs... > > module-info in the anaconda package. I should get back to trying to auto-generate this now that we have the modules.scsi, etc files in place... Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On 26.07.2007 17:26, David Woodhouse wrote: > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > [...] >> But users and packagers want some modules that do not head upstream in >> the near future -- let's take the lirc kernel-modules as example, >> where the lirc-upstream afaik is not actively working on getting the >> code into linus kernel. Nobody else is doing that either. I'd prefer >> to not have stuff like that in fedora's kernel rpm, as that could soon >> and in a major maintenance nightmare, which we all want to avoid >> afaics. > > It doesn't become any _less_ of a nightmare just because you ship it > separately. I'd even say the nightmare is a bit bigger. > If we don't want it Fedora's kernel RPM, then we don't want > it in Fedora at all. Users want it and we have people wanting to package and maintain those drivers. So let's give them a playing area with a big fat warning sign. That's IMHO way better to leave them out in the cold. Cu knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: > On 26.07.2007 17:26, David Woodhouse wrote: > > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > > [...] > >> But users and packagers want some modules that do not head upstream in > >> the near future -- let's take the lirc kernel-modules as example, > >> where the lirc-upstream afaik is not actively working on getting the > >> code into linus kernel. Nobody else is doing that either. I'd prefer > >> to not have stuff like that in fedora's kernel rpm, as that could soon > >> and in a major maintenance nightmare, which we all want to avoid > >> afaics. > > > > It doesn't become any _less_ of a nightmare just because you ship it > > separately. > > I'd even say the nightmare is a bit bigger. It's a lot bigger. > > If we don't want it Fedora's kernel RPM, then we don't want > > it in Fedora at all. > > Users want it and we have people wanting to package and maintain those > drivers. So let's give them a playing area with a big fat warning sign. > That's IMHO way better to leave them out in the cold. Users want ponies too. People can go and implement kmod stuff in their own repositories -- we _really_ don't want to be putting the 'Fedora' name on it. If it's good enough for Fedora, it's good enough for the kernel RPM. If not, let them do it elsewhere. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > I tend to say that approach is fine for you, Hans and some other > developers that are familiar with kernel-coding as those people have > shown to be able to get code upstream and know how to work with > upstream. Yes, although I'd phrase it as "that approach is fine for anyone who we'd actually want maintaining kernel code with the 'Fedora' name on it". > But the code in question IMHO should show potential for a > nearby upstream merge before it's being added. Absolutely. > But users and packagers want some modules that do not head upstream in > the near future -- let's take the lirc kernel-modules as example, > where the lirc-upstream afaik is not actively working on getting the > code into linus kernel. Nobody else is doing that either. I'd prefer > to not have stuff like that in fedora's kernel rpm, as that could soon > and in a major maintenance nightmare, which we all want to avoid > afaics. It doesn't become any _less_ of a nightmare just because you ship it separately. If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Who decides what drivers go on the install disk?
Chuck Ebbert ([EMAIL PROTECTED]) said: > The arcmsr driver is in-kernel but you can't install to a > system using it for the main disk controller: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 > > Ditto for the uli526x network driver, network installs are > impossible on systems using that: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 > > The kernel has the drivers available, but people are reporting > these as kernel bugs... module-info in the anaconda package. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On 26.07.2007 16:57, David Woodhouse wrote: > On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: >> Another issue I would like FESco to look at is the current somewhat grey >> state >> of kmod's I'm considering packaging kmod's for uvc (usb video class driver), >> lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in >> rawhide). But before I invest time in these I would first like to have the >> state of kmod's cleared up. I will try to work with there resp. upstreams to >> get them in the upstream kernel, and atleast for uvc and islsm upstream >> merger >> is planned already. > > I would still like to see kmod packages entirely deprecated in Fedora. I would like to see kmod packages entirely deprecated in the Everything spin of Fedora 8and thus updates-proper as well), but at the same time would like us to open a official testing area in the scope of the fedora project with a special repo for kmods and its deps to easen testing of that code, help getting it ready for upstream merge and semi-easy access for users. > If you want to maintain that kernel code and ship it with the 'Fedora' > brand on it, why don't we just give you commit access to the kernel > package? We can trust you to limit yourself to just those areas, and we > can trivially disable your patch(es) if it gets in the way of progress. > > We've done precisely that kind of thing before (including for bcm43xx > before that got merged). There's just no need for separate packages. I tend to say that approach is fine for you, Hans and some other developers that are familiar with kernel-coding as those people have shown to be able to get code upstream and know how to work with upstream. But the code in question IMHO should show potential for a nearby upstream merge before it's being added. But users and packagers want some modules that do not head upstream in the near future -- let's take the lirc kernel-modules as example, where the lirc-upstream afaik is not actively working on getting the code into linus kernel. Nobody else is doing that either. I'd prefer to not have stuff like that in fedora's kernel rpm, as that could soon and in a major maintenance nightmare, which we all want to avoid afaics. CU knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Who decides what drivers go on the install disk?
The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 Ditto for the uli526x network driver, network installs are impossible on systems using that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 The kernel has the drivers available, but people are reporting these as kernel bugs... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: > Another issue I would like FESco to look at is the current somewhat grey > state > of kmod's I'm considering packaging kmod's for uvc (usb video class driver), > lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in > rawhide). But before I invest time in these I would first like to have the > state of kmod's cleared up. I will try to work with there resp. upstreams to > get them in the upstream kernel, and atleast for uvc and islsm upstream > merger > is planned already. I would still like to see kmod packages entirely deprecated in Fedora. If you want to maintain that kernel code and ship it with the 'Fedora' brand on it, why don't we just give you commit access to the kernel package? We can trust you to limit yourself to just those areas, and we can trivially disable your patch(es) if it gets in the way of progress. We've done precisely that kind of thing before (including for bcm43xx before that got merged). There's just no need for separate packages. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
