On Mon, 2007-10-22 at 10:33 -0400, Jon Masters wrote: > On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote: > > On Mon, 22 Oct 2007 10:06:24 -0400 > > Jon Masters <jcm@xxxxxxxxxx> wrote: > > > > > On a tangent, I would like to have a discussion about in-kernel > > > firmware as it becomes split out and loaded using request_firmware. > > > So that third parties can supply different firmware updates, can we > > > agree that it's worthwhile having one firmware package for each > > > firmware file set needed by the kernel package, in the longer term? > > > > These wouldn't turn into kmod like packages would they, and have all > > the same kludges to work with RPM? Are you going to have to handle > > different firmware sets for each kernel version you might have > > installed, plus alternatives from upstream? Obviously I'm a bit > > reluctant to reintroduce nightmares like this. > > The problem is if a user needs to upgrade the firmware for some card, > they can't do this if the file for that firmware lives inside the kernel > package (well, they can abuse the breakage in RPM for multilib and > possibly get away with another package owning the file, but...). If > we're interested in allowing firmware upgrades to happen outside of the > kernel (which is one reason it split out upstream), then this is needed. > > Would love to hear comments ;-) 99% of the time, the driver and firmware[1] are closely knit. Try upgrade the firmware of a QLogic card without the driver following, and watch bad things happen. I'm sure there are exceptions, which should be dealt with, but sometimes there are reasons why this is the case. I also seem to remember similar issues with cciss controllers which would lead to corruption with a driver/firmware mismatch. [1]: when the firmware is shipped as part of the driver -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
