On Sat, 2004-04-17 at 07:44, Ryan Underwood wrote: > 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 don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I mostly agree with your other points. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
