Re: broadcom proposed firmware licence, please comment ...
On Thu, 2005-06-02 at 10:37 -0400, Nathanael Nerode wrote:
> Taking off debian-legal, since this is so not legal discussion anymore.
>
> Andres Salomon wrote:
> > > I think they said they'd accept a patch which loaded the firmware but fell
> > > back to firmware built into the kernel if it wasn't present, as a
> > > "transitional" requirement. Ugh squared. But I can do it; I can even do
> > > it in such a way that the tg3 patch to the kernel would consist of a
> single
> > > file deletion.
> >
> > Are they looking for a transition, or are they just looking for proof that
> > the firmware loading will actually work? Transition code doesn't sound
> > overly useful to me.
>
> They said they were looking for a transition. (And I agree, it doesn't sound
> that useful to me either.)
>
> I believe, however, that the idea was to avoid causing difficulties for people
> who didn't know where to find the firmware or how to install it. If the
> kernel installation files were changed to properly install firmware files in
> the right place per default, that would likely satisfy them. (I can
Yes, that's what I was thinking. Vendors will be taking care of
firmware file installation; kbuild should be handling it when running
modules_install. Perhaps a firmware_install target that takes care of
the various firmware blobs?
> integrate my generate-binary-firmware-file-from-hex code into the kernel
> patch if this sort of solution is desired.) Fixing up the installation files
> is just a little bit beyond what I'm personally willing to do at the moment,
> though, since I haven't yet figured out the kernel installation file system.
> So someone else would have to write that part.
>
I can do that, if necessary. What form was broadcom supplying firmware
in in the first place? If it's a binary firmware file, there's no need
to have a hex code converter; we can just throw the binary firmware file
in the directory tree.
> If anyone's volunteering to do so :-), I believe we'd decided that the "right
> place" was:
> /usr/lib/hotplug/firmware/tg3/5701_a0-0.0.0
> /usr/lib/hotplug/firmware/tg3/tso-1.4.0
> /usr/lib/hotplug/firmware/tg3/tso_5705-1.1.0
> (This forms the beginnings of a namespace and conventions for loadable
> firmware files, and is where my existing code puts them.)
>
I haven't bothered looking at other drivers in the tree that support
firmware loading; are paths hardcoded in there, or is the firmware
location simply a module/kernel arg?
> > Keep in mind the patch we'd have would have to simply readd the tg3
> > driver; the patch can't delete the file.
> Oh, what I was thinking was this:
> (1) reorganize the upstream kernel driver so that the included firmware was in
> a separate file (#included, for instance), as is done in most such drivers
This alone would go a long way towards making my life easier, if
upstream accepted it.
> (2) include the firmware loading code upstream
I assume the following is missing?
(2.5) Add binary firmware file, generated from hex code in header.
> (3) Debian's tar.gz.orig simply omits the firmware-containing file
> (4) The patch simply removes the references to it in the driver file
>
*nod*.
> > As such, it would still need to
> > be maintained (although shouldn't be too complex, as long as it doesn't
> > include firmware loading features and such).
Reply to: