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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 09 Oct 2010 10:01:28 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	Suraj Sumangala <Suraj.Sumangala@...eros.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: Firmware versioning best practices: ath3k-2.fw rename or
 replace ath3k-1.fw ?

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.
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/