All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.