[B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (2)

[B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (2)

[Sven Eckelmann]

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(-)

[B.A.T.M.A.N.] [PATCH 1/8] Staging: batman-adv: Convert names from Java to C style

[Sven Eckelmann]

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
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 2/8] Staging: batman-adv: Avoid rounding issues for local hna timeout

[Sven Eckelmann]

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");
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 3/8] Staging: batman-adv: Lower resolution for timeouts

[Sven Eckelmann]

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;
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 4/8] Staging: batman-adv: replace manual calculation by msecs_to_jiffies() for better readability

[Sven Eckelmann]

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
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 5/8] Staging: batman-adv: Add sysfs abi documentation about bonding

[Sven Eckelmann]

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>
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 6/8] Staging: batman-adv: adapting source version to revised versioning scheme

[Sven Eckelmann]

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 */
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 7/8] Staging: batman-adv: Add include guards to all header files

[Sven Eckelmann]

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_ */
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 8/8] Staging: batman-adv: fix early debugfs deinitialization

[Sven Eckelmann]

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);
-- 
1.7.1

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Sven Eckelmann]

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

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(-)

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

[B.A.T.M.A.N.] [PATCH 1/2] Staging: batman-adv: Allow to build it inside the kernel

[Sven Eckelmann]

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
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 2/2] Staging: batman-adv: Remove dependency to PROCFS

[Sven Eckelmann]

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---
 
-- 
1.7.1

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Sven Eckelmann]

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

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

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Greg KH]

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Sven Eckelmann]

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

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

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Greg KH]

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Sven Eckelmann]

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

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

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Greg KH]

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Daniel Seither]

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Sven Eckelmann]

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

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

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Henning Rogge]

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

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

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Sven Eckelmann]

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

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

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

Re: [B.A.T.M.A.N.] Staging: batman-adv for 2.6.36 (3)

[Daniel Seither]

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