[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> > 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.


> (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.


> 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.


> 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.


> 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.


Sven Luther

Reply to: