linux-kernel - Re: Version number policy!

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: <CAJ-VmomS_=1=QLZrfdD4vhu9Qy0w2JNQxEFrkt_OKjWetrWY4w@mail.gmail.com>
Date:	Mon, 8 Apr 2013 12:00:12 -0700
From:	Adrian Chadd <adrian@...ebsd.org>
To:	Christian Lamparter <chunkeey@...glemail.com>
Cc:	Eugene Krasnikov <k.eugene.e@...il.com>,
	Kalle Valo <kvalo@...rom.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	linux-bluetooth <linux-bluetooth@...r.kernel.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!

On 8 April 2013 08:33, Christian Lamparter <chunkeey@...glemail.com> wrote:
> On Monday, April 08, 2013 11:10:30 AM Eugene Krasnikov wrote:
>> It’s a good idea to pack bitmap into the tail/header of the firmware
>> binary to get capabilities even before fw loading. The plan is to add
>> 8 bytes for caps and also add time stamp. Let me play around with that
>> and provide fw and driver patch for review.
>
> Hm, come to think of it. Kalle, do you think ath9k_htc could use
> some bits of the fw header format, parser or the complete infrastructure
> from ath6kl? This could be great for Adrian, because he could
> just point people to it and they could moved it into the code
> into /drivers/net/wireless/ath/fw.c.

Just remember that we (ath9k_htc and carl9170) aren't constrained by
the same kinds of issues that closed firmware is. So version checks
aren't that bad, because that way over time we don't end up needing to
maintain lots of special cases for firmware options.

I still like the idea of firmware options for build time options that
people may wish to use - eg, say we want to support a version of
ath9k-htc firmware that does offloaded TX rate control, versus not.
But, maintaining multiple builds of the same firmware is IMHO going to
be a path towards madness to maintain.

The maintainability is why I'm hoping (!) to keep the number of
options low and just do "clean slate" moves whenever we shift to the
next major firmware version.

Adrian
--
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/