[PATCH] IPV4: spelling correction

[PATCH] IPV4: spelling correction

[YOSHIFUJI Hideaki / 吉藤英明]

D: spelling correction for net/ipv4

===== net/ipv4/ip_gre.c 1.34 vs edited =====
--- 1.34/net/ipv4/ip_gre.c	Tue Oct 28 18:13:14 2003
+++ edited/net/ipv4/ip_gre.c	Wed Feb 11 02:57:54 2004
@@ -316,8 +316,8 @@
    GRE tunnels with enabled checksum. Tell them "thank you".
 
    Well, I wonder, rfc1812 was written by Cisco employee,
-   what the hell these idiots break standrads established
-   by themself???
+   what the hell these idiots break standrards established
+   by themselves???
  */
 
 	struct iphdr *iph = (struct iphdr*)skb->data;
===== net/ipv4/ip_output.c 1.49 vs edited =====
--- 1.49/net/ipv4/ip_output.c	Wed Feb  4 03:24:11 2004
+++ edited/net/ipv4/ip_output.c	Wed Feb 11 02:58:42 2004
@@ -35,7 +35,7 @@
  *		Andi Kleen	: 	Replace ip_reply with ip_send_reply.
  *		Andi Kleen	:	Split fast and slow ip_build_xmit path 
  *					for decreased register pressure on x86 
- *					and more readibility. 
+ *					and more readability. 
  *		Marc Boucher	:	When call_out_firewall returns FW_QUEUE,
  *					silently drop skb instead of failing with -EPERM.
  *		Detlev Wengorz	:	Copy protocol for fragments.
===== net/ipv4/proc.c 1.15 vs edited =====
--- 1.15/net/ipv4/proc.c	Fri Sep 12 10:08:45 2003
+++ edited/net/ipv4/proc.c	Wed Feb 11 02:59:47 2004
@@ -24,7 +24,7 @@
  *	Gerhard Koerting	:	Show both timers
  *		Alan Cox	:	Allow inode to be NULL (kernel socket)
  *	Andi Kleen		:	Add support for open_requests and
- *					split functions for more readibility.
+ *					split functions for more readability.
  *	Andi Kleen		:	Add support for /proc/net/netstat
  *	Arnaldo C. Melo		:	Convert to seq_file
  *
===== net/ipv4/tcp_input.c 1.49 vs edited =====
--- 1.49/net/ipv4/tcp_input.c	Mon Feb  2 04:22:45 2004
+++ edited/net/ipv4/tcp_input.c	Wed Feb 11 03:10:02 2004
@@ -42,7 +42,7 @@
  *		Andi Kleen	:	Moved open_request checking here
  *					and process RSTs for open_requests.
  *		Andi Kleen	:	Better prune_queue, and other fixes.
- *		Andrey Savochkin:	Fix RTT measurements in the presnce of
+ *		Andrey Savochkin:	Fix RTT measurements in the presence of
  *					timestamps.
  *		Andrey Savochkin:	Check sequence numbers correctly when
  *					removing SACKs due to in sequence incoming
@@ -283,7 +283,7 @@
 		sk->sk_rcvbuf = min(4 * rcvmem, sysctl_tcp_rmem[2]);
 }
 
-/* 4. Try to fixup all. It is made iimediately after connection enters
+/* 4. Try to fixup all. It is made immediately after connection enters
  *    established state.
  */
 static void tcp_init_buffer_space(struct sock *sk)
@@ -392,7 +392,7 @@
 			if (tp->ack.ato > tp->rto)
 				tp->ack.ato = tp->rto;
 		} else if (m > tp->rto) {
-			/* Too long gap. Apparently sender falled to
+			/* Too long gap. Apparently sender fellen to
 			 * restart window, so that we send ACKs quickly.
 			 */
 			tcp_incr_quickack(tp);
@@ -431,7 +431,7 @@
 	 *
 	 * Funny. This algorithm seems to be very broken.
 	 * These formulae increase RTO, when it should be decreased, increase
-	 * too slowly, when it should be incresed fastly, decrease too fastly
+	 * too slowly, when it should be increased fastly, decrease too fastly
 	 * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
 	 * does not matter how to _calculate_ it. Seems, it was trap
 	 * that VJ failed to avoid. 8)
@@ -493,14 +493,14 @@
 	 *    at least by solaris and freebsd. "Erratic ACKs" has _nothing_
 	 *    to do with delayed acks, because at cwnd>2 true delack timeout
 	 *    is invisible. Actually, Linux-2.4 also generates erratic
