Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Senthil Balasubramanian <senthilkumar@atheros.com>]

On Sat, Oct 09, 2010 at 01:31:28PM +0530, Marcel Holtmann wrote:
> Hi Luis,
> 
> > What is the difference between ath3k-2.fw and ath3k-1.fw ?
> > 
> > Won't the API change now that you are addressing the sflash
> > configuration fix? Would it not help to identify the two
> > different firmwares then?
> > 
> > David, Marcel, what are your preferences for a firmware upgrade
> > where the firmware does not change API (lets just pretend it does
> > not for a moment) ? Do we keep the same filename?
> 
> that is what most companies do and that is what iwlwifi has done so far.
Luis

this is what we have been doing for our ath9k_htc driver. We kept the same
fie name for firmware updates as we haven't changed any APIs/interfaces that
host driver depends on.

> Only if the API breaks a different suffix is used.
> 
> With Bluetooth this should be never needed at all. The reason is that
> you need to expose Bluetooth HCI. And that has generic version, support
> commands and supported features commands.
> 
> We are not even using the version information for anything useful these
> days since the firmware has to identify its features and its supported
> commands with standard HCI commands. So it is pretty simple to detect
> what Bluetooth subsystem needs to do.
> 
> > In this particular case I would assume our new sflash configuration
> > fix that might be being worked on might change the re-enumerated
> > USB device IDs so it seems to me a good idea to use a new filename.
> > I should note ath3k-2.fw already made it to linux-firmware.git...
> 
> No it does not. The changed PID is not a breakage. It will just keep
> working. So please fix this in linux-firmware.git right away and remove
> the new firmware file.
> 
> And here is something that is wrong with your process as well. Don't
> submit firmware files upstream before the upstream maintainers accepted
> your driver or patch.
> 
> I know it is nice to have the firmware available quickly, but if your
> driver gets rejected for the reason we have stated in this thread, you
> have dangling firmware somewhere.
> 
> > I last tried to document a thread we had over this here:
> > 
> > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > 
> > Does this sound sane? If so then the sflash configuration fix
> > would seem to me like it would require a new filename. Now, while
> > we're at it, how about bug fixes?
> 
> If your firmware files are identical and the exposed API is identical
> (in this case Bluetooth HCI), then you do NO need a new filename.
> 
> Regards
> 
> Marcel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html