Re: [PATCH v2 0/7] TCP Fast Open client

[Rick Jones <rick.jones2@hp.com>]

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