-	 *    ACKs in some curcumstances.
+	 *    ACKs in some circumstances.
 	 */
 	tp->rto = (tp->srtt >> 3) + tp->rttvar;
 
 	/* 2. Fixups made earlier cannot be right.
 	 *    If we do not estimate RTO correctly without them,
 	 *    all the algo is pure shit and should be replaced
-	 *    with correct one. It is exaclty, which we pretend to do.
+	 *    with correct one. It is exactly, which we pretend to do.
 	 */
 }
 
@@ -654,7 +654,7 @@
 	 * to make it more realistic.
 	 *
 	 * A bit of theory. RTT is time passed after "normal" sized packet
-	 * is sent until it is ACKed. In normal curcumstances sending small
+	 * is sent until it is ACKed. In normal circumstances sending small
 	 * packets force peer to delay ACKs and calculation is correct too.
 	 * The algorithm is adaptive and, provided we follow specs, it
 	 * NEVER underestimate RTT. BUT! If peer tries to make some clever
@@ -728,7 +728,7 @@
  * L|R	1		- orig is lost, retransmit is in flight.
  * S|R  1		- orig reached receiver, retrans is still in flight.
  * (L|S|R is logically valid, it could occur when L|R is sacked,
- *  but it is equivalent to plain S and code short-curcuits it to S.
+ *  but it is equivalent to plain S and code short-circuits it to S.
  *  L|S is logically invalid, it would mean -1 packet in flight 8))
  *
  * These 6 states form finite state machine, controlled by the following events:
@@ -2194,7 +2194,7 @@
 /*
  * @__westwood_fast_bw
  * It is called when we are in fast path. In particular it is called when
- * header prediction is successfull. In such case infact update is
+ * header prediction is successfull. In such case in fact update is
  * straight forward and doesn't need any particular care.
  */
 void __tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb)
@@ -3494,7 +3494,7 @@
 	 * urgent. To do this requires some care. We cannot just ignore
 	 * tp->copied_seq since we would read the last urgent byte again
 	 * as data, nor can we alter copied_seq until this data arrives
-	 * or we break the sematics of SIOCATMARK (and thus sockatmark())
+	 * or we break the semantics of SIOCATMARK (and thus sockatmark())
 	 *
 	 * NOTE. Double Dutch. Rendering to plain English: author of comment
 	 * above did something sort of 	send("A", MSG_OOB); send("B", MSG_OOB);
@@ -3638,7 +3638,7 @@
 	tp->saw_tstamp = 0;
 
 	/*	pred_flags is 0xS?10 << 16 + snd_wnd
-	 *	if header_predition is to be made
+	 *	if header_prediction is to be made
 	 *	'S' will always be tp->tcp_header_len >> 2
 	 *	'?' will be 0 for the fast path, otherwise pred_flags is 0 to
 	 *  turn it off	(when there are holes in the receive 
===== net/ipv4/tcp_minisocks.c 1.43 vs edited =====
--- 1.43/net/ipv4/tcp_minisocks.c	Tue Oct 28 20:10:47 2003
+++ edited/net/ipv4/tcp_minisocks.c	Wed Feb 11 03:11:01 2004
@@ -216,7 +216,7 @@
 		/* In window segment, it may be only reset or bare ack. */
 
 		if (th->rst) {
-			/* This is TIME_WAIT assasination, in two flavors.
+			/* This is TIME_WAIT assassination, in two flavors.
 			 * Oh well... nobody has a sufficient solution to this
 			 * protocol bug yet.
 			 */

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [PATCH] IPV4: spelling correction

[Randy.Dunlap]

On Wed, 11 Feb 2004 03:28:31 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ <yoshfuji@linux-ipv6.org> wrote:

a few comments (beginning with "**").


| D: spelling correction for net/ipv4
| 
| ===== net/ipv4/tcp_input.c 1.49 vs edited =====
| --- 1.49/net/ipv4/tcp_input.c	Mon Feb  2 04:22:45 2004
| +++ edited/net/ipv4/tcp_input.c	Wed Feb 11 03:10:02 2004
| @@ -392,7 +392,7 @@
|  			if (tp->ack.ato > tp->rto)
|  				tp->ack.ato = tp->rto;
|  		} else if (m > tp->rto) {
| -			/* Too long gap. Apparently sender falled to
| +			/* Too long gap. Apparently sender fellen to
**                                                         failed
|  			 * restart window, so that we send ACKs quickly.
|  			 */
|  			tcp_incr_quickack(tp);
| @@ -431,7 +431,7 @@
|  	 *
|  	 * Funny. This algorithm seems to be very broken.
|  	 * These formulae increase RTO, when it should be decreased, increase
| -	 * too slowly, when it should be incresed fastly, decrease too fastly
| +	 * too slowly, when it should be increased fastly, decrease too fastly
** s/fastly/quickly/ or s/fastly/fast/

|  	 * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
|  	 * does not matter how to _calculate_ it. Seems, it was trap
|  	 * that VJ failed to avoid. 8)
| @@ -493,14 +493,14 @@
|  	tp->rto = (tp->srtt >> 3) + tp->rttvar;
|  
|  	/* 2. Fixups made earlier cannot be right.
|  	 *    If we do not estimate RTO correctly without them,
|  	 *    all the algo is pure shit and should be replaced
| -	 *    with correct one. It is exaclty, which we pretend to do.
| +	 *    with correct one. It is exactly, which we pretend to do.
**                                           ^ what  (delete comma)

|  	 */
|  }
|  
| -- 
| Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
| GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA


