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]

Message-ID: <1286611599.6145.435.camel@aeonflux>
Date:	Sat, 09 Oct 2010 10:06:39 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Sven-Haegar Koch <haegar@...net.de>
Cc:	"Luis R. Rodriguez" <lrodriguez@...eros.com>,
	Suraj Sumangala <Suraj.Sumangala@...eros.com>,
	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	"linux-kernel@...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 Sven-Haeger,

> > > > I last tried to document a thread we had over this here:
> > > >
> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > > >
> > 
> > Thanks, I've updated that link above to document bug fixing does not require
> > a filename change.
> 
> I would summarize it as:
> 
> If a new firmware version also works with an old driver, keep the filename.

correct.

> If a new firmware version also requires a new driver, change the name.
> 
> If a new driver requires a new firmware, change the name.

These two depend. The exposed API stays the same. The firmware file
itself is the same. Just the loading procedure is different. So no need
to change the firmware name.

Let me repeat this. If the API of the firmware exposed after loading it,
breaks or is incompatible, then you need a new name.

If you have generic commands to detect features in the firmware, then
you should never be needed to change your firmware name. So you could
extend the API as much as you like with keeping the same name.

The different firmware names are for the driver to be able to detect the
API of the firmware. And only if that is only possible via the filename
you should use different filenames. Otherwise don't bother and use the
generic feature detection of the firmware itself.

And for Bluetooth in specific that is HCI. So any company needed
different firmware filenames for Bluetooth have done something really
really wrong in their development cycles.

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/