The logic to process mod-extra.list finds modules that depend on the modules in that list and includes those in kernel-module-extra as well. This logic is broken, because it does not account for multi-layer dependency chains. Specifically, if a module depends on another module, and only the second one depends on something in mod-extra.list, then only the second would get moved. This leaves the first module in the kernel package, resulting in WARNING messages when the kernel rpm is installed:
Preparing... ########################################### [100%] 1:kernel ########################################### [100%] WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_register_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_unregister_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_register_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_unregister_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_reset_all WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_handle_dn WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbd WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol __wusb_dev_get_by_usb_dev WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_giveback_urb WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusb_dev_destroy WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_disconnect WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_probe WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/net/bridge/netfilter/ebtable_broute.ko needs unknown symbol br_should_route_hook
This patch reverses that logic, so that anything in kernel with a dependency on something in mod-extra.list will cause the module in mod-extra.list to be treated as if it was _not_ in that list. This prevents the WARNING lines above.
Signed-off-by: John W. Linville linville@tuxdriver.com --- I don't think I'm very fond of the kernel-modules-extra package. But if it is going to be around, it needs to process the dependencies in a way that doesn't require both modules to be installed all the time. :-)
diff --git a/kernel.spec b/kernel.spec index e1cf978..136d50f 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1661,6 +1662,7 @@ BuildKernel() { # Look through all of the modules, and throw any that have a dependency in # our list into the list as well. rm -rf dep.list dep2.list + rm -rf req.list req2.list cp %{SOURCE16} . for dep in `cat modnames` do @@ -1673,12 +1675,16 @@ BuildKernel() { then continue else - echo $dep >> dep.list + echo $mod.ko >> req.list fi done done
- for mod in `cat mod-extra.list` + sort -u req.list > req2.list + sort -u mod-extra.list > mod-extra2.list + join -v 1 mod-extra2.list req2.list > mod-extra3.list + + for mod in `cat mod-extra3.list` do # get the path for the module modpath=`grep /$mod modnames` @@ -1696,7 +1702,8 @@ BuildKernel() { mv $mod $newpath done
- rm modnames mod-extra.list dep.list dep2.list + rm modnames dep.list dep2.list req.list req2.list + rm mod-extra.list mod-extra2.list mod-extra3.list popd
# remove files that will be auto generated by depmod at rpm -i time
On Fri, Dec 02, 2011 at 01:02:03PM -0500, John W. Linville wrote:
The logic to process mod-extra.list finds modules that depend on the modules in that list and includes those in kernel-module-extra as well. This logic is broken, because it does not account for multi-layer dependency chains. Specifically, if a module depends on another module, and only the second one depends on something in mod-extra.list, then only the second would get moved. This leaves the first module in the kernel package, resulting in WARNING messages when the kernel rpm is installed:
Preparing... ########################################### [100%] 1:kernel ########################################### [100%] WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_register_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_unregister_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_register_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_unregister_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_reset_all WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_handle_dn WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbd WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol __wusb_dev_get_by_usb_dev WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_giveback_urb WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusb_dev_destroy WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_disconnect WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_probe WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/net/bridge/netfilter/ebtable_broute.ko needs unknown symbol br_should_route_hook
Weird. I don't recall seeing any of those warnings at all in my testing.
This patch reverses that logic, so that anything in kernel with a dependency on something in mod-extra.list will cause the module in mod-extra.list to be treated as if it was _not_ in that list. This prevents the WARNING lines above.
Signed-off-by: John W. Linville linville@tuxdriver.com
I don't think I'm very fond of the kernel-modules-extra package. But if it is going to be around, it needs to process the dependencies in a way that doesn't require both modules to be installed all the time. :-)
Honestly, we might want to just call depmod to work out _all_ the dependencies, then parse modules.dep and move everything once. Playing games either way is just going to play shell games moving a module around.
josh
On Fri, Dec 02, 2011 at 01:13:33PM -0500, Josh Boyer wrote:
On Fri, Dec 02, 2011 at 01:02:03PM -0500, John W. Linville wrote:
I don't think I'm very fond of the kernel-modules-extra package. But if it is going to be around, it needs to process the dependencies in a way that doesn't require both modules to be installed all the time. :-)
Honestly, we might want to just call depmod to work out _all_ the dependencies, then parse modules.dep and move everything once. Playing games either way is just going to play shell games moving a module around.
Honestly, I still think that has it backwards. If a module is important enough to stay in kernel (e.g. a hardware device driver), then dependency on a module that was slated for extras shouldn't pull the more important module over there -- it should pull the "extra" module back to kernel instead.
John
On Fri, Dec 02, 2011 at 01:42:10PM -0500, John W. Linville wrote:
On Fri, Dec 02, 2011 at 01:13:33PM -0500, Josh Boyer wrote:
On Fri, Dec 02, 2011 at 01:02:03PM -0500, John W. Linville wrote:
I don't think I'm very fond of the kernel-modules-extra package. But if it is going to be around, it needs to process the dependencies in a way that doesn't require both modules to be installed all the time. :-)
Honestly, we might want to just call depmod to work out _all_ the dependencies, then parse modules.dep and move everything once. Playing games either way is just going to play shell games moving a module around.
Honestly, I still think that has it backwards. If a module is important enough to stay in kernel (e.g. a hardware device driver), then dependency on a module that was slated for extras shouldn't pull the more important module over there -- it should pull the "extra" module back to kernel instead.
Oh, sure, yes. I wasn't saying you were incorrect there, I was more commenting on the fact that our 'dependency information' as it is today is suspect. Might as well try and fix that at the same time.
josh
On Fri, Dec 02, 2011 at 01:13:33PM -0500, Josh Boyer wrote:
On Fri, Dec 02, 2011 at 01:02:03PM -0500, John W. Linville wrote:
The logic to process mod-extra.list finds modules that depend on the modules in that list and includes those in kernel-module-extra as well. This logic is broken, because it does not account for multi-layer dependency chains. Specifically, if a module depends on another module, and only the second one depends on something in mod-extra.list, then only the second would get moved. This leaves the first module in the kernel package, resulting in WARNING messages when the kernel rpm is installed:
Preparing... ########################################### [100%] 1:kernel ########################################### [100%] WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_register_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_unregister_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_register_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_unregister_driver WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_reset_all WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_handle_dn WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbd WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol __wusb_dev_get_by_usb_dev WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_giveback_urb WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusb_dev_destroy WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_disconnect WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_probe WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/net/bridge/netfilter/ebtable_broute.ko needs unknown symbol br_should_route_hook
Weird. I don't recall seeing any of those warnings at all in my testing.
Not sure why that would be. I downloaded the kernels from Koji and looked for bnx2i and cnic
[linville-8530p.local]:> rpm -qpl kernel-3.2.0-0.rc4.git1.3.fc17.x86_64.rpm | grep bnx2i /lib/modules/3.2.0-0.rc4.git1.3.fc17.x86_64/kernel/drivers/scsi/bnx2i /lib/modules/3.2.0-0.rc4.git1.3.fc17.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko
[linville-8530p.local]:> rpm -qpl kernel-modules-extra-3.2.0-0.rc4.git1.3.fc17.x86_64.rpm | grep cnic /lib/modules/3.2.0-0.rc4.git1.3.fc17.x86_64/extra/drivers/net/ethernet/broadcom/cnic.ko
I don't have that installed, but on my local kernel:
[linville-8530p.local]:> modinfo bnx2i filename: /lib/modules/3.2.0-rc3-wl/kernel/drivers/scsi/bnx2i/bnx2i.ko version: 2.7.0.3 license: GPL description: Broadcom NetXtreme II BCM5706/5708/5709/57710/57711/57712/57800/57810/57840 iSCSI Driver author: Anil Veerabhadrappa anilgv@broadcom.com and Eddie Wai eddie.wai@broadcom.com srcversion: 7445E1064FD8729B5E670FA depends: scsi_transport_iscsi,libiscsi,cnic ...
So as we say around here -- somin' ain't right... :-)
kernel@lists.fedoraproject.org