Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
Other comments?
(the patch is from git.infradead.org/users/dwmw2/firmware-2.6.git)
Index: config-generic =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/config-generic,v retrieving revision 1.109 diff -u -p -r1.109 config-generic --- config-generic 4 Jun 2008 00:22:50 -0000 1.109 +++ config-generic 9 Jun 2008 09:59:12 -0000 @@ -2479,9 +2479,9 @@ CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m -CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL is not set CONFIG_SND_MAESTRO3=m -CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL is not set CONFIG_SND_MIRO=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m @@ -2502,7 +2502,7 @@ CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m -CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL is not set
# # ALSA USB devices @@ -3536,3 +3536,14 @@ CONFIG_SOC_CAMERA_MT9M001=m CONFIG_SOC_CAMERA_MT9V022=m # MT9V022_PCA9536_SWITCH is not set
+CONFIG_BUILTIN_FIRMWARE="" +# CONFIG_USB_KAWETH_FIRMWARE is not set +# CONFIG_DVB_TTUSB_BUDGET_FIRMWARE is not set +# CONFIG_USB_SERIAL_WHITEHEAT_FIRMWARE is not set +# CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set +# CONFIG_USB_SERIAL_TI_3410_FIRMWARE is not set +# CONFIG_USB_SERIAL_TI_5052_FIRMWARE is not set +# CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set +# CONFIG_USB_EMI62_FIRMWARE is not set +# CONFIG_USB_EMI26_FIRMWARE is not set + Index: kernel.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.679 diff -u -p -r1.679 kernel.spec --- kernel.spec 7 Jun 2008 01:48:53 -0000 1.679 +++ kernel.spec 9 Jun 2008 09:59:13 -0000 @@ -76,6 +76,8 @@ Summary: The Linux kernel (the core of t %define with_doc %{?_without_doc: 0} %{?!_without_doc: 1} # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} +# kernel-firmware +%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1} # kernel-bootwrapper (for creating zImages from kernel + initrd) @@ -565,6 +567,7 @@ Patch07: linux-2.6-compile-fixes.patch #Patch08: linux-2.6-compile-fix-gcc-43.patch
%if !%{nopatches} +Patch5: linux-2.6-firmware.patch
Patch10: linux-2.6-hotfixes.patch
@@ -693,6 +696,14 @@ header files define structures and const building most standard programs and are also needed for rebuilding the glibc package.
+%package firmware +Summary: Firmware files used by the Linux kernel +Group: Development/System +License: Redistributable +%description firmware +Kernel-firmware includes firmware files required for some devices to +operate. + %package bootwrapper Summary: Boot wrapper files for generating combined kernel + initrd images Group: Development/System @@ -992,6 +1003,7 @@ fi
%if !%{nopatches}
+ApplyPatch linux-2.6-firmware.patch ApplyPatch linux-2.6-hotfixes.patch
# Roland's utrace ptrace replacement. @@ -1581,6 +1593,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h %endif
+%if %{with_firmware} +make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install +%endif + %if %{with_bootwrapper} make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts %endif @@ -1690,6 +1706,12 @@ fi /usr/include/* %endif
+%if %{with_firmware} +%files firmware +%defattr(-,root,root) +/lib/firmware/* +%endif + %if %{with_bootwrapper} %files bootwrapper %defattr(-,root,root)
On Monday 09 June 2008 06:04:08 am David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
Other comments?
We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know.
On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote:
We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know.
Good point; I'll do it like that. Thanks.
On Mon, 2008-06-09 at 13:07 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote:
We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know.
Good point; I'll do it like that. Thanks.
Actually, it already was -- it was building the kernel-firmware subpackage for _both_ arch and noarch builds. I just needed to stop it doing so for the arch builds.
Jarod Wilson (jwilson@redhat.com) said:
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know.
Well, it means you may end up including various firmwares on architectures where they're irrelevant. But as long as you're willing to take the installed space hit, it's not a huge deal.
Bill
On Mon, 2008-06-09 at 10:01 -0400, Bill Nottingham wrote:
Well, it means you may end up including various firmwares on architectures where they're irrelevant. But as long as you're willing to take the installed space hit, it's not a huge deal.
Yeah, it doesn't take much -- and it's better on the file system than in unswappable kernel memory :)
Besides, I've deliberately kept 'make firmware_install' completely arch- and config-independent. You get the same bits wherever you run it.
David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Yeah, seems the sanest thing to do at least initially, so people don't suddenly wind up with non-functional devices.
Should the package own the /lib/firmware/ directory?
Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other.
On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote:
Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other.
I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense.
David Woodhouse wrote:
On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote:
Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other.
I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense.
Ah, okay, I figured udev typically would be wanted, but wasn't sure if some of this could be done sans-udev in some particular case. Just requiring udev does sound like the way to go then.
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
Is that something new upstream? It would be great to separate the firmware from the kernel builds.
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Cheers, Don
On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
Is that something new upstream? It would be great to separate the firmware from the kernel builds.
http://lwn.net/Articles/284104/ http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
On Mon, 2008-06-09 at 15:15 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
http://lwn.net/Articles/284104/ http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
Yup, I was going to reply with those links - especially the reply from the other Dave on pulling out firmware from the kernel :)
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
Good idea. But yeah, mkinitrd already looks for firmware files (those tagged with MODULE_FIRMWARE macros) and pulls them in.
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
Another issue that we never really solved was that we really need to have one firmware package per firmware (group) so that others can possibly override their firmware without replacing the entire kernel-firmware package and affecting everyone. Opinion?
Jon.
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote:
Another issue that we never really solved was that we really need to have one firmware package per firmware (group) so that others can possibly override their firmware without replacing the entire kernel-firmware package and affecting everyone. Opinion?
Later. We can't do it now, and it's not a loss. What we're doing makes it _easier_ to do that later, if we want to. But I don't want to try it now.
On Mon, 2008-06-09 at 15:48 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote:
Another issue that we never really solved was that we really need to have one firmware package per firmware (group) so that others can possibly override their firmware without replacing the entire kernel-firmware package and affecting everyone. Opinion?
Later. We can't do it now, and it's not a loss. What we're doing makes it _easier_ to do that later, if we want to. But I don't want to try it now.
K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :)
Jon.
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package.
On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package.
And that of course is a nicer fix, yeah, then people can have their own per-device firmware package if they choose to do so. Coolness.
Jon.
Jon Masters wrote:
On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package.
And that of course is a nicer fix, yeah, then people can have their own per-device firmware package if they choose to do so. Coolness.
Yeah, something like /lib/firmware/updates/ sounds gravy. I was initially thinking we could have a kernel-firmware package that was a meta-package, pulling in umpteen individual firmware packages (a la xorg-x11-drivers), but I like this idea better.
On Mon, Jun 09, 2008 at 03:53:07PM +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package.
Cute hack that might get ugly later when the tarball is actually updated with a newer version than the one in the 'special' directory leading to all sorts of confusion about what version is loading..
But I am for the baby steps approach just to get a sense of how this going to work properly.
Thanks for the effort.
Cheers, Don
On Mon, Jun 09, 2008 at 03:15:05PM +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
Is that something new upstream? It would be great to separate the firmware from the kernel builds.
http://lwn.net/Articles/284104/ http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
Thanks for the links. The discussion was helpful.
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..).
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally.
Cheers, Don
Don Zickus wrote:
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..).
I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :)
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally.
Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware.
Jarod Wilson wrote:
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally.
Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware.
But of course, you've still got a system that at least boots, and can back-rev the firmware if needed, so not a big issue vs. boot-path-dependent firmware.
On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote:
Don Zickus wrote:
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..).
I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :)
Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully? A stub kernel?
Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk?
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally.
Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware.
I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that.
Cheers, Don
Don Zickus wrote:
On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote:
Don Zickus wrote:
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..).
I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :)
Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully?
Not sure. What happens in such cases today? Have to install a new kernel or kmod?
A stub kernel?
Ew.
Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk?
Could get messy, littering /boot with old initrds that aren't cleaned up, and your bootloader with extra entries you may never use -- what would trigger their removal and when? I just assume leave out the auto-rebuilding of the initrd though. I think if you know you need/want new firmware for a device, you should be able to figure out how to create a new initrd with it (and save the old initrd as a fallback).
I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that.
Yeah, I sent a follow-up email saying the same, didn't take that into account until after hitting send, and my unsend button never seems to work... :)
On Mon, 2008-06-09 at 11:04 +0100, David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this.
The patches have now hit Linus' tree, so I've committed the specfile parts too. As soon as we update to 2.6.26-git1, we'll get a separate kernel-firmware package which is required by the main kernel binary package.
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Done. There are some firmwares which are under GPL, so even the "Free Software or nothing!" folks can have _some_ form of kernel-firmware package. I don't think there's a problem with requiring it.
I'll leave it to Alex to submit for review a kernel-firmware-libre package which Provides: kernel-firmware and which actually builds the various firmware files from source :)
Should the package own the /lib/firmware/ directory?
Not done.
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
Done.
kernel@lists.fedoraproject.org
-
Bill Nottingham -
David Woodhouse -
Don Zickus -
Jarod Wilson -
Jon Masters