Re: Version number policy!

On Mon, Apr 08, 2013 at 06:51:10PM -0700, Adrian Chadd wrote: > > But then you end up with people making filesystems which aren't > necessarily backwards compatible (and aren't aware of this), then try > to share with other extX implementations; or boot an older Linux > kernel (eg plugging an ext3

Re: Version number policy!

On 8 April 2013 17:37, Theodore Ts'o wrote: > There shouldn't be any crap; just a an error message indicating that > "the file system has features which this implementation doesn't > understand". At least, if the implementation was competently > coded (ext2/3/4 has feature bitmasks that make

Re: Version number policy!

On Mon, Apr 08, 2013 at 04:12:07PM -0700, Adrian Chadd wrote: > I'm a FreeBSD user. I know what it's like to have an alternate, out of > linux implementation of ext2/3 that doesn't implement all of the > features. > > I also know what kinds of crap happens when you try mounting a more > recent ext

Re: Version number policy!

I'm a FreeBSD user. I know what it's like to have an alternate, out of linux implementation of ext2/3 that doesn't implement all of the features. I also know what kinds of crap happens when you try mounting a more recent extX filesystem on an earlier kernel. Ie, it doesn't necessarily end well. :-

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

Re: Version number policy!

Christian, Did you have such a situation when e.g. one feature has 2 incompatible implementations? Let’s say initial implementation of “offloaded TX rate control” feature was immature and community decides to change implementation drastically so final realization of this feature is incompatible wi

Re: Version number policy!

On 8 April 2013 08:33, Christian Lamparter 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 s

Re: Version number policy!

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

Re: Version number policy!

Thanx Christian for a valuable input. 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. 2013/

Re: Version number policy!

On 5 April 2013 22:52, Kalle Valo wrote: > Eugene Krasnikov writes: > >> 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? > > I'm with Christian here. In ath6kl we switched to f

Re: Version number policy!

Eugene Krasnikov writes: > 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? I'm with Christian here. In ath6kl we switched to firmware advertising feature capabilities and I have

Re: Version number policy!

The point here is that once we hit a new major version, all the previous version checks can go away. So, if we decide to change some WMI message formats, it'll be in 2.x rather than 1.x. For example, has talked about killing off rate control in the NIC and doing it on the host. I'm happy with tha

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:

Re: Version number policy!

M, Adrian Chadd 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 / b

Re: Version number policy!

On Friday 05 April 2013 10:19:00 Luis R. Rodriguez wrote: > On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd wrote: > > Here's my first take on the version number policy: > > > > https://github.com/qca/open-ath9k-htc-firmware/wiki/VersionPolicy > > The summary: > &

Re: Version number policy!

Hi Adrian, This is the patch with new wmi command to support build number. Please let me know if it's ok so i can send it as pull request: >From 2591efa83bd24a807e3d93c4c8e1bf5c570737e1 Mon Sep 17 00:00:00 2001 From: Eugene Krasnikov Date: Fri, 5 Apr 2013 18:37:26 +0200 Subject: [PATCH] Add WMI_

Re: Version number policy!

On 5 April 2013 01:19, Luis R. Rodriguez wrote: > 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

Re: Version number policy!

On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd wrote: > Hi, > > 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 /