Hi,
here are patches targetted for 2.6.36. All patches needed for that patchset are already part of your staging-next tree.
All patches are cleanup patches and no new feature is added.
thanks, Sven
Antonio Quartulli (1): Staging: batman-adv: Convert names from Java to C style
Linus Lüssing (1): Staging: batman-adv: Avoid rounding issues for local hna timeout
Marek Lindner (4): Staging: batman-adv: replace manual calculation by msecs_to_jiffies() for better readability Staging: batman-adv: Add sysfs abi documentation about bonding Staging: batman-adv: adapting source version to revised versioning scheme Staging: batman-adv: fix early debugfs deinitialization
Simon Wunderlich (1): Staging: batman-adv: Lower resolution for timeouts
Sven Eckelmann (1): Staging: batman-adv: Add include guards to all header files
drivers/staging/batman-adv/aggregation.h | 5 +++++ drivers/staging/batman-adv/bat_debugfs.h | 6 +++--- drivers/staging/batman-adv/bat_sysfs.h | 6 +++--- drivers/staging/batman-adv/bitarray.h | 4 ++++ drivers/staging/batman-adv/hard-interface.h | 5 +++++ drivers/staging/batman-adv/hash.h | 8 +++++--- drivers/staging/batman-adv/icmp_socket.h | 5 +++++ drivers/staging/batman-adv/main.c | 4 ++-- drivers/staging/batman-adv/main.h | 13 +++++++++---- drivers/staging/batman-adv/originator.c | 6 ++---- drivers/staging/batman-adv/originator.h | 5 +++++ drivers/staging/batman-adv/packet.h | 5 +++++ drivers/staging/batman-adv/ring_buffer.h | 5 +++++ drivers/staging/batman-adv/routing.c | 6 +++--- drivers/staging/batman-adv/routing.h | 5 +++++ drivers/staging/batman-adv/send.c | 14 +++++++------- drivers/staging/batman-adv/send.h | 5 +++++ drivers/staging/batman-adv/soft-interface.c | 6 +++--- drivers/staging/batman-adv/soft-interface.h | 7 ++++++- drivers/staging/batman-adv/sysfs-class-net-mesh | 8 ++++++++ drivers/staging/batman-adv/translation-table.c | 3 +-- drivers/staging/batman-adv/translation-table.h | 5 +++++ drivers/staging/batman-adv/types.h | 6 +++--- drivers/staging/batman-adv/vis.c | 14 +++++++------- drivers/staging/batman-adv/vis.h | 7 ++++++- 25 files changed, 117 insertions(+), 46 deletions(-)
From: Antonio Quartulli ordex@ritirata.org
Useless but meaningfull patch that converts JavaStyle names into c_style
Signed-off-by: Antonio Quartulli ordex@ritirata.org Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/main.c | 2 +- drivers/staging/batman-adv/main.h | 2 +- drivers/staging/batman-adv/routing.c | 6 +++--- drivers/staging/batman-adv/send.c | 6 +++--- drivers/staging/batman-adv/soft-interface.c | 6 +++--- drivers/staging/batman-adv/soft-interface.h | 2 +- drivers/staging/batman-adv/vis.c | 12 ++++++------ 7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/batman-adv/main.c b/drivers/staging/batman-adv/main.c index 72fccb1..ae88806 100644 --- a/drivers/staging/batman-adv/main.c +++ b/drivers/staging/batman-adv/main.c @@ -49,7 +49,7 @@ int16_t num_hna;
struct net_device *soft_device;
-unsigned char broadcastAddr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}; +unsigned char broadcast_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}; atomic_t module_state;
static struct packet_type batman_adv_packet_type __read_mostly = { diff --git a/drivers/staging/batman-adv/main.h b/drivers/staging/batman-adv/main.h index fe5ee51..ab4c9e7 100644 --- a/drivers/staging/batman-adv/main.h +++ b/drivers/staging/batman-adv/main.h @@ -148,7 +148,7 @@ extern int16_t num_hna;
extern struct net_device *soft_device;
-extern unsigned char broadcastAddr[]; +extern unsigned char broadcast_addr[]; extern atomic_t module_state; extern struct workqueue_struct *bat_event_workqueue;
diff --git a/drivers/staging/batman-adv/routing.c b/drivers/staging/batman-adv/routing.c index acd8f74..127cfbf 100644 --- a/drivers/staging/batman-adv/routing.c +++ b/drivers/staging/batman-adv/routing.c @@ -120,7 +120,7 @@ void update_routes(struct orig_node *orig_node, update_HNA(orig_node, hna_buff, hna_buff_len); }
-static int isBidirectionalNeigh(struct orig_node *orig_node, +static int is_bidirectional_neigh(struct orig_node *orig_node, struct orig_node *orig_neigh_node, struct batman_packet *batman_packet, struct batman_if *if_incoming) @@ -564,7 +564,7 @@ void receive_bat_packet(struct ethhdr *ethhdr, batman_if->net_dev->dev_addr)) is_my_oldorig = 1;
- if (compare_orig(ethhdr->h_source, broadcastAddr)) + if (compare_orig(ethhdr->h_source, broadcast_addr)) is_broadcast = 1; }
@@ -674,7 +674,7 @@ void receive_bat_packet(struct ethhdr *ethhdr, return; }
- is_bidirectional = isBidirectionalNeigh(orig_node, orig_neigh_node, + is_bidirectional = is_bidirectional_neigh(orig_node, orig_neigh_node, batman_packet, if_incoming);
/* update ranking if it is not a duplicate or has the same diff --git a/drivers/staging/batman-adv/send.c b/drivers/staging/batman-adv/send.c index e61a62c..8059adb 100644 --- a/drivers/staging/batman-adv/send.c +++ b/drivers/staging/batman-adv/send.c @@ -174,7 +174,7 @@ static void send_packet_to_if(struct forw_packet *forw_packet,
send_raw_packet(forw_packet->packet_buff, forw_packet->packet_len, - batman_if, broadcastAddr); + batman_if, broadcast_addr); }
/* send a batman packet */ @@ -211,7 +211,7 @@ static void send_packet(struct forw_packet *forw_packet) send_raw_packet(forw_packet->packet_buff, forw_packet->packet_len, forw_packet->if_incoming, - broadcastAddr); + broadcast_addr); return; }
@@ -464,7 +464,7 @@ static void send_outstanding_bcast_packet(struct work_struct *work) skb1 = skb_copy(forw_packet->skb, GFP_ATOMIC); if (skb1) send_skb_packet(skb1, - batman_if, broadcastAddr); + batman_if, broadcast_addr); } rcu_read_unlock();
diff --git a/drivers/staging/batman-adv/soft-interface.c b/drivers/staging/batman-adv/soft-interface.c index ef7860d..2ea97de 100644 --- a/drivers/staging/batman-adv/soft-interface.c +++ b/drivers/staging/batman-adv/soft-interface.c @@ -36,7 +36,7 @@ static uint32_t bcast_seqno = 1; /* give own bcast messages seq numbers to avoid static int32_t skb_packets; static int32_t skb_bad_packets;
-unsigned char mainIfAddr[ETH_ALEN]; +unsigned char main_if_addr[ETH_ALEN]; static int bat_get_settings(struct net_device *dev, struct ethtool_cmd *cmd); static void bat_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info); @@ -58,7 +58,7 @@ static const struct ethtool_ops bat_ethtool_ops = {
void set_main_if_addr(uint8_t *addr) { - memcpy(mainIfAddr, addr, ETH_ALEN); + memcpy(main_if_addr, addr, ETH_ALEN); }
int my_skb_push(struct sk_buff *skb, unsigned int len) @@ -164,7 +164,7 @@ int interface_tx(struct sk_buff *skb, struct net_device *dev)
/* hw address of first interface is the orig mac because only * this mac is known throughout the mesh */ - memcpy(bcast_packet->orig, mainIfAddr, ETH_ALEN); + memcpy(bcast_packet->orig, main_if_addr, ETH_ALEN);
/* set broadcast sequence number */ bcast_packet->seqno = htonl(bcast_seqno); diff --git a/drivers/staging/batman-adv/soft-interface.h b/drivers/staging/batman-adv/soft-interface.h index 3852c57..0847e42 100644 --- a/drivers/staging/batman-adv/soft-interface.h +++ b/drivers/staging/batman-adv/soft-interface.h @@ -25,4 +25,4 @@ int interface_tx(struct sk_buff *skb, struct net_device *dev); void interface_rx(struct sk_buff *skb, int hdr_size); int my_skb_push(struct sk_buff *skb, unsigned int len);
-extern unsigned char mainIfAddr[]; +extern unsigned char main_if_addr[]; diff --git a/drivers/staging/batman-adv/vis.c b/drivers/staging/batman-adv/vis.c index d9ab981..ed2c1f9 100644 --- a/drivers/staging/batman-adv/vis.c +++ b/drivers/staging/batman-adv/vis.c @@ -390,7 +390,7 @@ static struct vis_info *add_packet(struct vis_packet *vis_packet,
/* Make it a broadcast packet, if required */ if (make_broadcast) - memcpy(info->packet.target_orig, broadcastAddr, ETH_ALEN); + memcpy(info->packet.target_orig, broadcast_addr, ETH_ALEN);
/* repair if entries is longer than packet. */ if (info->packet.entries * sizeof(struct vis_info_entry) > vis_info_len) @@ -524,7 +524,7 @@ static int generate_vis_packet(struct bat_priv *bat_priv) info->packet.vis_type = atomic_read(&bat_priv->vis_mode);
spin_lock_irqsave(&orig_hash_lock, flags); - memcpy(info->packet.target_orig, broadcastAddr, ETH_ALEN); + memcpy(info->packet.target_orig, broadcast_addr, ETH_ALEN); info->packet.ttl = TTL; info->packet.seqno = htonl(ntohl(info->packet.seqno) + 1); info->packet.entries = 0; @@ -641,7 +641,7 @@ static void broadcast_vis_packet(struct vis_info *info, int packet_length)
} spin_unlock_irqrestore(&orig_hash_lock, flags); - memcpy(info->packet.target_orig, broadcastAddr, ETH_ALEN); + memcpy(info->packet.target_orig, broadcast_addr, ETH_ALEN); }
static void unicast_vis_packet(struct vis_info *info, int packet_length) @@ -682,7 +682,7 @@ static void send_vis_packet(struct vis_info *info) return; }
- memcpy(info->packet.sender_orig, mainIfAddr, ETH_ALEN); + memcpy(info->packet.sender_orig, main_if_addr, ETH_ALEN); info->packet.ttl--;
packet_length = sizeof(struct vis_packet) + @@ -763,8 +763,8 @@ int vis_init(void)
INIT_LIST_HEAD(&send_list);
- memcpy(my_vis_info->packet.vis_orig, mainIfAddr, ETH_ALEN); - memcpy(my_vis_info->packet.sender_orig, mainIfAddr, ETH_ALEN); + memcpy(my_vis_info->packet.vis_orig, main_if_addr, ETH_ALEN); + memcpy(my_vis_info->packet.sender_orig, main_if_addr, ETH_ALEN);
if (hash_add(vis_hash, my_vis_info) < 0) { printk(KERN_ERR
From: Linus Lüssing linus.luessing@web.de
With the current default values, this patch is not critical, as LOCAL_HNA_TIMEOUT is a multiple of 1000 anyway. However, if someone would like to change this #define, the person could have some unexpected rounding issues. Therefore doing the multiplication before the division now.
Signed-off-by: Linus Lüssing linus.luessing@web.de Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/translation-table.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/batman-adv/translation-table.c b/drivers/staging/batman-adv/translation-table.c index 9fd32a9..fdd902d 100644 --- a/drivers/staging/batman-adv/translation-table.c +++ b/drivers/staging/batman-adv/translation-table.c @@ -258,7 +258,7 @@ static void hna_local_purge(struct work_struct *work) hna_local_entry = hashit.bucket->data;
timeout = hna_local_entry->last_seen + - ((LOCAL_HNA_TIMEOUT / 1000) * HZ); + ((LOCAL_HNA_TIMEOUT * HZ) / 1000); if ((!hna_local_entry->never_purge) && time_after(jiffies, timeout)) hna_local_del(hna_local_entry, "address timed out");
From: Simon Wunderlich siwu@hrz.tu-chemnitz.de
It is enough for our timeouts to keep them in seconds instead of miliseconds. With a too high resolution, we might even risk an integer overflow, so this patch should make things more safe.
Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/main.h | 4 ++-- drivers/staging/batman-adv/originator.c | 6 ++---- drivers/staging/batman-adv/translation-table.c | 3 +-- drivers/staging/batman-adv/vis.c | 2 +- drivers/staging/batman-adv/vis.h | 2 +- 5 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/batman-adv/main.h b/drivers/staging/batman-adv/main.h index ab4c9e7..49aaec5 100644 --- a/drivers/staging/batman-adv/main.h +++ b/drivers/staging/batman-adv/main.h @@ -36,10 +36,10 @@ #define JITTER 20 #define TTL 50 /* Time To Live of broadcast messages */
-#define PURGE_TIMEOUT 200000 /* purge originators after time in ms if no +#define PURGE_TIMEOUT 200 /* purge originators after time in seconds if no * valid packet comes in -> TODO: check * influence on TQ_LOCAL_WINDOW_SIZE */ -#define LOCAL_HNA_TIMEOUT 3600000 +#define LOCAL_HNA_TIMEOUT 3600 /* in seconds */
#define TQ_LOCAL_WINDOW_SIZE 64 /* sliding packet range of received originator * messages in squence numbers (should be a diff --git a/drivers/staging/batman-adv/originator.c b/drivers/staging/batman-adv/originator.c index 195c1ee..26bbf2d 100644 --- a/drivers/staging/batman-adv/originator.c +++ b/drivers/staging/batman-adv/originator.c @@ -193,8 +193,7 @@ static bool purge_orig_neighbors(struct orig_node *orig_node, neigh_node = list_entry(list_pos, struct neigh_node, list);
if ((time_after(jiffies, - (neigh_node->last_valid + - ((PURGE_TIMEOUT * HZ) / 1000)))) || + neigh_node->last_valid + PURGE_TIMEOUT * HZ)) || (neigh_node->if_incoming->if_status == IF_TO_BE_REMOVED)) {
@@ -231,8 +230,7 @@ static bool purge_orig_node(struct orig_node *orig_node) struct neigh_node *best_neigh_node;
if (time_after(jiffies, - (orig_node->last_valid + - ((2 * PURGE_TIMEOUT * HZ) / 1000)))) { + orig_node->last_valid + 2 * PURGE_TIMEOUT * HZ)) {
bat_dbg(DBG_BATMAN, "Originator timeout: originator %pM, last_valid %lu\n", diff --git a/drivers/staging/batman-adv/translation-table.c b/drivers/staging/batman-adv/translation-table.c index fdd902d..9e3c845 100644 --- a/drivers/staging/batman-adv/translation-table.c +++ b/drivers/staging/batman-adv/translation-table.c @@ -257,8 +257,7 @@ static void hna_local_purge(struct work_struct *work) while (hash_iterate(hna_local_hash, &hashit)) { hna_local_entry = hashit.bucket->data;
- timeout = hna_local_entry->last_seen + - ((LOCAL_HNA_TIMEOUT * HZ) / 1000); + timeout = hna_local_entry->last_seen + LOCAL_HNA_TIMEOUT * HZ; if ((!hna_local_entry->never_purge) && time_after(jiffies, timeout)) hna_local_del(hna_local_entry, "address timed out"); diff --git a/drivers/staging/batman-adv/vis.c b/drivers/staging/batman-adv/vis.c index ed2c1f9..ddee0f2 100644 --- a/drivers/staging/batman-adv/vis.c +++ b/drivers/staging/batman-adv/vis.c @@ -597,7 +597,7 @@ static void purge_vis_packets(void) if (info == my_vis_info) /* never purge own data. */ continue; if (time_after(jiffies, - info->first_seen + (VIS_TIMEOUT*HZ)/1000)) { + info->first_seen + VIS_TIMEOUT * HZ)) { hash_remove_bucket(vis_hash, &hashit); send_list_del(info); kref_put(&info->refcount, free_info); diff --git a/drivers/staging/batman-adv/vis.h b/drivers/staging/batman-adv/vis.h index 1cfadce..e152cd7 100644 --- a/drivers/staging/batman-adv/vis.h +++ b/drivers/staging/batman-adv/vis.h @@ -19,7 +19,7 @@ * */
-#define VIS_TIMEOUT 200000 +#define VIS_TIMEOUT 200 /* timeout of vis packets in seconds */
struct vis_info { unsigned long first_seen;
From: Marek Lindner lindner_marek@yahoo.de
Signed-off-by: Marek Lindner lindner_marek@yahoo.de Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/send.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/batman-adv/send.c b/drivers/staging/batman-adv/send.c index 8059adb..d4b92ef 100644 --- a/drivers/staging/batman-adv/send.c +++ b/drivers/staging/batman-adv/send.c @@ -42,15 +42,15 @@ static uint8_t hop_penalty(const uint8_t tq) /* when do we schedule our own packet to be sent */ static unsigned long own_send_time(struct bat_priv *bat_priv) { - return jiffies + - (((atomic_read(&bat_priv->orig_interval) - JITTER + - (random32() % 2*JITTER)) * HZ) / 1000); + return jiffies + msecs_to_jiffies( + atomic_read(&bat_priv->orig_interval) - + JITTER + (random32() % 2*JITTER)); }
/* when do we schedule a forwarded packet to be sent */ static unsigned long forward_send_time(struct bat_priv *bat_priv) { - return jiffies + (((random32() % (JITTER/2)) * HZ) / 1000); + return jiffies + msecs_to_jiffies(random32() % (JITTER/2)); }
/* send out an already prepared packet to the given address via the
From: Marek Lindner lindner_marek@yahoo.de
Signed-off-by: Marek Lindner lindner_marek@yahoo.de Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/sysfs-class-net-mesh | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/batman-adv/sysfs-class-net-mesh b/drivers/staging/batman-adv/sysfs-class-net-mesh index c75a87b..5aa1912 100644 --- a/drivers/staging/batman-adv/sysfs-class-net-mesh +++ b/drivers/staging/batman-adv/sysfs-class-net-mesh @@ -6,6 +6,14 @@ Description: Indicates whether the batman protocol messages of the mesh <mesh_iface> shall be aggregated or not.
+What: /sys/class/net/<mesh_iface>/mesh/bonding +Date: June 2010 +Contact: Simon Wunderlich siwu@hrz.tu-chemnitz.de +Description: + Indicates whether the data traffic going through the + mesh will be sent using multiple interfaces at the + same time (if available). + What: /sys/class/net/<mesh_iface>/mesh/orig_interval Date: May 2010 Contact: Marek Lindner lindner_marek@yahoo.de
From: Marek Lindner lindner_marek@yahoo.de
The new versioning scheme looks like this: * the trunk will simply be named "devel" followed by a revision number * the upcoming release branch will be "maint" followed by a revision number * the releases will carry their respective names (e.g. 2010.0.0)
Signed-off-by: Marek Lindner lindner_marek@yahoo.de Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/main.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/batman-adv/main.h b/drivers/staging/batman-adv/main.h index 49aaec5..f6a1c04 100644 --- a/drivers/staging/batman-adv/main.h +++ b/drivers/staging/batman-adv/main.h @@ -27,7 +27,7 @@ #define DRIVER_DESC "B.A.T.M.A.N. advanced" #define DRIVER_DEVICE "batman-adv"
-#define SOURCE_VERSION "2010.0.0" +#define SOURCE_VERSION "maint"
/* B.A.T.M.A.N. parameters */
We include different header files indirectly to the same source file. This creates weird compiler errors from time to time. Include guards should prefend that functions/variables/... gets redefined by itself.
Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/aggregation.h | 5 +++++ drivers/staging/batman-adv/bat_debugfs.h | 6 +++--- drivers/staging/batman-adv/bat_sysfs.h | 6 +++--- drivers/staging/batman-adv/bitarray.h | 4 ++++ drivers/staging/batman-adv/hard-interface.h | 5 +++++ drivers/staging/batman-adv/hash.h | 8 +++++--- drivers/staging/batman-adv/icmp_socket.h | 5 +++++ drivers/staging/batman-adv/main.h | 5 +++++ drivers/staging/batman-adv/originator.h | 5 +++++ drivers/staging/batman-adv/packet.h | 5 +++++ drivers/staging/batman-adv/ring_buffer.h | 5 +++++ drivers/staging/batman-adv/routing.h | 5 +++++ drivers/staging/batman-adv/send.h | 5 +++++ drivers/staging/batman-adv/soft-interface.h | 5 +++++ drivers/staging/batman-adv/translation-table.h | 5 +++++ drivers/staging/batman-adv/types.h | 6 +++--- drivers/staging/batman-adv/vis.h | 5 +++++ 17 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/batman-adv/aggregation.h b/drivers/staging/batman-adv/aggregation.h index 84401ca..71a91b3 100644 --- a/drivers/staging/batman-adv/aggregation.h +++ b/drivers/staging/batman-adv/aggregation.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_AGGREGATION_H_ +#define _NET_BATMAN_ADV_AGGREGATION_H_ + #include "main.h"
/* is there another aggregated packet here? */ @@ -36,3 +39,5 @@ void add_bat_packet_to_list(struct bat_priv *bat_priv, unsigned long send_time); void receive_aggr_bat_packet(struct ethhdr *ethhdr, unsigned char *packet_buff, int packet_len, struct batman_if *if_incoming); + +#endif /* _NET_BATMAN_ADV_AGGREGATION_H_ */ diff --git a/drivers/staging/batman-adv/bat_debugfs.h b/drivers/staging/batman-adv/bat_debugfs.h index 5cdd332..72df532 100644 --- a/drivers/staging/batman-adv/bat_debugfs.h +++ b/drivers/staging/batman-adv/bat_debugfs.h @@ -20,8 +20,8 @@ */
-#ifndef BAT_DEBUGFS_H -#define BAT_DEBUGFS_H +#ifndef _NET_BATMAN_ADV_DEBUGFS_H_ +#define _NET_BATMAN_ADV_DEBUGFS_H_
#define DEBUGFS_BAT_SUBDIR "batman_adv"
@@ -30,4 +30,4 @@ void debugfs_destroy(void); int debugfs_add_meshif(struct net_device *dev); void debugfs_del_meshif(struct net_device *dev);
-#endif +#endif /* _NET_BATMAN_ADV_DEBUGFS_H_ */ diff --git a/drivers/staging/batman-adv/bat_sysfs.h b/drivers/staging/batman-adv/bat_sysfs.h index cb45a91..7f186c0 100644 --- a/drivers/staging/batman-adv/bat_sysfs.h +++ b/drivers/staging/batman-adv/bat_sysfs.h @@ -20,8 +20,8 @@ */
-#ifndef BAT_SYSFS_H -#define BAT_SYSFS_H +#ifndef _NET_BATMAN_ADV_SYSFS_H_ +#define _NET_BATMAN_ADV_SYSFS_H_
#define SYSFS_IF_MESH_SUBDIR "mesh" #define SYSFS_IF_BAT_SUBDIR "batman_adv" @@ -39,4 +39,4 @@ void sysfs_del_meshif(struct net_device *dev); int sysfs_add_hardif(struct kobject **hardif_obj, struct net_device *dev); void sysfs_del_hardif(struct kobject **hardif_obj);
-#endif +#endif /* _NET_BATMAN_ADV_SYSFS_H_ */ diff --git a/drivers/staging/batman-adv/bitarray.h b/drivers/staging/batman-adv/bitarray.h index dad13bf..01897d6 100644 --- a/drivers/staging/batman-adv/bitarray.h +++ b/drivers/staging/batman-adv/bitarray.h @@ -19,6 +19,8 @@ * */
+#ifndef _NET_BATMAN_ADV_BITARRAY_H_ +#define _NET_BATMAN_ADV_BITARRAY_H_
/* you should choose something big, if you don't want to waste cpu */ #define TYPE_OF_WORD unsigned long @@ -40,3 +42,5 @@ char bit_get_packet(TYPE_OF_WORD *seq_bits, int32_t seq_num_diff,
/* count the hamming weight, how many good packets did we receive? */ int bit_packet_count(TYPE_OF_WORD *seq_bits); + +#endif /* _NET_BATMAN_ADV_BITARRAY_H_ */ diff --git a/drivers/staging/batman-adv/hard-interface.h b/drivers/staging/batman-adv/hard-interface.h index 1e5fc3e..d5640b0 100644 --- a/drivers/staging/batman-adv/hard-interface.h +++ b/drivers/staging/batman-adv/hard-interface.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_HARD_INTERFACE_H_ +#define _NET_BATMAN_ADV_HARD_INTERFACE_H_ + #define IF_NOT_IN_USE 0 #define IF_TO_BE_REMOVED 1 #define IF_INACTIVE 2 @@ -38,3 +41,5 @@ int batman_skb_recv(struct sk_buff *skb, struct net_device *orig_dev); int hardif_min_mtu(void); void update_min_mtu(void); + +#endif /* _NET_BATMAN_ADV_HARD_INTERFACE_H_ */ diff --git a/drivers/staging/batman-adv/hash.h b/drivers/staging/batman-adv/hash.h index 0505595..c483e11 100644 --- a/drivers/staging/batman-adv/hash.h +++ b/drivers/staging/batman-adv/hash.h @@ -19,8 +19,9 @@ * */
-#ifndef _BATMAN_HASH_H -#define _BATMAN_HASH_H +#ifndef _NET_BATMAN_ADV_HASH_H_ +#define _NET_BATMAN_ADV_HASH_H_ + #define HASHIT(name) struct hash_it_t name = { \ .index = -1, .bucket = NULL, \ .prev_bucket = NULL, \ @@ -95,4 +96,5 @@ struct hashtable_t *hash_resize(struct hashtable_t *hash, int size); * the returned iterator to access the elements until hash_it_t returns NULL. */ struct hash_it_t *hash_iterate(struct hashtable_t *hash, struct hash_it_t *iter_in); -#endif + +#endif /* _NET_BATMAN_ADV_HASH_H_ */ diff --git a/drivers/staging/batman-adv/icmp_socket.h b/drivers/staging/batman-adv/icmp_socket.h index 2dc954a..bf9b348 100644 --- a/drivers/staging/batman-adv/icmp_socket.h +++ b/drivers/staging/batman-adv/icmp_socket.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_ICMP_SOCKET_H_ +#define _NET_BATMAN_ADV_ICMP_SOCKET_H_ + #include "types.h"
#define ICMP_SOCKET "socket" @@ -27,3 +30,5 @@ void bat_socket_init(void); int bat_socket_setup(struct bat_priv *bat_priv); void bat_socket_receive_packet(struct icmp_packet_rr *icmp_packet, size_t icmp_len); + +#endif /* _NET_BATMAN_ADV_ICMP_SOCKET_H_ */ diff --git a/drivers/staging/batman-adv/main.h b/drivers/staging/batman-adv/main.h index f6a1c04..e308673 100644 --- a/drivers/staging/batman-adv/main.h +++ b/drivers/staging/batman-adv/main.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_MAIN_H_ +#define _NET_BATMAN_ADV_MAIN_H_ + /* Kernel Programming */ #define LINUX
@@ -162,3 +165,5 @@ int choose_orig(void *data, int32_t size); int is_my_mac(uint8_t *addr); int is_bcast(uint8_t *addr); int is_mcast(uint8_t *addr); + +#endif /* _NET_BATMAN_ADV_MAIN_H_ */ diff --git a/drivers/staging/batman-adv/originator.h b/drivers/staging/batman-adv/originator.h index 6632538..e88411d 100644 --- a/drivers/staging/batman-adv/originator.h +++ b/drivers/staging/batman-adv/originator.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_ORIGINATOR_H_ +#define _NET_BATMAN_ADV_ORIGINATOR_H_ + int originator_init(void); void originator_free(void); void purge_orig(struct work_struct *work); @@ -29,3 +32,5 @@ create_neighbor(struct orig_node *orig_node, struct orig_node *orig_neigh_node, int orig_seq_print_text(struct seq_file *seq, void *offset); int orig_hash_add_if(struct batman_if *batman_if, int max_if_num); int orig_hash_del_if(struct batman_if *batman_if, int max_if_num); + +#endif /* _NET_BATMAN_ADV_ORIGINATOR_H_ */ diff --git a/drivers/staging/batman-adv/packet.h b/drivers/staging/batman-adv/packet.h index 8a04418..abb5e46 100644 --- a/drivers/staging/batman-adv/packet.h +++ b/drivers/staging/batman-adv/packet.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_PACKET_H_ +#define _NET_BATMAN_ADV_PACKET_H_ + #define ETH_P_BATMAN 0x4305 /* unofficial/not registered Ethertype */
#define BAT_PACKET 0x01 @@ -113,3 +116,5 @@ struct vis_packet { uint8_t target_orig[6]; /* who should receive this packet */ uint8_t sender_orig[6]; /* who sent or rebroadcasted this packet */ } __attribute__((packed)); + +#endif /* _NET_BATMAN_ADV_PACKET_H_ */ diff --git a/drivers/staging/batman-adv/ring_buffer.h b/drivers/staging/batman-adv/ring_buffer.h index b8c9456..6b0cb9a 100644 --- a/drivers/staging/batman-adv/ring_buffer.h +++ b/drivers/staging/batman-adv/ring_buffer.h @@ -19,5 +19,10 @@ * */
+#ifndef _NET_BATMAN_ADV_RING_BUFFER_H_ +#define _NET_BATMAN_ADV_RING_BUFFER_H_ + void ring_buffer_set(uint8_t lq_recv[], uint8_t *lq_index, uint8_t value); uint8_t ring_buffer_avg(uint8_t lq_recv[]); + +#endif /* _NET_BATMAN_ADV_RING_BUFFER_H_ */ diff --git a/drivers/staging/batman-adv/routing.h b/drivers/staging/batman-adv/routing.h index 43387a2..3eac64e 100644 --- a/drivers/staging/batman-adv/routing.h +++ b/drivers/staging/batman-adv/routing.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_ROUTING_H_ +#define _NET_BATMAN_ADV_ROUTING_H_ + #include "types.h"
void slide_own_bcast_window(struct batman_if *batman_if); @@ -39,3 +42,5 @@ struct neigh_node *find_router(struct orig_node *orig_node, struct batman_if *recv_if); void update_bonding_candidates(struct bat_priv *bat_priv, struct orig_node *orig_node); + +#endif /* _NET_BATMAN_ADV_ROUTING_H_ */ diff --git a/drivers/staging/batman-adv/send.h b/drivers/staging/batman-adv/send.h index 0a0990d..b64c627 100644 --- a/drivers/staging/batman-adv/send.h +++ b/drivers/staging/batman-adv/send.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_SEND_H_ +#define _NET_BATMAN_ADV_SEND_H_ + #include "types.h"
int send_skb_packet(struct sk_buff *skb, @@ -35,3 +38,5 @@ void schedule_forward_packet(struct orig_node *orig_node, int add_bcast_packet_to_list(struct sk_buff *skb); void send_outstanding_bat_packet(struct work_struct *work); void purge_outstanding_packets(struct batman_if *batman_if); + +#endif /* _NET_BATMAN_ADV_SEND_H_ */ diff --git a/drivers/staging/batman-adv/soft-interface.h b/drivers/staging/batman-adv/soft-interface.h index 0847e42..6364854 100644 --- a/drivers/staging/batman-adv/soft-interface.h +++ b/drivers/staging/batman-adv/soft-interface.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_SOFT_INTERFACE_H_ +#define _NET_BATMAN_ADV_SOFT_INTERFACE_H_ + void set_main_if_addr(uint8_t *addr); void interface_setup(struct net_device *dev); int interface_tx(struct sk_buff *skb, struct net_device *dev); @@ -26,3 +29,5 @@ void interface_rx(struct sk_buff *skb, int hdr_size); int my_skb_push(struct sk_buff *skb, unsigned int len);
extern unsigned char main_if_addr[]; + +#endif /* _NET_BATMAN_ADV_SOFT_INTERFACE_H_ */ diff --git a/drivers/staging/batman-adv/translation-table.h b/drivers/staging/batman-adv/translation-table.h index 232208f..fa93e37 100644 --- a/drivers/staging/batman-adv/translation-table.h +++ b/drivers/staging/batman-adv/translation-table.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_TRANSLATION_TABLE_H_ +#define _NET_BATMAN_ADV_TRANSLATION_TABLE_H_ + #include "types.h"
int hna_local_init(void); @@ -38,3 +41,5 @@ struct orig_node *transtable_search(uint8_t *addr); extern spinlock_t hna_local_hash_lock; extern struct hashtable_t *hna_local_hash; extern atomic_t hna_local_changed; + +#endif /* _NET_BATMAN_ADV_TRANSLATION_TABLE_H_ */ diff --git a/drivers/staging/batman-adv/types.h b/drivers/staging/batman-adv/types.h index e1fc460..82602d0 100644 --- a/drivers/staging/batman-adv/types.h +++ b/drivers/staging/batman-adv/types.h @@ -23,8 +23,8 @@
-#ifndef TYPES_H -#define TYPES_H +#ifndef _NET_BATMAN_ADV_TYPES_H_ +#define _NET_BATMAN_ADV_TYPES_H_
#include "packet.h" #include "bitarray.h" @@ -172,4 +172,4 @@ struct if_list_entry { struct hlist_node list; };
-#endif +#endif /* _NET_BATMAN_ADV_TYPES_H_ */ diff --git a/drivers/staging/batman-adv/vis.h b/drivers/staging/batman-adv/vis.h index e152cd7..bb13bf1 100644 --- a/drivers/staging/batman-adv/vis.h +++ b/drivers/staging/batman-adv/vis.h @@ -19,6 +19,9 @@ * */
+#ifndef _NET_BATMAN_ADV_VIS_H_ +#define _NET_BATMAN_ADV_VIS_H_ + #define VIS_TIMEOUT 200 /* timeout of vis packets in seconds */
struct vis_info { @@ -53,3 +56,5 @@ void receive_client_update_packet(struct bat_priv *bat_priv, int vis_info_len); int vis_init(void); void vis_quit(void); + +#endif /* _NET_BATMAN_ADV_VIS_H_ */
From: Marek Lindner lindner_marek@yahoo.de
The debugfs files are initialized at load time only but would get deinitialized when the module changed in it deactivate (sleeping) state. As a consequence the debugfs files are not accessible anymore.
Signed-off-by: Marek Lindner lindner_marek@yahoo.de Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/batman-adv/main.c b/drivers/staging/batman-adv/main.c index ae88806..d7e2960 100644 --- a/drivers/staging/batman-adv/main.c +++ b/drivers/staging/batman-adv/main.c @@ -148,6 +148,7 @@ void cleanup_module(void) { deactivate_module();
+ debugfs_destroy(); unregister_netdevice_notifier(&hard_if_notifier); hardif_remove_interfaces();
@@ -212,7 +213,6 @@ void deactivate_module(void) hna_global_free();
synchronize_net(); - debugfs_destroy();
synchronize_rcu(); atomic_set(&module_state, MODULE_INACTIVE);
Hi,
Sven Eckelmann wrote:
here are patches targetted for 2.6.36. All patches needed for that patchset are already part of your staging-next tree.
All patches are cleanup patches and no new feature is added.
It seems that I forgot two smaller changes. Please add them to the list of patches I send to you today.
thanks, Sven
Sven Eckelmann (2): Staging: batman-adv: Allow to build it inside the kernel Staging: batman-adv: Remove dependency to PROCFS
drivers/staging/batman-adv/Kconfig | 2 +- drivers/staging/batman-adv/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
We must use the user supplied information about how the code should be compiled instead of always trying to build it as module.
Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/batman-adv/Makefile b/drivers/staging/batman-adv/Makefile index 654c4d2..e9817b5 100644 --- a/drivers/staging/batman-adv/Makefile +++ b/drivers/staging/batman-adv/Makefile @@ -18,5 +18,5 @@ # 02110-1301, USA #
-obj-m += batman-adv.o +obj-$(CONFIG_BATMAN_ADV) += batman-adv.o batman-adv-objs := main.o bat_debugfs.o bat_sysfs.o send.o routing.o soft-interface.o icmp_socket.o translation-table.o bitarray.o hash.o ring_buffer.o vis.o hard-interface.o aggregation.o originator.o
It is not need to depend on it as procfs support was removed during the transition to sysfs.
Signed-off-by: Sven Eckelmann sven.eckelmann@gmx.de --- drivers/staging/batman-adv/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/batman-adv/Kconfig b/drivers/staging/batman-adv/Kconfig index 1e7e0a8..8553f35 100644 --- a/drivers/staging/batman-adv/Kconfig +++ b/drivers/staging/batman-adv/Kconfig @@ -4,7 +4,7 @@
config BATMAN_ADV tristate "B.A.T.M.A.N. Advanced Meshing Protocol" - depends on PROC_FS && NET + depends on NET default n ---help---
Sven Eckelmann wrote:
Hi,
here are patches targetted for 2.6.36. All patches needed for that patchset are already part of your staging-next tree.
All patches are cleanup patches and no new feature is added.
thanks, Sven
Antonio Quartulli (1): Staging: batman-adv: Convert names from Java to C style
Linus Lüssing (1): Staging: batman-adv: Avoid rounding issues for local hna timeout
Marek Lindner (4): Staging: batman-adv: replace manual calculation by msecs_to_jiffies() for better readability Staging: batman-adv: Add sysfs abi documentation about bonding Staging: batman-adv: adapting source version to revised versioning scheme Staging: batman-adv: fix early debugfs deinitialization
Simon Wunderlich (1): Staging: batman-adv: Lower resolution for timeouts
Sven Eckelmann (3): Staging: batman-adv: Add include guards to all header files Staging: batman-adv: Allow to build it inside the kernel Staging: batman-adv: Remove dependency to PROCFS
Hi,
we send you those 10 patches 10 days ago and they don't seem to be merged in you staging-next tree. Linus has already released -rc4 after his vacation and it is unclear to me how long it takes until 2.6.35 is released and I am not allowed to submit patches for 2.6.36.
Do you think that I can still submit some patches to you for 2.6.36 or should I wait for 2.6.37?
The remaining patches are logging related. One patch moves the printk's to pr_(err|info|warning) and bat_(warning|info|error) makros. The second one moves the logging of routing related information from kernel ring buffer to a private ringbuffer in debugfs for each batX device.
Best regards, Sven
On Tue, Jul 06, 2010 at 03:04:07PM +0200, Sven Eckelmann wrote:
Sven Eckelmann wrote:
Hi,
here are patches targetted for 2.6.36. All patches needed for that patchset are already part of your staging-next tree.
All patches are cleanup patches and no new feature is added.
thanks, Sven
Antonio Quartulli (1): Staging: batman-adv: Convert names from Java to C style
Linus Lüssing (1): Staging: batman-adv: Avoid rounding issues for local hna timeout
Marek Lindner (4): Staging: batman-adv: replace manual calculation by msecs_to_jiffies() for better readability Staging: batman-adv: Add sysfs abi documentation about bonding Staging: batman-adv: adapting source version to revised versioning scheme Staging: batman-adv: fix early debugfs deinitialization
Simon Wunderlich (1): Staging: batman-adv: Lower resolution for timeouts
Sven Eckelmann (3): Staging: batman-adv: Add include guards to all header files Staging: batman-adv: Allow to build it inside the kernel Staging: batman-adv: Remove dependency to PROCFS
Hi,
we send you those 10 patches 10 days ago and they don't seem to be merged in you staging-next tree. Linus has already released -rc4 after his vacation and it is unclear to me how long it takes until 2.6.35 is released and I am not allowed to submit patches for 2.6.36.
It will be a few more weeks before .35 is released. Please note that I was working on 5 stable kernel updates last week plus an extended holliday weekend here and then there's my "real job" that I also have to do :)
I should get to your patches this week, don't worry, they will make it into .36 with no problem.
Do you think that I can still submit some patches to you for 2.6.36 or should I wait for 2.6.37?
Please send them on, if they go on top of these, I have no problems adding them.
thanks,
greg k-h
Greg KH wrote:
On Tue, Jul 06, 2010 at 03:04:07PM +0200, Sven Eckelmann wrote:
[...]
we send you those 10 patches 10 days ago and they don't seem to be merged in you staging-next tree. Linus has already released -rc4 after his vacation and it is unclear to me how long it takes until 2.6.35 is released and I am not allowed to submit patches for 2.6.36.
It will be a few more weeks before .35 is released. Please note that I was working on 5 stable kernel updates last week plus an extended holliday weekend here and then there's my "real job" that I also have to do :)
No, I didn't want to say that you are too slow. It is just hard to know how fast somebody can process something and if he has enough free time. If you would say that the weather is to good to do computer related work until 2.6.35 then it would be fine too. :)
I should get to your patches this week, don't worry, they will make it into .36 with no problem.
Do you think that I can still submit some patches to you for 2.6.36 or should I wait for 2.6.37?
Please send them on, if they go on top of these, I have no problems adding them.
Ok, I will send them later.
thanks, Sven
On Tue, Jul 06, 2010 at 05:36:12PM +0200, Sven Eckelmann wrote:
Greg KH wrote:
On Tue, Jul 06, 2010 at 03:04:07PM +0200, Sven Eckelmann wrote:
[...]
we send you those 10 patches 10 days ago and they don't seem to be merged in you staging-next tree. Linus has already released -rc4 after his vacation and it is unclear to me how long it takes until 2.6.35 is released and I am not allowed to submit patches for 2.6.36.
It will be a few more weeks before .35 is released. Please note that I was working on 5 stable kernel updates last week plus an extended holliday weekend here and then there's my "real job" that I also have to do :)
No, I didn't want to say that you are too slow. It is just hard to know how fast somebody can process something and if he has enough free time. If you would say that the weather is to good to do computer related work until 2.6.35 then it would be fine too. :)
The weather is pretty nice here, finally, maybe I should take a few weeks off :)
Don't worry about pinging me if I haven't responded to a patch, it doesn't bother me at all. In rare cases, I do miss them, so it can't hurt if you haven't gotten a response from me in a week.
thanks,
greg k-h
Greg KH wrote:
No, I didn't want to say that you are too slow. It is just hard to know how fast somebody can process something and if he has enough free time. If you would say that the weather is to good to do computer related work until 2.6.35 then it would be fine too. :)
The weather is pretty nice here, finally, maybe I should take a few weeks off :)
Don't worry about pinging me if I haven't responded to a patch, it doesn't bother me at all. In rare cases, I do miss them, so it can't hurt if you haven't gotten a response from me in a week.
Ok. Thanks a lot that you applied the patches so fast - even when the weather is so nice. :)
I have a small question about the topic "how to reduce the workload for you". We send the patch which should integrate batman-adv into net/ around two weeks ago to David S. Miller and the netdev@vger mailing list [1]. Some hours later Hagen Paul Pfeifer responded with some questions and different ideas - which we (batman developers and Henning Rogge from olsr) either answered and/or started to discuss them.
The problem is that the discussion stopped quite fast... actually there was only one mail from the netdev guys. This is quite irritating to me and the question arose whether we did something terrible wrong when we send the patch.
Maybe you could give us a small hint how to proceed further. If we should wait, poke around or maybe submit it in a completely different way. It is not about "getting it into net right away", but we would really like to get some responses so we can work on it to make it better.
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
thanks for the mentoring, Sven
[1] http://kerneltrap.org/mailarchive/linux-netdev/2010/6/28/6280066/thread
On Sat, Jul 10, 2010 at 01:07:56AM +0200, Sven Eckelmann wrote:
I have a small question about the topic "how to reduce the workload for you". We send the patch which should integrate batman-adv into net/ around two weeks ago to David S. Miller and the netdev@vger mailing list [1]. Some hours later Hagen Paul Pfeifer responded with some questions and different ideas - which we (batman developers and Henning Rogge from olsr) either answered and/or started to discuss them.
The problem is that the discussion stopped quite fast... actually there was only one mail from the netdev guys. This is quite irritating to me and the question arose whether we did something terrible wrong when we send the patch.
Nope, you all did fine.
Maybe you could give us a small hint how to proceed further. If we should wait, poke around or maybe submit it in a completely different way. It is not about "getting it into net right away", but we would really like to get some responses so we can work on it to make it better.
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
Try sending it again after a few more days with the comment, "everything is addressed in the last round of comments" somewhere in it.
Persistance is key :)
thanks,
greg k-h
Am 10.07.2010 01:07, Sven Eckelmann wrote:
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
Hagen Paul Pfeifer suggested in his message "a generalized architecture and a user space implementation of the protocol". What came to my mind when I read this again was a division of control plane and data/forwarding plane as known from traditional routing.
The whole forwarding stuff would stay in the kernel, using a simple routing table (for destination X, send to node Y on interface Z). The processing of routing messages (OGMs) and creation/update of the routing table based on the full originator table could be moved to a user space daemon. Relative to packets of regular data transmissions, routing messages are not sent and received that often such that processing them in user space should not hurt performance (very much), especially when compared to the original implementation of batman-adv in the user space.
Firstly, this approach would improve the architecture by separation of concerns, which makes it easier to understand, debug and maintain the code. Secondly, it would get easier to play with / improve the routing protocol and the metrics if the latter parts were implemented in user space. And maybe it is indeed possible to make the kernel part of the code agnostic to the used protocol implementation, which would lead to the generalized architecture that Hagen envisioned.
- Daniel
Daniel Seither wrote:
Am 10.07.2010 01:07, Sven Eckelmann wrote:
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
Hagen Paul Pfeifer suggested in his message "a generalized architecture and a user space implementation of the protocol". What came to my mind when I read this again was a division of control plane and data/forwarding plane as known from traditional routing.
The whole forwarding stuff would stay in the kernel, using a simple routing table (for destination X, send to node Y on interface Z).
This would go against the bonding/alternating functionality.
The processing of routing messages (OGMs) and creation/update of the routing table based on the full originator table could be moved to a user space daemon. Relative to packets of regular data transmissions, routing messages are not sent and received that often such that processing them in user space should not hurt performance (very much), especially when compared to the original implementation of batman-adv in the user space.
Firstly, this approach would improve the architecture by separation of concerns, which makes it easier to understand, debug and maintain the code. Secondly, it would get easier to play with / improve the routing protocol and the metrics if the latter parts were implemented in user space. And maybe it is indeed possible to make the kernel part of the code agnostic to the used protocol implementation, which would lead to the generalized architecture that Hagen envisioned.
Yes, that was what I wanted to discuss with him further. I tried to express my view about that topic using
But it does not work for things which must route ethernet frames as there does not exist such a framework and it is hard to create one which everyone will like and has enough information to provide all features they need.
Yes, I could imagine that this is an alternative route which could be elegant and successful, but the hard part is that we don't have anything that is really sufficient to be the general routing framework (see for example the unicast fragmentation which is added quite late.. or at least proposed quite late). There are even more things coming which are related to some parts of the multiple gateway handling (I never saw the implementation of the part I am referring to, but as far as I can follow the explanation the routing code must be adjusted again when we want to handle the non-dhcp/ndp multiple gateway for redundant paths to the non-mesh world situation).
Lets check what we may remove from kernelland when move everything to userspace (but don't forget, that the formular would be: sizeof(kernelpart) + sizeof(userpart) >> sizeof(current kernelland part)
* aggregation.* -> complete to userspace (but creates lot of jitter). * bat_debugfs.* -> nearly nothing moves to userspace * bat_sysfs.* -> around 60-70% stays inside the kernelland * bitarray.* -> stays inside the kernel * hard-interface.* -> stays inside the kernel * hash.* -> stays inside the kernel * icmp_socket.c -> stays inside the kernel * main.* -> stays inside the kernel * originator.* -> moves to userspace * ring_buffer.* -> moves to userspace * routing.* -> 80-90% stays inside the kernel * send.* -> 60% stays inside the kernel * soft-interface.* -> stays inside the kernel * translation-table.* -> stays inside the kernel * vis.* -> moves to userspace
This is a quite sketchy list and may misses some important points. Nevertheless we see that probably most of the code is just the routing/device stuff. So we could really think about splitting batman-adv in two parts: SEMF (simple ethernet mesh framework) and batman-adv (the part which does the discovery and route management). This doesn't mean that we really move to userspace, but that we have a better separation between those two parts inside the kernelland.
The first step would be to have more than one soft-interface.
This doesn't mean that this move is good (or bad), but it is a lot smaller step which can be discussed much more in detail without forgetting most of the important parts while discussing kernelland<->userspace interfaces.
Best regards, Sven
Am Samstag 10 Juli 2010, 10:40:52 schrieb Sven Eckelmann:
Daniel Seither wrote:
Am 10.07.2010 01:07, Sven Eckelmann wrote:
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
Hagen Paul Pfeifer suggested in his message "a generalized architecture and a user space implementation of the protocol". What came to my mind when I read this again was a division of control plane and data/forwarding plane as known from traditional routing.
The whole forwarding stuff would stay in the kernel, using a simple routing table (for destination X, send to node Y on interface Z).
This would go against the bonding/alternating functionality.
The bonding/alternating functionality could be part of the routing framework. I think there is something similar on IP layer routing in linux.
(a framework like this would make it very easy to port additional routing daemons for layer 2 routing, I already hear the 802.11s group crying because of competitors ;) ).
Henning Rogge
Henning Rogge wrote:
Am Samstag 10 Juli 2010, 10:40:52 schrieb Sven Eckelmann:
Daniel Seither wrote:
Am 10.07.2010 01:07, Sven Eckelmann wrote:
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
Hagen Paul Pfeifer suggested in his message "a generalized architecture and a user space implementation of the protocol". What came to my mind when I read this again was a division of control plane and data/forwarding plane as known from traditional routing.
The whole forwarding stuff would stay in the kernel, using a simple routing table (for destination X, send to node Y on interface Z).
This would go against the bonding/alternating functionality.
The bonding/alternating functionality could be part of the routing framework. I think there is something similar on IP layer routing in linux.
Yes, I know that it must be part of the routing framework - just the ruleset he explained is not sufficient for that task.
Kind regards, Sven
On 10.07.2010 10:40, Sven Eckelmann wrote:
Daniel Seither wrote:
On 10.07.2010 01:07, Sven Eckelmann wrote:
batman-adv works quite well for us - but that doesn't mean that it is good in context of the current kernel development. And who should know it better than the netdev guys.
Hagen Paul Pfeifer suggested in his message "a generalized architecture and a user space implementation of the protocol". What came to my mind when I read this again was a division of control plane and data/forwarding plane as known from traditional routing.
The whole forwarding stuff would stay in the kernel, using a simple routing table (for destination X, send to node Y on interface Z).
This would go against the bonding/alternating functionality.
Okay. I didn't really look into this functionality yet, but slightly extending the routing table by for example multiple next hops should do the job, right?
Lets check what we may remove from kernelland when move everything to userspace (but don't forget, that the formular would be: sizeof(kernelpart) + sizeof(userpart) >> sizeof(current kernelland part)
- aggregation.* -> complete to userspace (but creates lot of jitter).
- bat_debugfs.* -> nearly nothing moves to userspace
- bat_sysfs.* -> around 60-70% stays inside the kernelland
- bitarray.* -> stays inside the kernel
- hard-interface.* -> stays inside the kernel
- hash.* -> stays inside the kernel
- icmp_socket.c -> stays inside the kernel
- main.* -> stays inside the kernel
- originator.* -> moves to userspace
- ring_buffer.* -> moves to userspace
- routing.* -> 80-90% stays inside the kernel
- send.* -> 60% stays inside the kernel
- soft-interface.* -> stays inside the kernel
- translation-table.* -> stays inside the kernel
- vis.* -> moves to userspace
This is a quite sketchy list and may misses some important points. Nevertheless we see that probably most of the code is just the routing/device stuff. So we could really think about splitting batman-adv in two parts: SEMF (simple ethernet mesh framework) and batman-adv (the part which does the discovery and route management). This doesn't mean that we really move to userspace, but that we have a better separation between those two parts inside the kernelland.
I agree. Thanks for analyzing the existing code; I'm not that familiar with the gory details of batman-adv. Your suggestion should yield quite an improvement from the point of architecture.
- Daniel
b.a.t.m.a.n@lists.open-mesh.org
-
Daniel Seither -
Greg KH -
Henning Rogge -
Sven Eckelmann