--
~Randy

Re: [PATCH] IPV4: spelling correction

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040211.032831.67897970.yoshfuji@linux-ipv6.org> (at Wed, 11 Feb 2004 03:28:31 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:

>     Well, I wonder, rfc1812 was written by Cisco employee,
> -   what the hell these idiots break standrads established
> -   by themself???
> +   what the hell these idiots break standrards established
> +   by themselves???

Oops, this also includes a typo. Please use this instead.

===== net/ipv4/ip_gre.c 1.34 vs edited =====
--- 1.34/net/ipv4/ip_gre.c	Tue Oct 28 18:13:14 2003
+++ edited/net/ipv4/ip_gre.c	Wed Feb 11 03:30:06 2004
@@ -316,8 +316,8 @@
    GRE tunnels with enabled checksum. Tell them "thank you".
 
    Well, I wonder, rfc1812 was written by Cisco employee,
-   what the hell these idiots break standrads established
-   by themself???
+   what the hell these idiots break standards established
+   by themselves???
  */
 
 	struct iphdr *iph = (struct iphdr*)skb->data;
===== net/ipv4/ip_output.c 1.49 vs edited =====
--- 1.49/net/ipv4/ip_output.c	Wed Feb  4 03:24:11 2004
+++ edited/net/ipv4/ip_output.c	Wed Feb 11 03:29:42 2004
@@ -35,7 +35,7 @@
  *		Andi Kleen	: 	Replace ip_reply with ip_send_reply.
  *		Andi Kleen	:	Split fast and slow ip_build_xmit path 
  *					for decreased register pressure on x86 
- *					and more readibility. 
+ *					and more readability. 
  *		Marc Boucher	:	When call_out_firewall returns FW_QUEUE,
  *					silently drop skb instead of failing with -EPERM.
  *		Detlev Wengorz	:	Copy protocol for fragments.
===== net/ipv4/proc.c 1.15 vs edited =====
--- 1.15/net/ipv4/proc.c	Fri Sep 12 10:08:45 2003
+++ edited/net/ipv4/proc.c	Wed Feb 11 03:29:42 2004
@@ -24,7 +24,7 @@
  *	Gerhard Koerting	:	Show both timers
  *		Alan Cox	:	Allow inode to be NULL (kernel socket)
  *	Andi Kleen		:	Add support for open_requests and
- *					split functions for more readibility.
+ *					split functions for more readability.
  *	Andi Kleen		:	Add support for /proc/net/netstat
  *	Arnaldo C. Melo		:	Convert to seq_file
  *
===== net/ipv4/tcp_input.c 1.49 vs edited =====
--- 1.49/net/ipv4/tcp_input.c	Mon Feb  2 04:22:45 2004
+++ edited/net/ipv4/tcp_input.c	Wed Feb 11 03:29:42 2004
@@ -42,7 +42,7 @@
  *		Andi Kleen	:	Moved open_request checking here
  *					and process RSTs for open_requests.
  *		Andi Kleen	:	Better prune_queue, and other fixes.
- *		Andrey Savochkin:	Fix RTT measurements in the presnce of
+ *		Andrey Savochkin:	Fix RTT measurements in the presence of
  *					timestamps.
  *		Andrey Savochkin:	Check sequence numbers correctly when
  *					removing SACKs due to in sequence incoming
@@ -283,7 +283,7 @@
 		sk->sk_rcvbuf = min(4 * rcvmem, sysctl_tcp_rmem[2]);
 }
 
