[B.A.T.M.A.N.] sysfs compat

[B.A.T.M.A.N.] sysfs compat

[Marek Lindner]

Hi,

the current trunk contains some code which breaks our backward compatibility, 
especially the sysfs API seem to be troublesome. I made 2 patches that address 
the issue on my 2.6.21 test system. It would be nice if you could test them on 
your system as well. I'd be particularly interested in kernels older than 
2.6.25. Does someone have a 2.6.20 system ?

At some point we have to start thinking about how many versions we want to 
support. Each new kernel brings more changes which need to be dealt with. 
Right now, the required effort is still at a sustainable level but the gap is 
growing. On one hand it is a nice playground to expand our knowledge about 
macros and demonstrate what nasty things you can do (see the second patch as 
an example).  ;-)
On the other hand it always requires a serious amount of time and effort. It 
only makes sense if at least some people are using it. Opinions ?

Regards,
Marek

[B.A.T.M.A.N.] [PATCH 1/2] batman-adv: adding MAC_FMT compatibility

[Marek Lindner]

Kernel older than 2.6.24 do not have the MAC_FMT definition,
therefore we need to add it to our compat layer.

Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
 batman-adv-kernelland/compat.h |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/batman-adv-kernelland/compat.h b/batman-adv-kernelland/compat.h
index 2e3aded..4eaa128 100644
--- a/batman-adv-kernelland/compat.h
+++ b/batman-adv-kernelland/compat.h
@@ -62,6 +62,12 @@ static inline int skb_clone_writable(struct sk_buff *skb, unsigned int len)
 
 #endif /* < KERNEL_VERSION(2, 6, 23) */
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 24)
+
+#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
+
+#endif /* < KERNEL_VERSION(2, 6, 24) */
+
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
 
 #define strict_strtoul(cp, base, res) \
-- 
1.7.0

[B.A.T.M.A.N.] [PATCH 2/2] batman-adv: adding sysfs compat

[Marek Lindner]

The linux sysfs layer changed with 2.6.25 which breaks batman-adv
on older versions. This patch adds a compat layer for the affected
function calls.

Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
 batman-adv-kernelland/bat_sysfs.c |    1 +
 batman-adv-kernelland/compat.h    |   70 +++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/batman-adv-kernelland/bat_sysfs.c b/batman-adv-kernelland/bat_sysfs.c
index c700359..7690368 100644
--- a/batman-adv-kernelland/bat_sysfs.c
+++ b/batman-adv-kernelland/bat_sysfs.c
@@ -27,6 +27,7 @@
 #include "gateway_common.h"
 #include "gateway_client.h"
 #include "vis.h"
+#include "compat.h"
 
 #define to_dev(obj)     container_of(obj, struct device, kobj)
 
diff --git a/batman-adv-kernelland/compat.h b/batman-adv-kernelland/compat.h
index 4eaa128..9f21f5a 100644
--- a/batman-adv-kernelland/compat.h
+++ b/batman-adv-kernelland/compat.h
@@ -23,6 +23,7 @@
  */
 
 #include <linux/version.h>	/* LINUX_VERSION_CODE */
+#include "bat_sysfs.h"		/* struct bat_attribute */
 
 #ifndef IPPROTO_UDP
 #define IPPROTO_UDP 17
@@ -80,6 +81,75 @@ static inline int skb_clone_writable(struct sk_buff *skb, unsigned int len)
 	ret; \
 })
 
