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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 5 Apr 2013 20:08:14 +0200
From:	Christian Lamparter <chunkeey@...glemail.com>
To:	Eugene Krasnikov <k.eugene.e@...il.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!

On Friday 05 April 2013 19:23:54 Eugene Krasnikov wrote:
> When it comes to feature bitmap do you have an example of such a
> bitmap from carl9170? 
That's a weird way of asking. No, I don't have an example?!
But carl9170fw_feature_list is used in "production".

Anyway, there is one defined in:
<https://github.com/chunkeey/carl9170fw/blob/master/include/shared/fwdesc.h#L26>

It's packed into the OTUS firmware descriptor:
<https://github.com/chunkeey/carl9170fw/blob/master/include/shared/fwdesc.h#L118>

And the descriptor is filled in:
<https://github.com/chunkeey/carl9170fw/blob/master/carlfw/src/fw.c>

[Basically, a bit for every feature in kconfig.]

Of course, the nice thing is, if you have something like
kconfig (carl9170fw.git uses a pretty much the vanilla kernel
kconfig. Everything apart from the cmake scripts for gperf
(which is in extra/) is packed into the conf/ directory.

And it has the necessary cmake files. So it should integrate 
well into the "new" ath9k_htc cmake build system Felix made.

> Why not to rely always on major version?
Ok, let's do the same with major version...

if  ((fw_major == 1 && fw_minor > 30) ||
     (fw_major == 2 && fw_minor > 7) ||
     (fw_major == 3 && fw_minor > 3) ||
     (fw_major > 4))
      feature_supported = true;

Nope, I think it looks just as bad.
[Please, explain what you meant to say...
Because the new versioning draft stats that very
major release is incompatible with the old one and
clearly, having to support a ton of different firmware
trees is no joy.... and not necessary]

BTW: Instead of a GET_BUILD command, why not make a add a
firmware header or pack the information into the tail... 

This way, it can be read and parsed by tools, without having
to upload it to the device first.

carl9170fw already such a tool, it's called: fwinfo and it is located in: 
<https://github.com/chunkeey/carl9170fw/blob/master/tools/src/fwinfo.c>

Regards,
	Christian
--
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/