Message-Id: <201304090003.47056.chunkeey@googlemail.com>
Date:	Tue, 9 Apr 2013 00:03:46 +0200
From:	Christian Lamparter <chunkeey@...glemail.com>
To:	Eugene Krasnikov <k.eugene.e@...il.com>
Cc:	Adrian Chadd <adrian@...ebsd.org>, 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!

Hello,

On Monday, April 08, 2013 10:37:08 PM Eugene Krasnikov wrote:
> Did you have such a situation when e.g. one feature has 2 incompatible
> implementations?
I'm not aware of anything in particular. But we can look elsewhere for
examples, maybe Kalle knows one? Or you could ask the file system folks.
AFAIK ext2 fs is using one and they have maintained some basic 
compatibility throughout the major releases.

For example, it's possible to read data on a ext3 and ext4(dev) file
system with the old ext2 module - this is very user-friendly [1]!
Maybe, you can dig up more examples, just browse the web for "feature 
bits/flags/..."
 
> 2013/4/8 Adrian Chadd <adrian@...ebsd.org>:
> > 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 know, I know, but wouldn't it be great to have a common firmware parsing
infrastructure for all the driver with firmware under ath/? [No, I'm not
talking about writing a firmware that works on all devices. I want common
rules for firmware header descriptors. But if you peg features (firmware
or device!) to abstract firmware versions like "1.2.3.4-34+", then this is
going to be difficult.] 

> > 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.

Or like ext2,3,4 => just have a lowest common denominator. So users can
at least always access the web and get a matching firmware. 

Of course, it could be that we are just talking about completely different
things. Anyway, Luis asked me, if I have any "input"... and not more ;-).

Regards,
	Christian

[1] 
<https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#Can_I_mount_existing_Ext3_as_Ext4.3F_And_vice_versa.3F_Similarly_from_Ext2_to_Ext4_and_its_reverse.3F>
--
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/

Powered by blists - more mailing lists