+#define transtable_local_read(kobj, attr, buff, off, count) \
+	transtable_local_read(kobj, buff, off, count)
+#define transtable_global_read(kobj, attr, buff, off, count) \
+	transtable_global_read(kobj, buff, off, count)
+#define originators_read(kobj, attr, buff, off, count) \
+	originators_read(kobj, buff, off, count)
+#define gateways_read(kobj, attr, buff, off, count) \
+	gateways_read(kobj, buff, off, count)
+#define vis_data_read(kobj, attr, buff, off, count) \
+	vis_data_read(kobj, buff, off, count)
+
+#define to_battr(a) container_of(a, struct bat_attribute, attr)
+
+static inline ssize_t bat_wrapper_show(struct kobject *kobj,
+				   struct attribute *attr, char *buf)
+{
+	struct bat_attribute *bat_attr = to_battr(attr);
+
+	if (bat_attr->show)
+		return bat_attr->show(kobj, attr, buf);
+
+	return -EIO;
+}
+
+static inline ssize_t bat_wrapper_store(struct kobject *kobj,
+				    struct attribute *attr,
+				    const char *buf, size_t count)
+{
+	struct bat_attribute *bat_attr = to_battr(attr);
+
+	if (bat_attr->store)
+		return bat_attr->store(kobj, attr, (char *)buf, count);
+
+	return -EIO;
+}
+
+static struct sysfs_ops bat_wrapper_ops = {
+	.show   = bat_wrapper_show,
+	.store  = bat_wrapper_store,
+};
+
+static struct kobj_type ktype_bat_wrapper = {
+	.sysfs_ops      = &bat_wrapper_ops,
+};
+
+static inline struct kobject *kobject_create_and_add(const char *name,
+						     struct kobject *parent)
+{
+	struct kobject *kobj;
+	int err;
+
+	kobj = kzalloc(sizeof(*kobj), GFP_KERNEL);
+	if (!kobj)
+		return NULL;
+
+	kobject_set_name(kobj, name);
+	kobj->ktype = &ktype_bat_wrapper;
+	kobj->kset = NULL;
+	kobj->parent = parent;
+
+	err = kobject_register(kobj);
+	if (err) {
+		kobject_put(kobj);
+		return NULL;
+	}
+
+	return kobj;
+}
+
 #endif /* < KERNEL_VERSION(2, 6, 25) */
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 26)
-- 
1.7.0

Re: [B.A.T.M.A.N.] sysfs compat

[Andrew Lunn]

> At some point we have to start thinking about how many versions we
> want to support. Each new kernel brings more changes which need to
> be dealt with.  Right now, the required effort is still at a
> sustainable level but the gap is growing. On one hand it is a nice
> playground to expand our knowledge about macros and demonstrate what
> nasty things you can do (see the second patch as an example).  ;-)
> On the other hand it always requires a serious amount of time and
> effort. It only makes sense if at least some people are using
> it. Opinions ?

I guess the problem here is devices which cannot use modern kernels.

Why can a device not use a modern kernel?

1) Binary only drivers which work only for a specific kernel. I guess
   the biggest problem here is broadcom devices? What is the current
   state here? How good is the native linux broadcom driver? Are there
   other chipsets without an open driver?

2) The need to use a vendor kernel since the mainline kernel does not
   have the necessary support. How big a problem is this?

What other reasons are there not to use a modern kernel?

   Andrew
    

Re: [B.A.T.M.A.N.] sysfs compat

[Franz Böhm]

Also all Atheros based systems with binary drivers from Atheros itself 
or SDK's from third party vendors only work with particular (quite old) 
kernel versions. Perhaps you are able to build with newer kernel but 
it's much more difficult to get support from the chip manufacturer this way.

Using open source drivers instead is not always an opinion because it's 
very hard to comply with radio regulations and get your product 
certified. This is why I think it's somehow also important for BATMAN to 
support older kernels.

This problem also applies to Sigma Designs, Texas Instrument and all 
other Multimedia-SOC vendors but there will seldom be BATMAN on non 
wireless systems like this :-)

Franz


Andrew Lunn schrieb:
>> At some point we have to start thinking about how many versions we
>> want to support. Each new kernel brings more changes which need to
>> be dealt with.  Right now, the required effort is still at a
>> sustainable level but the gap is growing. On one hand it is a nice
>> playground to expand our knowledge about macros and demonstrate what
>> nasty things you can do (see the second patch as an example).  ;-)
>> On the other hand it always requires a serious amount of time and
>> effort. It only makes sense if at least some people are using
>> it. Opinions ?
> 
> I guess the problem here is devices which cannot use modern kernels.
> 
> Why can a device not use a modern kernel?
> 
> 1) Binary only drivers which work only for a specific kernel. I guess
>    the biggest problem here is broadcom devices? What is the current
>    state here? How good is the native linux broadcom driver? Are there
>    other chipsets without an open driver?
> 
> 2) The need to use a vendor kernel since the mainline kernel does not
>    have the necessary support. How big a problem is this?
> 
> What other reasons are there not to use a modern kernel?
> 
>    Andrew
>     
> 

Re: [B.A.T.M.A.N.] sysfs compat

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 2358 bytes --]

Franz Böhm wrote:
> Also all Atheros based systems with binary drivers from Atheros itself
> or SDK's from third party vendors only work with particular (quite old)
> kernel versions. Perhaps you are able to build with newer kernel but
> it's much more difficult to get support from the chip manufacturer this
> way.
> 
> Using open source drivers instead is not always an opinion because it's
> very hard to comply with radio regulations and get your product
> certified. This is why I think it's somehow also important for BATMAN to
> support older kernels.

Yes, commercial support is a big problem. The atheros driver (targeted for 
2.6.15) can be ported to with reasonable effort to a kernel supported by 
batman-adv. But as you stated above the upstream support maybe will be gone 
afterward.

...do we really trust devices running really old kernels? There must be a well 
educated and hard working support team behind that kernel to keep it working. 
Not that bugs come over time, but bugs are found over time and must be fixed 
or otherwise some people will have more fun than you with these "features".

So we have different possibilities, but the most important one should be the 
requirements of the actual developers. Both Marek and Simon use batman-adv on 
different kernels and have special requirements on kernel versions they must 
support.

We can use openwrt as extra information what should be supported. Currently I 
see kernels from 2.6.25-2.6.34.

To come back to the security consideration: Usually the kernel folks support 
the last kernel only with security fixes and other bug fixes. This isn't 
sufficient for people which run a specific kernel a long time (distributions 
for example). As result of these requirements a specific kernel version is 
maintained longer than others [1] ("LTS" if you want to name it in ubuntu-
style). So the lowest kernel version number here is 2.6.27

I am not sure if we really want to check kernels of specific desktop/server 
distributions because they aren't our real target audience and kernels of 
distributions with a really long support time tends to have more in common 
with every other kernel but not with the vanilla kernel with the same version 
number.

Best regards,
	Sven

[1] http://www.kroah.com/log/linux/stable-status-01-2010.html

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] sysfs compat

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Hi,

personally i need 2.6.24, and don't care much about 2.6.20, so i would not bother
to drop support for this special version - We can however integrate patches, i'm
sure someone will look at it if it is a trivial conversion.

Marek, i've tested your patches with all major kernel releases from 2.6.20 to 
2.6.33. What i have seen is:

 * 2.6.20 fails for various reasons
 * 2.6.23 and 2.6.24 show some warnings
 * all other kernel versions are fine

The warnings for 23 and 24 can be fixed by moving the *_read() defines from 
"< 2.6.25" to "< 2.6.23". If you integrate this modification into your patch, 
you will gain my blessing and my sign-off. :)

best regards,
	Simon

On Mon, May 03, 2010 at 08:28:08AM +0800, Marek Lindner wrote:
> 
> Hi,
> 
> the current trunk contains some code which breaks our backward compatibility, 
> especially the sysfs API seem to be troublesome. I made 2 patches that address 
> the issue on my 2.6.21 test system. It would be nice if you could test them on 
> your system as well. I'd be particularly interested in kernels older than 
> 2.6.25. Does someone have a 2.6.20 system ?
> 
> At some point we have to start thinking about how many versions we want to 
> support. Each new kernel brings more changes which need to be dealt with. 
> Right now, the required effort is still at a sustainable level but the gap is 
> growing. On one hand it is a nice playground to expand our knowledge about 
> macros and demonstrate what nasty things you can do (see the second patch as 
> an example).  ;-)
> On the other hand it always requires a serious amount of time and effort. It 
> only makes sense if at least some people are using it. Opinions ?
> 
> Regards,
> Marek
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] sysfs compat

[Marek Lindner]

Hi,

> Marek, i've tested your patches with all major kernel releases from 2.6.20
> to  2.6.33. What i have seen is:
> 
>  * 2.6.20 fails for various reasons
>  * 2.6.23 and 2.6.24 show some warnings
>  * all other kernel versions are fine
> 
> The warnings for 23 and 24 can be fixed by moving the *_read() defines
> from  "< 2.6.25" to "< 2.6.23". If you integrate this modification into
> your patch, you will gain my blessing and my sign-off. :)


thanks for testing. I followed your suggestion before pushing the patches. :)

Since 2.6.20 does not work at this point I removed it from the list of 
supported kernel versions. Unfortunately, many embedded system vendors do not 
bother to bring their drivers upstream and instead, publish "code blobs" 
limited to an old linux version. So, it makes sense for us to offer support for 
older versions as well. We could remove old versions if the effort is getting 
too high (as we just did with 2.6.20).

@Franz: I know you are stuck at 2.6.14 or something similar with your Atheros 
system but I don't think it is feasible for us to "go down" that far (unless 
you find a way). It might be easier to try pushing your Atheros beyong the 
current 2.6.21 minimum.

Regards,
Marek

Re: [B.A.T.M.A.N.] sysfs compat

[Franz Böhm]

Of course you are right Marek. I don't want to stay with 2.6.14 and will 
switch to a kernel >2.6.21 asap.

I wanted to say that it's suddenly more a general problem using chip 
supplier or third party SDK's for embedded systems and being constrained 
to use quite old kernels.

Regards,
Franz


Marek Lindner schrieb:
> Hi,
> 
>> Marek, i've tested your patches with all major kernel releases from 2.6.20
>> to  2.6.33. What i have seen is:
>>
>>  * 2.6.20 fails for various reasons
>>  * 2.6.23 and 2.6.24 show some warnings
>>  * all other kernel versions are fine
>>
>> The warnings for 23 and 24 can be fixed by moving the *_read() defines
>> from  "< 2.6.25" to "< 2.6.23". If you integrate this modification into
>> your patch, you will gain my blessing and my sign-off. :)
> 
> 
> thanks for testing. I followed your suggestion before pushing the patches. :)
> 
> Since 2.6.20 does not work at this point I removed it from the list of 
> supported kernel versions. Unfortunately, many embedded system vendors do not 
> bother to bring their drivers upstream and instead, publish "code blobs" 
> limited to an old linux version. So, it makes sense for us to offer support for 
> older versions as well. We could remove old versions if the effort is getting 
> too high (as we just did with 2.6.20).
> 
> @Franz: I know you are stuck at 2.6.14 or something similar with your Atheros 
> system but I don't think it is feasible for us to "go down" that far (unless 
> you find a way). It might be easier to try pushing your Atheros beyong the 
> current 2.6.21 minimum.
> 
> Regards,
> Marek
> 

Re: [B.A.T.M.A.N.] sysfs compat

[elektra]

Hello Franz -

as a comment: Whenever I used drivers from a chip manufacturer so far I had a 
miserable experience. Basic features and most common applications usually 
work, but thats it. Drivers are usually buggy and unmaintained. Particularly 
ad-hoc mode support usually is theoretically there but practically broken. I 
know of no proprietary vendor driver that works properly.

The fact that you are usually bound to a very old version of Linux is telling. 
I only use / promote chips with decent open-source support. OpenWrt is 
awesome.

Cheers,
Elektra

Re: [B.A.T.M.A.N.] sysfs compat

[Franz Böhm]

Hi Elektra,

the problem lies somewhere else like mentioned earlier:

" ... Using open source drivers instead is not always an opinion because 
it's very hard to comply with radio regulations and get your product 
certified. ..."

You are right regarding the quality of binary drivers from chip 
suppliers. But if you pay lots of money for an SDK with outdated kernel 
:-) and with binary drivers included, the supplier should give you 
support for every problem their binary drivers create.

For example you will never ever get 100% source from Sigma Designs to 
debug their binary stuff because they mostly fear loosing their 
intellectual property.

Of course it's a different point of view if you are working on a 
commercial product or on a software project for some sort of community. 
In the first way you have to get your product certified. In the second 
way you want to prevent using binary drivers.

Regards,
Franz


elektra schrieb:
> Hello Franz -
> 
> as a comment: Whenever I used drivers from a chip manufacturer so far I had a 
> miserable experience. Basic features and most common applications usually 
> work, but thats it. Drivers are usually buggy and unmaintained. Particularly 
> ad-hoc mode support usually is theoretically there but practically broken. I 
> know of no proprietary vendor driver that works properly.
> 
> The fact that you are usually bound to a very old version of Linux is telling. 
> I only use / promote chips with decent open-source support. OpenWrt is 
> awesome.
> 
> Cheers,
> Elektra
> 

Re: [B.A.T.M.A.N.] sysfs compat

[elektra]

Hi Franz -

there are certified devices out there, running OpenWrt / open-source drivers. 
May I ask, what particular regulator issues you have in mind, that a open-
source driver can not comply with? Read: Are you sure you don't get the 
regulators blessing for your product with a open-source driver?

Besides: Do you know this song by Eric Idle, regarding the FCC?

http://www.youtube.com/watch?v=F4ajZ-5kTXk

A few memes:

Any product can be tampered with.

In many certified devices you can simply switch the reg domain. Then choose 
Japan, for example. Now you can transmit on channel 14 in the 2.4GHz range. 
Not so legal anywhere outside of Nippon. 

