On Sat, Apr 17, 2004 at 03:03:04AM +0200, Michel Dänzer wrote: > > It allows for the microcode to be updated without replacing the kernel, > > which is not a bad thing anyway.
But changing the microcode would change the driver->chip interface anyway. So you'd have to update the driver too. Keeping the driver and the userspace loader in sync might be...erm.. painful. If a userspace approach to firmware loading is pursued, perhaps a better approach is like the modprobe approach. When the XFree86 driver for a piece of hardware initializes, it would do a kernel probe for the firmware for this device, corresponding to the particular version of the driver that is running. The kernel would call a firmware loading binary (like it calls /sbin/modprobe or whatever is in that /proc entry) telling it what driver is asking and what version of the driver. Based on that information, the userspace loader can decide which version of the microcode to load up. If that version is not available, exit with failure and the kernel should then return failure to the application, so it knows that the proper microcode that particular driver version was written against was unable to be found, and to disable features which would require a loaded microcode. > I'm not sure it ever has changed or will change... we both know the > background of this; IMHO it's an inconvenience for users for little or > no gain of freedom. Well, microcode without source has been a big topic on debian-devel recently. There seems to be 3 interpretations under DFSG: 1) Binary only firmware under a license which doesn't require redistribution of source code is ok (i.e. a BSD license), but GPL licensed stuff is no good because no way to satisfy GPL. 2) Binary only firmware as well as GPL licensed stuff is ok. Here we are arguing intent on the part of whoever released the binary only code under GPL, and saying that they would be laughed out of court if it ever came to them suing a distributor for breach of GPL. 3) Neither of these is ok, must go into non-free because binary-only firmware doesnt meet DFSG (no source) regardless of its license. Either whole driver must go into non-free, or a crippled driver is provided in main and a userspace loader in non-free to add the missing functionality. 3 is a rather zealous approach, but seemed to be the approach that the "do-ers" on this issue are taking. I sympathize with the idealists on this issue, but I can't help but feel that this is impractical in the short run. I would love if Matrox gave me some microcode programming info for their WARP engine in G-series (could implement a T&L pipeline stage for instance), but I think inconveniencing users in this way is the wrong way to put pressure on the vendor to be more open (if that is the goal). These things are not general purpose computers, and I think the DFSG should only apply to software that is run on a general purpose computer. You could say that a video card or a random USB microcontroller may or may not be a Von Neumann machine. But it is probably not even close to Turing complete. Of course we don't know that without the specifications. But I don't see the point of applying DFSG to things that are not, or not known to be, general purpose computers. As long as the microcode is legally redistributable, I dont have a problem with it. (Granted, some of the microcode included with the Linux kernel seems not to be freely redistributable, and that is obviously a problem that some have been overlooking.) -- Ryan Underwood, <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
