Re: non-free firmware
On Wed, Jan 11, 2006 at 06:46:39PM -0500, Nathanael Nerode wrote:
> Sven Luther wrote:
> > If we are going to do this, we obviously need to find out a strong framework
> > how this is supposed to work, and all need to follow the same schema.
> Upstream hasn't done this. I realized this need and started asking people
> about an appropriate naming scheme for the files in /lib/firmware
> (or /usr/lib/hotplug/firmware as it was then) and attempted to keep it.
No, i don't think this was the kind of framework i was refering to, more of a
set of rules on how we would patch the drivers to make them request_firmware
aware.
>
> > I heard rumors about your patch being too disruptive, and was thus rejected
> by
> > davem, we don't want that to happen.
>
> I'll be blunt: those rumors are false, and whoever started them is slandering
> my work.
I wanted to say that davem found your patch to disruptive, but this is only
second hear knowledge.
> For the original patch, the reasons given for rejection were the following:
> (1) Either Jeff Garzik or Dave Miller (I don't remember which) wanted a
> transition period when the firmware loader would fall back to a built-in
> firmware copy. I was willing to write a patch which did that, but I thought
> it was a bit silly. I later asked if a patch would be accepted if it did
> that, but received no reply.
Ok.
> (2) Reasonable concerns were raised about needing firmware to be available in
> order to mount /usr, creating a nasty chicken-and-egg problem. This has
> mostly been addressed by the creation of /lib/firmware. Similar problems may
> arise with the mounting of root, I suppose, but with the switch to
> initramfs-all-the-time, these can be addressed trivially by modification of
> the initramfs.
Indeed, this needs support from the ramdisk tools, either initramfs-tools and
yaird, or debian-installer. Once debian-installer switches to initramfs (if it
has not already), simply appending the non-free bits to the ramdisk should be
trivial to do. Still sucks for cds or floppies.
> (3) Jeff Garzik and Dave Miller didn't think that firmware loading was a good
> idea at all, ever. Well, if they still think that, then they'll naturally
> reject the patch, and there's nothing we can do about it.
Indeed.
> None of these concerns has any relevance to Debian today.
>
> Dave Miller didn't feel that the (former) non-distributable licensing of the
> tg3 firmware, or indeed his own failure to put correct copyright notices on
> it, mattered. I felt very strongly that it did, and perhaps he took a
> dislike to me because of my stridency on that matter.
Probably.
> The last time I proposed a patch -- which simply separated the firmware into a
> separate file, so as to make life slightly easier for Debian, and on general
> tidiness grounds -- he accused me of trying to disguise my intentions, which
> I certainly was not. (Come on! I'm the poster child for strident and
> outspoken!) He then dropped my patch on the floor with no technical
> commentary at all. He did say that he didn't see the point unless it was
> combined with a full firmware loading patch; so I asked what technical
> requirements would be required of a full firmware loading patch (keeping in
> mind the responses earlier), and got absolute dead silence.
I think i remember that post.
> The only technical criticism which I have ever heard of my patch was the claim
> that firmware loading should not be done, and that firmware blobs should be
> compiled into the kernel. I don't consider this to be relevant commentary.
>
> During the original period of use of the patch in Debian, I discovered that
> the firmware was not only non-free but also not actually legal to distribute.
> This led to some unfortunate problems because people were unable to get
> copies of the loadable firmware, and I certainly don't want to repeat the
> situation where the driver tries to load firmware which people can't find. I
> made several efforts to contact the copyright holders without sucess (no
> replies at all). I also asked Dave Miller, who claimed to know the authors,
> if he could put me in contact with someone who might be able to do something
> about the licensing problems, but he refused. Thankfully this has been
> resolved now.
Yes, we contacted broadcom, and they solved the distributability issue. I know
people on LKML where saying that this would never happen, but it did. Took
time, but happened.
> The patch is not very invasive at all; I actually bent over backwards to avoid
> interfering with the call sequence (since request_firmware can't be called in
> a spinlock, and nearly the whole tg3 driver is in a single spinlock). I have
> had several people testify that it works just fine.
Ok.
> Again, those rumors are entirely false, so pay no attention to them.
I just expressed myself badly, that is all, i think the rumors well correspond
to what i read above, sorry for miscommunicating them.
Friendly,
Sven Luther
Reply to: