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
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
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
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
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.
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
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
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
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
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.
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.
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
On 8 April 2013 08:33, Christian Lamparter chunk...@googlemail.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
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
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
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.
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 extX
On 8 April 2013 17:37, Theodore Ts'o ty...@mit.edu 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
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
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
Eugene Krasnikov k.eugen...@gmail.com 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
On 5 April 2013 22:52, Kalle Valo kv...@adurom.com wrote:
Eugene Krasnikov k.eugen...@gmail.com 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.
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
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:
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 / behavi
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:
> >
&
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
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.
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 / beha
On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd adr...@freebsd.org 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 / behaviour
changes
On 5 April 2013 01:19, Luis R. Rodriguez mcg...@do-not-panic.com 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
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 k.eugen...@gmail.com
Date: Fri, 5 Apr 2013 18:37:26 +0200
On Friday 05 April 2013 10:19:00 Luis R. Rodriguez wrote:
On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd adr...@freebsd.org 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
at 11:27 AM, Adrian Chadd adr...@freebsd.org 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 / behaviour
changes that aren't backwards compatible
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:
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
36 matches
Mail list logo
