At Fri, 14 Mar 2008 09:46:02 +1300, Eliot Blennerhassett wrote:
OK. BTW, what if the newer firmware is loaded onto the old driver?
Within limits (how far apart driver and firmware are) this will work. Mostly we are adding functions to the firmware, so old driver will work with new firmware but a new driver won't work with old firmware. Sometimes old functions are deprecated, but we don't remove them straight away.
As long as the backward-compatibility is kept, I think it's fine to use the same name. What I'm concerned is rather the regression by the firmware package update.
So, I suppose the driver won't crash even if you have only the old firmware?
In the windows world our "driver" install includes driver, firmware, userspace dll, python bindings, and mixer application all matching.
Not that on Linux, obviously :) Of course, distros should provide the consistent packages, though.
Would it be safer to rename the firmware file for each incompatible version? If yes, we can change the asihpi driver code together with the firmware renames to couple tightly.
The firmware images contain the HPI version encoded in the header. I will at least log a warning that the driver and firmware version do not match.
That'll be good.
I guess its possible to use versioned file names. Did you have something in mind? Currently the filename is generated from an adapter ID:
sprintf(fw_name, "asihpi/dsp%04x.bin", nAdapter);
Well, you can simply add a version number suffix to the firmware name, such as, dspxxx-032011.bin. But, I think this versioned name is needed only if the firmware has compatibility issue. As long as the firmware has a certain level of compatibility, we can reuse the same name.
thanks,
Takashi