linux-kernel

Open Source and information security mailing list archives

Date:	Fri, 5 Apr 2013 19:23:54 +0200
From:	Eugene Krasnikov <k.eugene.e@...il.com>
To:	Christian Lamparter <chunkeey@...glemail.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	Adrian Chadd <adrian@...ebsd.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	ath9k_htc_fw <ath9k_htc_fw@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Version number policy!

Good point regarding timestamp.

When it comes to feature bitmap do you have an example of such a
bitmap from carl9170? Why not to rely always on major version?

2013/4/5 Christian Lamparter <chunkeey@...glemail.com>:
> On Friday 05 April 2013 10:19:00 Luis R. Rodriguez wrote:
>> On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd <adrian@...ebsd.org> wrote:
>> > Here's my first take on the version number policy:
>> >
>> > https://github.com/qca/open-ath9k-htc-firmware/wiki/VersionPolicy
>> > The summary:
>> >
>> > * major version number changes are for firmware API / behaviour
>> > changes that aren't backwards compatible;
>> > * minor version number changes are for firmware API / behaviour
>> > changes that are incremental and default to the old behaviour (eg, new
>> > optional commands);
>> > * the driver should check the minor version number before using any
>> > optional features with that version.
>> >
>> > What's TODO:
>> >
>> > * Add a new WMI command to get the build number, git string, etc.
>> > * add it as our first optional minor version command :-)
>>
>> This is better than anything we had drafted before for 802.11 open
>> firmware design rules. Cc'ing a few lists for wider review given that
>> what we had written before for rules was for 802.11 and Bluetooth [0]
>> and it was very Linux specific. We are striving for open firmware here
>> for the community, for BSD / Linux. Christian would have dealt with
>> more of the support on open firmware design so far due to carl9170.fw
>> [1] so curious if he has any input.
> Based on my experience with carl9170, I can tell you that
> new stuff (new wmi commands, or advanced offload caps, features
> and bugfixes) should be advised via feature flags in bitmaps
> and not firmware versions. [Just make it long enough...]
>
> Otherwise you'll have to write endless checks like:
> if ((fw_minor == 1 && fw_patch > 30) ||
>     (fw_minor == 2 && fw_patch > 7) ||
>     (fw_minor == 3 && fw_patch > 3) ||
>     (fw_minor > 4))
>                 feature_supported = true;
>
> everytime you backport features and bugfixes to older firmwares.
>
> Also, firmware dates are more important than you think.
> They allow some way of syncing the firmware->driver and
> your inbox.
>
> Regards,
>         Christian
>
> _______________________________________________
> Ath9k_htc_fw mailing list
> Ath9k_htc_fw@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw

-- 
Best regards,
Eugene
--
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/

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