-/* 4. Try to fixup all. It is made iimediately after connection enters
+/* 4. Try to fixup all. It is made immediately after connection enters
  *    established state.
  */
 static void tcp_init_buffer_space(struct sock *sk)
@@ -392,7 +392,7 @@
 			if (tp->ack.ato > tp->rto)
 				tp->ack.ato = tp->rto;
 		} else if (m > tp->rto) {
-			/* Too long gap. Apparently sender falled to
+			/* Too long gap. Apparently sender fellen to
 			 * restart window, so that we send ACKs quickly.
 			 */
 			tcp_incr_quickack(tp);
@@ -431,7 +431,7 @@
 	 *
 	 * Funny. This algorithm seems to be very broken.
 	 * These formulae increase RTO, when it should be decreased, increase
-	 * too slowly, when it should be incresed fastly, decrease too fastly
+	 * too slowly, when it should be increased fastly, decrease too fastly
 	 * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
 	 * does not matter how to _calculate_ it. Seems, it was trap
 	 * that VJ failed to avoid. 8)
@@ -493,14 +493,14 @@
 	 *    at least by solaris and freebsd. "Erratic ACKs" has _nothing_
 	 *    to do with delayed acks, because at cwnd>2 true delack timeout
 	 *    is invisible. Actually, Linux-2.4 also generates erratic
-	 *    ACKs in some curcumstances.
+	 *    ACKs in some circumstances.
 	 */
 	tp->rto = (tp->srtt >> 3) + tp->rttvar;
 
 	/* 2. Fixups made earlier cannot be right.
 	 *    If we do not estimate RTO correctly without them,
 	 *    all the algo is pure shit and should be replaced
-	 *    with correct one. It is exaclty, which we pretend to do.
+	 *    with correct one. It is exactly, which we pretend to do.
 	 */
 }
 
@@ -654,7 +654,7 @@
 	 * to make it more realistic.
 	 *
 	 * A bit of theory. RTT is time passed after "normal" sized packet
-	 * is sent until it is ACKed. In normal curcumstances sending small
+	 * is sent until it is ACKed. In normal circumstances sending small
 	 * packets force peer to delay ACKs and calculation is correct too.
 	 * The algorithm is adaptive and, provided we follow specs, it
 	 * NEVER underestimate RTT. BUT! If peer tries to make some clever
@@ -728,7 +728,7 @@
  * L|R	1		- orig is lost, retransmit is in flight.
  * S|R  1		- orig reached receiver, retrans is still in flight.
  * (L|S|R is logically valid, it could occur when L|R is sacked,
- *  but it is equivalent to plain S and code short-curcuits it to S.
+ *  but it is equivalent to plain S and code short-circuits it to S.
  *  L|S is logically invalid, it would mean -1 packet in flight 8))
  *
  * These 6 states form finite state machine, controlled by the following events:
@@ -2194,7 +2194,7 @@
 /*
  * @__westwood_fast_bw
  * It is called when we are in fast path. In particular it is called when
- * header prediction is successfull. In such case infact update is
+ * header prediction is successfull. In such case in fact update is
  * straight forward and doesn't need any particular care.
  */
 void __tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb)
@@ -3494,7 +3494,7 @@
 	 * urgent. To do this requires some care. We cannot just ignore
 	 * tp->copied_seq since we would read the last urgent byte again
 	 * as data, nor can we alter copied_seq until this data arrives
-	 * or we break the sematics of SIOCATMARK (and thus sockatmark())
+	 * or we break the semantics of SIOCATMARK (and thus sockatmark())
 	 *
 	 * NOTE. Double Dutch. Rendering to plain English: author of comment
 	 * above did something sort of 	send("A", MSG_OOB); send("B", MSG_OOB);
