[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <502D214E.8070803@hp.com>
Date: Thu, 16 Aug 2012 09:35:26 -0700
From: Rick Jones <rick.jones2@...com>
To: David Laight <David.Laight@...LAB.COM>
CC: Yuchung Cheng <ycheng@...gle.com>, davem@...emloft.net,
hkchu@...gle.com, edumazet@...gle.com, ncardwell@...gle.com,
sivasankar@...ucsd.edu, netdev@...r.kernel.org
Subject: Re: [PATCH v2 0/7] TCP Fast Open client
On 08/16/2012 01:50 AM, David Laight wrote:
> It seems wrong to be using sendmsg() to perform a 'connect' action.
> Anything that tries to monitor the socket state from a trace, or
> validate the sequence of library calls will get it all wrong.
>
> IMHO this should be a new connect_xxx() function - and probably
> a new system call entry.
>
> This is similar to the complete fubar where sctp abuses setsockopt().
>
> For development hacking using sendmsg() probably avoided the need
> to hack at some code paths, but I'm sure it will cause grief in
> the long term.
>
> Other OS may have much more difficultly in abusing sendmsg().
I kind of like being able to use sendmsg()/sendto() as it provides a bit
of symmetry with UDP. Just so long as I can keep using
sendmsg()/sendto() for subsequent sends on the same connection I think
it would be fine. In fact, being able to use sendto() made adding
netperf support for the client side of TCP Fast Open rather trivial as
it already knew about using sendto() for UDP :)
Someone tracing/monitoring will have to know "When tracing an
application possibly using TCP Fast Open you have to include
<new-to-the-procedure> in the tracing" - and including sendmsg/sendto
there is no different than a new call. At least from my perspective.
rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists