On Fri, 19 Jun 2020 at 17:21, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Fri, Jun 19, 2020 at 04:01:57PM +0300, Vladimir Oltean wrote: > > Again, I would have accepted any technical argument you could bring. > > Thinking more about this, there is in fact a technical reason to leave > the code as is. For DGRAM sockets, the behavior of recvmsg() in > sk_receive() is the same with and without DONTWAIT. But this is only > by chance. > > Consider a STREAM socket with fixed message sizes. In that case, poll > indicates only that the socket is readable, and not that an entire > message is available. When recvmsg(flags=DONTWAIT) returns, the > length may be less than a full message, and the code in sk_receive() > would have to read the socket again (and again) until a whole message > arrives. If sk_receive(flags=DONTWAIT) is allowed, then that method > would have to cover the case of reading a partial message. >
A technical argument which implies that IEEE 1588 synchronization may work over connection-oriented sockets is a stylistic argument, really. I don't buy it. > But sk_receive() does not implement that programming pattern. Instead > the caller knows a message is available, and then sk_receive() > "blocks" in recvmsg() for that one message. That is the design > pattern. > No, sk_receive() does not "block" in recvmsg() for that one message. Any kernel tracing program (I recommend kernelshark, it has a nice GUI) will tell you that. > > So, as a matter of personal style, I think the only right thing for me > > to do is to retreat now. Feel free to use any portion of the patches I > > submitted so far in any combination you see desirable. > > I will likely apply patch 3. For patch 2, could you please comment on > the diff I posted as an alternate solution? > Yes, I will provide my feedback on that. > Thanks, > Richard Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
