[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Some thoughts about firmware inclusion.

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 redhat com> 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 ;-)

Is it frequently the case that firmware upgrades do not require driver
updates as well in order to function?  Many wireless issues seem to
revolve around the fact that firmware and drivers that are out of sync
just don't work.  If firmware is split out, how will such dependencies
be managed?

> Jon.
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]