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
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) \
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)
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
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?
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?
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
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
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
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
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
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
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
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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
elektra -
Franz Böhm -
Marek Lindner -
RHS Linux User -
Simon Wunderlich -
Sven Eckelmann