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.
I'm sorry everyone. I mis-spoke here. I thought Chelsio shipped the
binary fw image somehow with RHEL5.3. Turns out they do in fact bundle
it in a header file upstream. This is new news to me. :)
From Chelsio:
drivers/net/cxgb3/t3_firmware.h contains the FW and the protocol sram
images. The driver is modified to first try to load images under
/lib/firmware, then from the header file.
Guess I'll see about adding these driver changes into ofed.
Steve.
_______________________________________________
ewg mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
