[ewg] shipping firmware with ofed

[Doug Ledford]

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 <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090304/494a4d6d/attachment.sig>