@@ -3638,7 +3638,7 @@
 	tp->saw_tstamp = 0;
 
 	/*	pred_flags is 0xS?10 << 16 + snd_wnd
-	 *	if header_predition is to be made
+	 *	if header_prediction is to be made
 	 *	'S' will always be tp->tcp_header_len >> 2
 	 *	'?' will be 0 for the fast path, otherwise pred_flags is 0 to
 	 *  turn it off	(when there are holes in the receive 
===== net/ipv4/tcp_minisocks.c 1.43 vs edited =====
--- 1.43/net/ipv4/tcp_minisocks.c	Tue Oct 28 20:10:47 2003
+++ edited/net/ipv4/tcp_minisocks.c	Wed Feb 11 03:29:42 2004
@@ -216,7 +216,7 @@
 		/* In window segment, it may be only reset or bare ack. */
 
 		if (th->rst) {
-			/* This is TIME_WAIT assasination, in two flavors.
+			/* This is TIME_WAIT assassination, in two flavors.
 			 * Oh well... nobody has a sufficient solution to this
 			 * protocol bug yet.
 			 */

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [PATCH] IPV4: spelling correction

[Nivedita Singhvi]

YOSHIFUJI Hideaki / 吉藤英明 wrote:

>>    Well, I wonder, rfc1812 was written by Cisco employee,
>>-   what the hell these idiots break standrads established
>>-   by themself???
>>+   what the hell these idiots break standrards established
>>+   by themselves???
> 
> 
> Oops, this also includes a typo. Please use this instead.

I strongly object. Strongly and strenuously. DaveM, please,
please, please, leave those golden lines alone. The original
from Alexey is a work of art, humor, character and intelligence.

Removing those lines would reduce Linux to tasteless,
bland potatohood that so characterizes every other operating
system out there (OK, with the possible exception of Dynix/ptx,
but it's dead, Jim).

Assimilate all the rest of the kernel into the grammatically
correct and humorless Borg, if you will, but please, please,
leave these lines alone...

thanks,
Nivedita

Re: [PATCH] IPV4: spelling correction

[David S. Miller]

On Tue, 10 Feb 2004 10:44:48 -0800
Nivedita Singhvi <niv@us.ibm.com> wrote:

> I strongly object. Strongly and strenuously. DaveM, please,
> please, please, leave those golden lines alone. The original
> from Alexey is a work of art, humor, character and intelligence.

I totally agree.  In documentation and things for end users, fine.
We can typo correct till the end of time.  But for comments meant
for programmers, let's keep it lively and humorous and sometimes
flat out grammatically wrong.  This is what gives it flavor makes
it our's.

Often times I can tell who wrote what merely by the phrasing style
of the comments.  That's incredibly cool :)

Re: [PATCH] IPV4: spelling correction

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040210105124.61431b9b.davem@redhat.com> (at Tue, 10 Feb 2004 10:51:24 -0800), "David S. Miller" <davem@redhat.com> says:

> On Tue, 10 Feb 2004 10:44:48 -0800
> Nivedita Singhvi <niv@us.ibm.com> wrote:
> 
> > I strongly object. Strongly and strenuously. DaveM, please,
> > please, please, leave those golden lines alone. The original
> > from Alexey is a work of art, humor, character and intelligence.
> 
> I totally agree.  In documentation and things for end users, fine.
> We can typo correct till the end of time.  But for comments meant
> for programmers, let's keep it lively and humorous and sometimes
> flat out grammatically wrong.  This is what gives it flavor makes
> it our's.

Okay.

But... Please apply the following patch. 
I want to fix my error and mis-leading flags. :-P

Thanks.

===== net/ipv6/addrconf.c 1.91 vs edited =====
--- 1.91/net/ipv6/addrconf.c	Tue Feb  3 03:31:58 2004
+++ edited/net/ipv6/addrconf.c	Wed Feb 11 03:56:59 2004
@@ -1071,7 +1071,7 @@
 		eui[0] ^= 2;
 		return 0;
 	case ARPHRD_ARCNET:
-		/* XXX: inherit EUI-64 fro mother interface -- yoshfuji */
+		/* XXX: inherit EUI-64 from other interface -- yoshfuji */
 		if (dev->addr_len != ARCNET_ALEN)
 			return -1;
 		memset(eui, 0, 7);
===== net/ipv6/ndisc.c 1.71 vs edited =====
--- 1.71/net/ipv6/ndisc.c	Tue Feb 10 04:13:09 2004
+++ edited/net/ipv6/ndisc.c	Wed Feb 11 04:00:28 2004
@@ -747,7 +747,7 @@
 			return;
 		}
 
-		/* XXX: RFC2461 7.1.1:
+		/* RFC2461 7.1.1:
 	 	 *	If the IP source address is the unspecified address, 
 		 *	there MUST NOT be source link-layer address option 
 		 *	in the message.
@@ -1195,7 +1195,7 @@
 		return;
 	}
 
-	/* XXX: RFC2461 8.1: 
+	/* RFC2461 8.1: 
 	 *	The IP source address of the Redirect MUST be the same as the current
 	 *	first-hop router for the specified ICMP Destination Address.
 	 */

--yoshfuji

Re: [PATCH] IPV4: spelling correction

[Arnaldo Carvalho de Melo]

Em Tue, Feb 10, 2004 at 10:51:24AM -0800, David S. Miller escreveu:
> Often times I can tell who wrote what merely by the phrasing style
> of the comments.  That's incredibly cool :)

This is sooooo true... 8) Sometimes there is a -ANK, but sometimes
it is just not needed, at all :P

