From: "David S. Miller" <davem@redhat.com>
To: greearb@candelatech.com
Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Networking: send-to-self [link to non-broken patch this time]
Date: Wed, 18 Sep 2002 18:28:55 -0700 (PDT) [thread overview]
Message-ID: <20020918.182855.47438220.davem@redhat.com> (raw)
In-Reply-To: <3D890A51.7000103@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Wed, 18 Sep 2002 16:20:49 -0700
David S. Miller wrote:
> I don't think I'll be applying this:
>
> 1) No tcp ipv6 bits
I know squat about this, so am reluctant to hack code there.
It's hash lookup code, nearly identical to ipv4 version except
it's dealing with 128-bit IP addresses instead of 32-bit.
You give up way too easily, which leads me to belive you'll disappear
just as easily if complicated bugs stop popping up as a result of your
changes.
This is one of the most important issues I consider when I get a
delicate patch to the networking for someone, how fast they throw
their arms up in the air.
For example, someone like Arnaldo, when he sends me a patch and the
whole kernel explodes as a result I know he'll stick around for
however long it takes to fix the problems and he won't go "ipv6 looks
too complicated" when I ask him to submit a complete version of his
changes.
You patch should not be a maintainence burden to me. Your attitude
tells me it is going to become one.
See http://www.candelatech.com/sts2_hack.patch (32-bit only), it contains the missing
bits, I'm not good at generating two patch sets (ie pktgen and send-to-self)
when they touch the same file...
Don't include stuff in the patch that doesn't belong there, this isn't
so difficult.
The #ifdefs were per request, I personally would like them not to be there
either. As far as I can tell, the changes are backwards compatible, so there
should be no need for ifdefs.
I mean put the ifdefs in a header file such as tcp.h, not in the *.c
code.
Thanks for looking at them. I can fix the #ifdef cruft, but adding 64bit
support or hacking ipv6 is beyond my means of testing at this point, so
I cannot make those changes.
I don't require you to test the ipv6 portions, I will be able to
eyeball them and know if they are right or not, this is how simple
the ipv6 version of the tcp bits will be.
next prev parent reply other threads:[~2002-09-19 1:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 6:47 [PATCH] Networking: send-to-self Ben Greear
2002-09-18 6:44 ` David S. Miller
2002-09-18 6:53 ` Ben Greear
2002-09-18 7:09 ` [PATCH] Networking: send-to-self [link to non-broken patch this time] Ben Greear
2002-09-18 22:55 ` David S. Miller
2002-09-18 23:20 ` Ben Greear
2002-09-19 1:28 ` David S. Miller [this message]
2002-09-19 2:07 ` Ben Greear
2002-09-19 2:01 ` David S. Miller
2002-09-19 3:04 ` Ben Greear
2002-09-27 1:00 ` [PATCH] Networking: send-to-self [link to non-broken patch this kuznet
2002-09-27 1:30 ` Ben Greear
2002-09-27 3:36 ` kuznet
2002-09-27 6:33 ` Ben Greear
2002-09-27 15:01 ` kuznet
2002-09-27 15:40 ` Ben Greear
2002-09-27 15:46 ` kuznet
2002-09-27 15:53 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020918.182855.47438220.davem@redhat.com \
--to=davem@redhat.com \
--cc=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).