On Tue, 2009-03-03 at 12:48 -0600, Steve Wise wrote: > Woodruff, Robert J wrote: > > Steve Wrote, > > > > > >> I request that we do add this. Forcing customers to download firmware > >> isn't very user friendly. > >> > > > > > >> It should be fairly easy to do, yes? I would take on the work involved > >> to add the infrastructure needed... > >> > > > > > >> All that would be needed, I think, is to make a src rpm that allows > >> generating an rpm that will install the firmware in /lib/firmware. Each > >> provider could manage their own. Or we could have a "firmware" src rpm > >> that holds all the providers' firmware images... > >> > > > > > >> Thoughts? > >> > > > > > >> Steve. > >> > > > > > > If people submit firmware to ofed, then would it have to be submitted > > under the dual BSD/GPL license as agreed to in the OFA bylaws. If so, > > then you would probably have to submit the firmware source code as well, > > and I am not sure if you are willing to do that... > > > > > > This has somehow been dealt with by RedHat. They ship chelsio binary > firmware without src. > > Doug, can you please comment on this?
I asked around, and we've never actually shipped Chelsio firmware (we almost did, but instead Chelsio added the firmware byte code into their upstream driver and we backported that so that the kernel has the firmware built into the Chelsio driver). We have shipped other firmware rpms in the past. Those rpms have to be built separate from regular source based rpms (or else the aggregation aspect of the GPL and most other licenses kicks in), so for instance you couldn't stick a binary firmware blob in the libcxgb3 rpm along side it's library source. We've also traditionally shipped any firmware packages on a separate CD/DVD from our main distribution where we had certain closed source but free to distribute items (like Adobe Reader/Flash Player, that sort of thing). And I don't think the firmware rpms are in the base channel in RHN but instead require you to subscribe to the addons channel in RHN (but I could be wrong on that, I don't keep up with RHN channel assignments myself). So, our preference is actually to have the right firmware be part of the driver itself. That's what cxgb3 does now, it's what QLogic FC adapters have done since forever, as well as quite a few other drivers, and it makes sure the driver and firmware *never* get out of sync. It also means that a kernel upgrade doesn't trigger a firmware upgrade on the file system which can render the previous kernel unusable. -- Doug Ledford <[email protected]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ewg mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