- Arnaldo

Re: [PATCH] IPV4: spelling correction

[jamal]

Some of those comments should be framed ;-> They are just the best.

[I have to say the best comments i have ever seen was in some
old code (written in the 70s in some big corp that i worked for) by some
guy who claimed he couldnt fix something because he was naked (had to
get dressed). 
Only 20 years later we had to fix that bug because of a customer
problem;-> It was good he had that comment in there. Afterwards trying
to catchup with sleep I kept getting image flashes of this guy trying to
get dressed in a hurry and forgeting to fix the bug. Then i started
wondering what possibly could have been rushing that guy to get dressed?
Then i saluted the guy for being courageous enough to leave that comment
in there (it was the most obscene and coolest comment in a few million
lines of code). hehe. I never met him but there are so many unanswered
questions ;-> Dude, if you are reading this message call me, you are my
hero ;->
Fast forward 20 years from now with the comments in the net code in
Linux ..]

cheers,
jamal

On Wed, 2004-02-11 at 07:07, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 10, 2004 at 10:51:24AM -0800, David S. Miller escreveu:
> > Often times I can tell who wrote what merely by the phrasing style
> > of the comments.  That's incredibly cool :)
> 
> This is sooooo true... 8) Sometimes there is a -ANK, but sometimes
> it is just not needed, at all :P
> 
> - Arnaldo
> 
> 

Re: [PATCH] IPV4: spelling correction

[Nivedita Singhvi]

jamal wrote:

> [I have to say the best comments i have ever seen was in some
> old code (written in the 70s in some big corp that i worked for) by some
> guy who claimed he couldnt fix something because he was naked (had to
> get dressed). 

Oh lord. Trying to look into a kernel bug and now
this naked guy image ... :). Probably going to haunt us
all for some time. Bug fixing might never be the
same ;)

thanks,
Nivedita

