On Wed, 2008-10-22 at 16:14 -0700, reinette chatre wrote: > In this firmware case we do not have "an id" (we have one > file that is loaded by firmware loader so we cannot know what we get > just by "looking at it" unless we enforce a version number in the > filename as we currently do in our driver) and the firmware can change, > potentially frequently, with the consequence of many "quirks" that need > to be maintained. But so you do know which firmware it is. Also, the driver looks into the firmware after loading it to see which version it has, no? At least there seemed to be a printout like that. b43 for example has a few dynamic function pointers that are assigned depending on the firmware. It even supports two completely different hardware-transmit-header layouts. > > It all depends on how much the ucode API changes and sometimes we really > > wanna cleanup the driver and remove the old code, but in that case we > > have to tell the users via modules_install that this kernel will break > > or we have to keep the old driver around. Breaking it from one kernel > > version to the next one without the user noticing only after reboot is > > just not good enough. > > I agree with you and Johannes in this regard and look forward to the > modules_install solution. I do hope this will be acceptable to > everybody. I think even in that case there should be one kernel version that warns and accepts both, and then the next one that requires the newer version. b43, for example, will print out a warning every time it loads old microcode and the kernel tells you which URL to go to to download new firmware that will no longer warn. The code has been in there for more than a kernel version because we aren't changing that, but thanks to this we can now rip out the old code should we implement new features that absolutely require the new firmware. The transition should be more gradual. Module install time in particular is quite late, at that point I might already have installed the kernel. And if you're anything like me, you install new kernels while sitting on a train for hours and hours after downloading the git tree at home ;) The patch Tomas identified doesn't look so extensive. Mind you, I don't even see how it causes a microcode error, must be your policy of aborting the microcode when it detects a regulatory violation? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
