On Fri, 19 Jun 2020 at 14:58, Richard Cochran <richardcoch...@gmail.com> wrote:
>
> On Fri, Jun 19, 2020 at 02:51:56PM +0300, Vladimir Oltean wrote:
> > Could you please give a concrete example of why it isn't desirable for
> > MSG_DONTWAIT to be specified on a socket where data availability has
> > been previously confirmed through poll()? I'm not sure what the patch
> > has to do with the industry having "plenty enough guess work and
> > sloppy copy and paste as it is".
>
> This is how the sockets API works. Either you use poll or DONTWAIT,
> not both. Setting both shows that the author does not understand the
> API, and that is not a signal that I am willing to send out into the
> world.
>
> So this isn't desirable simply as a matter of style, but style does
> matter.
>
Let's keep it technical. Being rather inexperienced compared to others
who've contributed to the project and to Linux networking in general,
I do respect style, but I would also like to learn. The "man recv"
page says:
MSG_DONTWAIT (since Linux 2.2)
Enables nonblocking operation; if the operation would
block, the call fails with the error EAGAIN or EWOULDBLOCK.
And this is exactly what I want: a fail-fast system. So I need a
technical explanation about what's wrong with the patch. Sure this is
a production-quality application stack, but before it goes into
production it goes into tons and tons of testing first, testing which
is done by people, so if anything, I would see it as an improvement
that ptp4l detects runtime errors and doesn't just try to remain
oblivious to them. And a bug is a bug, doesn't matter if it's in the
kernel or in the application stack as far as I'm concerned. Whoever
could detect it should report it. The kernel does its part and the
application stack should do its part too.
> I appreciate that you (and I) spent long hours searching for a subtle
> kernel bug, and that was very frustrating. But it was a kernel bug,
> and a singular one at that. Production code does not and should not
> need special instrumentation to catch rare kernel bugs.
>
> Thanks,
> Richard
See, this is not instrumentation to catch rare kernel bugs, you're
reading the patches in totally the wrong key. This is simply extra
sanity checking.
Perhaps the most frustrating thing to me, after debugging that system
issue, is that ptp4l had all means necessary to detect a system issue,
but it preferred to remain oblivious to it.
Thanks,
-Vladimir
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