Re: [PATCH] IPV4: spelling correction (Take 3)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040211.033324.120562092.yoshfuji@linux-ipv6.org> (at Wed, 11 Feb 2004 03:33:24 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:

> In article <20040211.032831.67897970.yoshfuji@linux-ipv6.org> (at Wed, 11 Feb 2004 03:28:31 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:
> 
> >     Well, I wonder, rfc1812 was written by Cisco employee,
> > -   what the hell these idiots break standrads established
> > -   by themself???
> > +   what the hell these idiots break standrards established
> > +   by themselves???
> 
> Oops, this also includes a typo. Please use this instead.

Thank you, Joe, Chris and Randy!
Here's the updated patch. (Take 3)

===== net/ipv4/ip_gre.c 1.34 vs edited =====
--- 1.34/net/ipv4/ip_gre.c	Tue Oct 28 18:13:14 2003
+++ edited/net/ipv4/ip_gre.c	Wed Feb 11 03:39:50 2004
@@ -94,7 +94,7 @@
    that is ALL. :-) Well, it does not remove the problem completely,
    but exponential growth of network traffic is changed to linear
    (branches, that exceed pmtu are pruned) and tunnel mtu
-   fastly degrades to value <68, where looping stops.
+   quickly degrades to value <68, where looping stops.
    Yes, it is not good if there exists a router in the loop,
    which does not force DF, even when encapsulating packets have DF set.
    But it is not our problem! Nobody could accuse us, we made
@@ -316,8 +316,8 @@
    GRE tunnels with enabled checksum. Tell them "thank you".
 
    Well, I wonder, rfc1812 was written by Cisco employee,
-   what the hell these idiots break standrads established
-   by themself???
+   what the hell these idiots break standards established
+   by themselves???
  */
 
 	struct iphdr *iph = (struct iphdr*)skb->data;
===== net/ipv4/ip_output.c 1.49 vs edited =====
--- 1.49/net/ipv4/ip_output.c	Wed Feb  4 03:24:11 2004
+++ edited/net/ipv4/ip_output.c	Wed Feb 11 03:39:16 2004
@@ -35,7 +35,7 @@
  *		Andi Kleen	: 	Replace ip_reply with ip_send_reply.
  *		Andi Kleen	:	Split fast and slow ip_build_xmit path 
  *					for decreased register pressure on x86 
- *					and more readibility. 
+ *					and more readability. 
  *		Marc Boucher	:	When call_out_firewall returns FW_QUEUE,
  *					silently drop skb instead of failing with -EPERM.
  *		Detlev Wengorz	:	Copy protocol for fragments.
===== net/ipv4/proc.c 1.15 vs edited =====
--- 1.15/net/ipv4/proc.c	Fri Sep 12 10:08:45 2003
+++ edited/net/ipv4/proc.c	Wed Feb 11 03:39:16 2004
@@ -24,7 +24,7 @@
  *	Gerhard Koerting	:	Show both timers
  *		Alan Cox	:	Allow inode to be NULL (kernel socket)
  *	Andi Kleen		:	Add support for open_requests and
- *					split functions for more readibility.
+ *					split functions for more readability.
  *	Andi Kleen		:	Add support for /proc/net/netstat
  *	Arnaldo C. Melo		:	Convert to seq_file
  *
===== net/ipv4/tcp_input.c 1.49 vs edited =====
--- 1.49/net/ipv4/tcp_input.c	Mon Feb  2 04:22:45 2004
+++ edited/net/ipv4/tcp_input.c	Wed Feb 11 03:41:25 2004
@@ -42,7 +42,7 @@
  *		Andi Kleen	:	Moved open_request checking here
  *					and process RSTs for open_requests.
  *		Andi Kleen	:	Better prune_queue, and other fixes.
- *		Andrey Savochkin:	Fix RTT measurements in the presnce of
+ *		Andrey Savochkin:	Fix RTT measurements in the presence of
  *					timestamps.
  *		Andrey Savochkin:	Check sequence numbers correctly when
  *					removing SACKs due to in sequence incoming
@@ -283,7 +283,7 @@
 		sk->sk_rcvbuf = min(4 * rcvmem, sysctl_tcp_rmem[2]);
 }
 
-/* 4. Try to fixup all. It is made iimediately after connection enters
+/* 4. Try to fixup all. It is made immediately after connection enters
  *    established state.
  */
 static void tcp_init_buffer_space(struct sock *sk)
@@ -392,7 +392,7 @@
 			if (tp->ack.ato > tp->rto)
 				tp->ack.ato = tp->rto;
 		} else if (m > tp->rto) {
-			/* Too long gap. Apparently sender falled to
+			/* Too long gap. Apparently sender failed to
 			 * restart window, so that we send ACKs quickly.
 			 */
 			tcp_incr_quickack(tp);
@@ -431,7 +431,7 @@
 	 *
 	 * Funny. This algorithm seems to be very broken.
 	 * These formulae increase RTO, when it should be decreased, increase
-	 * too slowly, when it should be incresed fastly, decrease too fastly
+	 * too slowly, when it should be increased quickly, decrease too quickly
 	 * etc. I guess in BSD RTO takes ONE value, so that it is absolutely
 	 * does not matter how to _calculate_ it. Seems, it was trap
 	 * that VJ failed to avoid. 8)
@@ -493,14 +493,14 @@
 	 *    at least by solaris and freebsd. "Erratic ACKs" has _nothing_
 	 *    to do with delayed acks, because at cwnd>2 true delack timeout
 	 *    is invisible. Actually, Linux-2.4 also generates erratic
-	 *    ACKs in some curcumstances.
+	 *    ACKs in some circumstances.
 	 */
 	tp->rto = (tp->srtt >> 3) + tp->rttvar;
 
 	/* 2. Fixups made earlier cannot be right.
 	 *    If we do not estimate RTO correctly without them,
 	 *    all the algo is pure shit and should be replaced
-	 *    with correct one. It is exaclty, which we pretend to do.
+	 *    with correct one. It is exactly what we pretend to do.
 	 */
 }
 
@@ -654,7 +654,7 @@
 	 * to make it more realistic.
 	 *
 	 * A bit of theory. RTT is time passed after "normal" sized packet
