Hi Folks
This patch fixes a few typos and spelling errors.
Andrew
Index: send.c =================================================================== --- send.c (revision 1340) +++ send.c (working copy) @@ -143,7 +143,7 @@ batman_packet->tq = (batman_packet->tq * (TQ_MAX_VALUE - (2 * TQ_HOP_PENALTY))) / (TQ_MAX_VALUE);
debug_log(LOG_TYPE_BATMAN, - "%s %spacket (originator %s, seqno %d, TQ %d, TTL %d, IDF %s) on interface %s [%s]\n", + "%s %s packet (originator %s, seqno %d, TQ %d, TTL %d, IDF %s) on interface %s [%s]\n", (packet_num > 0 ? "Forwarding" : (forw_packet->own ? "Sending own" : "Forwarding")), (packet_num > 0 ? "aggregated " : ""), orig_str, ntohs(batman_packet->seqno), batman_packet->tq, batman_packet->ttl, Index: hard-interface.c =================================================================== --- hard-interface.c (revision 1340) +++ hard-interface.c (working copy) @@ -314,7 +314,7 @@ return;
/** - * wait for readers of the the interfaces, so update won't be a problem. + * wait for readers of the interfaces, so update won't be a problem. * this function is not time critical and can wait a bit .... */ synchronize_rcu(); Index: README =================================================================== --- README (revision 1340) +++ README (working copy) @@ -57,7 +57,7 @@
# cat /proc/net/batman-adv/vis
-This output can be processeed with graphviz-tools like dot. +This output can be processed with graphviz-tools like dot. The labels are similar/compatible to the ETX metric, 1.0 means perfect connection (100%), 2.0 means 50%, 3.0 means 33% and so on.
Index: aggregation.c =================================================================== --- aggregation.c (revision 1340) +++ aggregation.c (working copy) @@ -59,7 +59,7 @@ batman_packet = (struct batman_packet *)forw_packet_pos->packet_buff;
/** - * check aggregation compability + * check aggregation compatibility * -> direct link packets are broadcasted on their interface only * -> aggregate packet if the current packet is a "global" packet * as well as the base packet Index: routing.c =================================================================== --- routing.c (revision 1340) +++ routing.c (working copy) @@ -76,7 +76,7 @@ kfree(neigh_node); }
- hna_global_del_orig(orig_node, "originator timeouted"); + hna_global_del_orig(orig_node, "originator timed out");
kfree(orig_node->bcast_own); kfree(orig_node->bcast_own_sum); @@ -158,7 +158,7 @@ if ((orig_node->router != NULL) && (neigh_node == NULL)) {
debug_log(LOG_TYPE_ROUTES, "Deleting route towards: %s\n", orig_str); - hna_global_del_orig(orig_node, "originator timeouted"); + hna_global_del_orig(orig_node, "originator timed out");
/* route added */ } else if ((orig_node->router == NULL) && (neigh_node != NULL)) { @@ -247,7 +247,7 @@ /* * 1 - ((1-x) ** 3), normalized to TQ_MAX_VALUE * this does affect the nearly-symmetric links only a little, - * but punishes asymetric links more. + * but punishes asymmetric links more. * this will give a value between 0 and TQ_MAX_VALUE */ orig_neigh_node->tq_asym_penalty = TQ_MAX_VALUE - (TQ_MAX_VALUE * @@ -258,7 +258,7 @@
batman_packet->tq = ((batman_packet->tq * orig_neigh_node->tq_own * orig_neigh_node->tq_asym_penalty) / (TQ_MAX_VALUE * TQ_MAX_VALUE));
- debug_log(LOG_TYPE_BATMAN, "bidirectional: orig = %-15s neigh = %-15s => own_bcast = %2i, real recv = %2i, local tq: %3i, asym_penality: %3i, total tq: %3i \n", + debug_log(LOG_TYPE_BATMAN, "bidirectional: orig = %-15s neigh = %-15s => own_bcast = %2i, real recv = %2i, local tq: %3i, asym_penalty: %3i, total tq: %3i \n", orig_str, neigh_str, total_count, neigh_node->real_packet_count, orig_neigh_node->tq_own, orig_neigh_node->tq_asym_penalty, batman_packet->tq);
/* if link has the minimum required transmission quality consider it bidirectional */ @@ -451,9 +451,9 @@ if (orig_neigh_node == NULL) return;
- /* drop packet if sender is not a direct neighbor and if we no route towards it */ + /* drop packet if sender is not a direct neighbor and if we don't route towards it */ if (!is_single_hop_neigh && (orig_neigh_node->router == NULL)) { - debug_log(LOG_TYPE_BATMAN, "Drop packet: OGM via unkown neighbor! \n"); + debug_log(LOG_TYPE_BATMAN, "Drop packet: OGM via unknown neighbor! \n"); return; }
@@ -662,7 +662,7 @@ if (!is_my_mac(ethhdr->h_dest)) continue;
- /* drop packet if it has not neccessary minimum size */ + /* drop packet if it has not necessary minimum size */ if (result < sizeof(struct ethhdr) + sizeof(struct icmp_packet)) continue;
@@ -761,7 +761,7 @@ if (!is_my_mac(ethhdr->h_dest)) continue;
- /* drop packet if it has not neccessary minimum size */ + /* drop packet if it has not necessary minimum size */ if (result < sizeof(struct ethhdr) + sizeof(struct unicast_packet)) continue;
@@ -809,7 +809,7 @@ if (is_bcast(ethhdr->h_source)) continue;
- /* drop packet if it has not neccessary minimum size */ + /* drop packet if it has not necessary minimum size */ if (result < sizeof(struct ethhdr) + sizeof(struct bcast_packet)) continue;
Index: main.h =================================================================== --- main.h (revision 1340) +++ main.h (working copy) @@ -34,7 +34,7 @@ #define PURGE_TIMEOUT 200000 /* purge originators after time in ms if no valid packet comes in -> TODO: check influence on TQ_LOCAL_WINDOW_SIZE */ #define LOCAL_HNA_TIMEOUT 3600000
-#define TQ_LOCAL_WINDOW_SIZE 64 /* sliding packet range of received originator messages in squence numbers (should be a multiple of our word size) */ +#define TQ_LOCAL_WINDOW_SIZE 64 /* sliding packet range of received originator messages in sequence numbers (should be a multiple of our word size) */ #define TQ_GLOBAL_WINDOW_SIZE 10 #define TQ_LOCAL_BIDRECT_SEND_MINIMUM 1 #define TQ_LOCAL_BIDRECT_RECV_MINIMUM 1
Hi Folks
This patch fixes a few typos and spelling errors.
You don't specify for which project this patch is (yes, I can guess when I look at the patched files, but who wants to guess if it could be in the summary line of the patch - see as an example https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-June/002712.html or Mareks commit messages since r1257). I am not really sure but I think Marek prefers -p1 unified patches from the trunk... as he has written a script to apply my patches directly from mbox. He seems to interpret the whole message as commit message with the real patch at the end.
Maybe somebody should at a "SubmittingPatches" to the wiki - a good example for such a document is http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatche...
Best regards, Sven
On Fri, Jul 10, 2009 at 12:08:19PM +0200, Sven Eckelmann wrote:
Hi Folks
This patch fixes a few typos and spelling errors.
You don't specify for which project this patch is
I've emailed Merek a few times in the last day about this and other patches. He is expecting the patch and knows what is applies to. I'm more posting here for review by anybody who is interested. Maybe somebody will require a different dialect of English!
Also, i've been maintainer of an large open source project, eCos. An experience maintainers can very quickly determine what files where are involved.
I am not really sure but I think Marek prefers -p1 unified patches from the trunk... as he has written a script to apply my patches directly from mbox. He seems to interpret the whole message as commit message with the real patch at the end.
My experience from eCos is that the first few patches i get from a new contribute i want to take a very close look at. I generally apply them first with --dry just to make sure there are no surprises, corruption by mail tools, etc and they are against the latest trunk tip, etc. Only after a building up some level of trust with the contributor do i take a more relaxed approach. Since this is my first patch for b.a.t.m.a.n, i don't expect to get all the fine details right and i'm sure Merek will tell me where i'm wrong.
Andrew
On Friday 10 July 2009 18:08:19 Sven Eckelmann wrote:
I am not really sure but I think Marek prefers -p1 unified patches from the trunk... as he has written a script to apply my patches directly from mbox. He seems to interpret the whole message as commit message with the real patch at the end.
Maybe somebody should at a "SubmittingPatches" to the wiki - a good example for such a document is http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatch es;hb=HEAD
You raise a valid point here. I wrote some short guidelines on our contribute page (http://open-mesh.net/wiki/Contribute). Hope that clarifies the situation.
Regards, Marek
You raise a valid point here. I wrote some short guidelines on our contribute page (http://open-mesh.net/wiki/Contribute). Hope that clarifies the situation
Are my new patches O.K?
Andrew
On Tuesday 14 July 2009 17:28:36 Andrew Lunn wrote:
You raise a valid point here. I wrote some short guidelines on our contribute page (http://open-mesh.net/wiki/Contribute). Hope that clarifies the situation
Are my new patches O.K?
Yes, perfect. Both are in the repos now. Thanks a lot. :-)
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
Marek Lindner -
Sven Eckelmann