The old Broadcom chipset / proprietary driver can be configured to transmit at 
250mW with the proprietary closed source driver. Hence you can transmit at 
~25dbm EIRP (with the stock antennas), far beyond the ETSI regulations of 
20dBm EIRP.

Any device with a external antenna connector can be used together with a high-
gain antenna. Again you get far beyond the legal limits.

Cheers,
Elektra

Re: [B.A.T.M.A.N.] sysfs compat

[Franz Böhm]

Hi Elektra,

as far as I know there is no 100% open source driver for Atheros AR9280 
that is compliant with ETSI regulations. Please correct me if I am wrong.

Interestingly there is also no 5GHz support in OpenWrt 10.03 because of 
regulatory issues.

Sorry Elektra, but it's irrelevant what you can do with all those 
wireless stuff around. You can also use a kitchen knife as a weapon. 
It's only a matter of being compliant with laws if you want to get your 
product on the market.

For example you need reverse polarity connectors (RP-SMA, ...) to make 
it harder for people to attach some self constructed antennas. This is 
simply a FCC regulation every certified product has to obey.

As I already said, this is only applicable for commercial products. But 
also OpenWrt seems to be worried about regulations.

This discussion is off topic and also not BATMAN relevant. So I would 
say we shouldn't go further into detail about regulation good, bad, yes 
or no.

Regards,
Franz


elektra schrieb:
> Hi Franz -
> 
> there are certified devices out there, running OpenWrt / open-source drivers. 
> May I ask, what particular regulator issues you have in mind, that a open-
> source driver can not comply with? Read: Are you sure you don't get the 
> regulators blessing for your product with a open-source driver?
> 
> Besides: Do you know this song by Eric Idle, regarding the FCC?
> 
> http://www.youtube.com/watch?v=F4ajZ-5kTXk
> 
> A few memes:
> 
> Any product can be tampered with.
> 
> In many certified devices you can simply switch the reg domain. Then choose 
> Japan, for example. Now you can transmit on channel 14 in the 2.4GHz range. 
> Not so legal anywhere outside of Nippon. 
> 
> The old Broadcom chipset / proprietary driver can be configured to transmit at 
> 250mW with the proprietary closed source driver. Hence you can transmit at 
> ~25dbm EIRP (with the stock antennas), far beyond the ETSI regulations of 
> 20dBm EIRP.
> 
> Any device with a external antenna connector can be used together with a high-
> gain antenna. Again you get far beyond the legal limits.
> 
> Cheers,
> Elektra
> 

Re: [B.A.T.M.A.N.] sysfs compat

[RHS Linux User]

Hi All,

   I used to run one of "THE" compliance labs....

   Who really cares about compliance ??!!  The real question is does it
work, does it *REALLY* work !!  Can you reset it reliably? Can you debug
it?

   I too ONLY consider open source as even worth spending my time
with.

   The original Atheros driver for MITs roofnet was 50% of the size
of their "regular" OEM driver. And it worked pretty well !! Pretty
telling. AFAIK the MIT sources were never leaked to the web?

   I keep thinking someone *SHOULD* do a WIFI interface to ethernet with
an open radio and and open VHDL fpga design. That way we could all see
what was *REALLY* happending with the RF !  MUCH better than ANY analyser
out there.

   And it would just get better and become more reliable over time.

   Hurrah for open source!

   Wiz


On Tue, 4 May 2010, elektra wrote:

> Hi Franz -
> 
> there are certified devices out there, running OpenWrt / open-source drivers. 
> May I ask, what particular regulator issues you have in mind, that a open-
> source driver can not comply with? Read: Are you sure you don't get the 
> regulators blessing for your product with a open-source driver?
> 
> Besides: Do you know this song by Eric Idle, regarding the FCC?
> 
> http://www.youtube.com/watch?v=F4ajZ-5kTXk
> 
> A few memes:
> 
> Any product can be tampered with.
> 
> In many certified devices you can simply switch the reg domain. Then choose 
> Japan, for example. Now you can transmit on channel 14 in the 2.4GHz range. 
> Not so legal anywhere outside of Nippon. 
> 
> The old Broadcom chipset / proprietary driver can be configured to transmit at 
> 250mW with the proprietary closed source driver. Hence you can transmit at 
> ~25dbm EIRP (with the stock antennas), far beyond the ETSI regulations of 
> 20dBm EIRP.
> 
> Any device with a external antenna connector can be used together with a high-
> gain antenna. Again you get far beyond the legal limits.
> 
> Cheers,
> Elektra
>