-	 * is sent until it is ACKed. In normal curcumstances sending small
+	 * is sent until it is ACKed. In normal circumstances sending small
 	 * packets force peer to delay ACKs and calculation is correct too.
 	 * The algorithm is adaptive and, provided we follow specs, it
 	 * NEVER underestimate RTT. BUT! If peer tries to make some clever
@@ -728,7 +728,7 @@
  * L|R	1		- orig is lost, retransmit is in flight.
  * S|R  1		- orig reached receiver, retrans is still in flight.
  * (L|S|R is logically valid, it could occur when L|R is sacked,
- *  but it is equivalent to plain S and code short-curcuits it to S.
+ *  but it is equivalent to plain S and code short-circuits it to S.
  *  L|S is logically invalid, it would mean -1 packet in flight 8))
  *
  * These 6 states form finite state machine, controlled by the following events:
@@ -2194,7 +2194,7 @@
 /*
  * @__westwood_fast_bw
  * It is called when we are in fast path. In particular it is called when
- * header prediction is successfull. In such case infact update is
+ * header prediction is successful. In such case in fact update is
  * straight forward and doesn't need any particular care.
  */
 void __tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb)
@@ -2533,7 +2533,7 @@
  * to timestamp space.
  *
  * All these measures still do not guarantee that we reject wrapped ACKs
- * on networks with high bandwidth, when sequence space is recycled fastly,
+ * on networks with high bandwidth, when sequence space is recycled quickly,
  * but it guarantees that such events will be very rare and do not affect
  * connection seriously. This doesn't look nice, but alas, PAWS is really
  * buggy extension.
@@ -3494,7 +3494,7 @@
 	 * urgent. To do this requires some care. We cannot just ignore
 	 * tp->copied_seq since we would read the last urgent byte again
 	 * as data, nor can we alter copied_seq until this data arrives
-	 * or we break the sematics of SIOCATMARK (and thus sockatmark())
+	 * or we break the semantics of SIOCATMARK (and thus sockatmark())
 	 *
 	 * NOTE. Double Dutch. Rendering to plain English: author of comment
 	 * above did something sort of 	send("A", MSG_OOB); send("B", MSG_OOB);
@@ -3638,7 +3638,7 @@
 	tp->saw_tstamp = 0;
 
 	/*	pred_flags is 0xS?10 << 16 + snd_wnd
-	 *	if header_predition is to be made
+	 *	if header_prediction is to be made
 	 *	'S' will always be tp->tcp_header_len >> 2
 	 *	'?' will be 0 for the fast path, otherwise pred_flags is 0 to
 	 *  turn it off	(when there are holes in the receive 
===== net/ipv4/tcp_minisocks.c 1.43 vs edited =====
--- 1.43/net/ipv4/tcp_minisocks.c	Tue Oct 28 20:10:47 2003
+++ edited/net/ipv4/tcp_minisocks.c	Wed Feb 11 03:39:16 2004
@@ -216,7 +216,7 @@
 		/* In window segment, it may be only reset or bare ack. */
 
 		if (th->rst) {
-			/* This is TIME_WAIT assasination, in two flavors.
+			/* This is TIME_WAIT assassination, in two flavors.
 			 * Oh well... nobody has a sufficient solution to this
 			 * protocol bug yet.
 			 */

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [PATCH] IPV4: spelling correction

[Chris Wright]

* YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B (yoshfuji@linux-ipv6.org) wrote:
> --- 1.34/net/ipv4/ip_gre.c	Tue Oct 28 18:13:14 2003
> +++ edited/net/ipv4/ip_gre.c	Wed Feb 11 02:57:54 2004
> @@ -316,8 +316,8 @@
>     GRE tunnels with enabled checksum. Tell them "thank you".
>  
>     Well, I wonder, rfc1812 was written by Cisco employee,
> -   what the hell these idiots break standrads established
> -   by themself???
> +   what the hell these idiots break standrards established
                                       ^^^^^^^^^^
> +   by themselves???

Heh, looks like swapping one typo for another.  standards?

> @@ -392,7 +392,7 @@
>  			if (tp->ack.ato > tp->rto)
>  				tp->ack.ato = tp->rto;
>  		} else if (m > tp->rto) {
> -			/* Too long gap. Apparently sender falled to
> +			/* Too long gap. Apparently sender fellen to
							   ^^^^^^
failed?

>  			 * restart window, so that we send ACKs quickly.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net