From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@oss.sgi.com
Subject: Re: [PATCH] merge sctp_opt with sctp_sock
Date: Mon, 17 Jan 2005 23:49:33 -0200 [thread overview]
Message-ID: <41EC6B2D.7020506@conectiva.com.br> (raw)
In-Reply-To: <Pine.LNX.4.58.0501171718380.15927@w-sridhar.beaverton.ibm.com>
Sridhar Samudrala escreveu:
> On Mon, 17 Jan 2005, Arnaldo Carvalho de Melo wrote:
>
>
>>David S. Miller escreveu:
>>
>>>On Sat, 15 Jan 2005 02:52:13 -0200
>>>Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:
>>>
>>>
>>>
>>>> Please take a look and if its acceptable pull from:
>>>>
>>>>bk://kernel.bkbits.net/acme/connection_sock-2.6
>>>>
>>>> The tricky bit here is that SCTP, to keep the existing logic,
>>>>needs a way to copy only its private area from one sock to another, so
>>>>I introduced a generic inet_sk_copy_descendant, that knows about the
>>>>inet (v4/v6) layout (wrt inet_sock and inet6_pinfo), using this and
>>>>sk->sk_prot->slab_obj_size we can copy the inet_sock descendant
>>>>private area generically.
>>>
>>>
>>>This looks fine, although I wish the descendant copying thing
>>>could be done more cleanly somehow.
>>
>>/me too, but this is the best scheme I've found for now, perhaps in
>>the future, after some more refactoring work is done/merged we can
>>find some better way of doing this (tcp_create_openreq_child also
>>does something like this, but does it in all the sock, perhaps
>>SCTP can do something similar).
>
>
> I thought you introduced this generic function so that other protocols also
> may use it. If you & Dave feel that this is not clean and is going to be
> needed only by SCTP, SCTP also could do a memcpy of the entire sock instead
> of only sctp private area before calling sctp_sock_migrate although it is not
> very straightforward. Let me know if i should work on a patch to do that.
Sridhar, please leave it as is for now, perhaps some other protocol will need it,
I still have decnet, econet, x.25, wanrouter, etc to go, and this is not something
we should spend too much time for now, I think, I'm more than happy if you
just tell me that this is equivalent to what we had before, i.e. that I didn't
introduced any bugs 8)
- Arnaldo
next prev parent reply other threads:[~2005-01-18 1:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-15 4:52 [PATCH] merge sctp_opt with sctp_sock Arnaldo Carvalho de Melo
2005-01-17 21:33 ` David S. Miller
2005-01-18 1:12 ` Arnaldo Carvalho de Melo
2005-01-18 1:40 ` Sridhar Samudrala
2005-01-18 1:49 ` Arnaldo Carvalho de Melo [this message]
2005-01-18 2:18 ` Sridhar Samudrala
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=41EC6B2D.7020506@conectiva.com.br \
--to=acme@conectiva.com.br \
--cc=davem@davemloft.net \
--cc=netdev@oss.sgi.com \
--cc=sri@us.ibm.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).