Version number policy!

[Christian Lamparter]

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