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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]