[Top] [All Lists]

Re: [PATCH] merge sctp_opt with sctp_sock

To: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] merge sctp_opt with sctp_sock
From: Sridhar Samudrala <sri@xxxxxxxxxx>
Date: Mon, 17 Jan 2005 18:18:04 -0800 (PST)
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <>
References: <> <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 17 Jan 2005, Arnaldo Carvalho de Melo wrote:

> 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@xxxxxxxxxxxxxxxx> wrote:
> >>>
> >>>
> >>>
> >>>>  Please take a look and if its acceptable pull from:
> >>>>
> >>>>bk://
> >>>>
> >>>>  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)

It looks fine and i don't see any issues. will try to pull from davem's tree and
test to see that it doesn't break any SCTP regression tests.


<Prev in Thread] Current Thread [Next in Thread>