On Wed, 24 Jun 2020 at 19:58, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, Jun 24, 2020 at 07:36:47PM +0300, Vladimir Oltean wrote: > > I am reading this as: "let's be defensive even in the case where the > > kernel decides to go nuts and push us a packet on the error queue even > > if we didn't enable SO_SELECT_ERR_QUEUE". But that isn't at all what's > > going on. As stated, we opted in this SO_SELECT_ERR_QUEUE game because > > we need TX timestamps. > > But, at this point in the program, we know that no tx time stamp is > outstanding. We always send one Tx event, then immediately fetch the > time stamp. This is carefully synchronized by the program. It is > important to do this because many drivers support exactly one Tx time > stamp at a time. > > The kernel must not fabricate transmit time stamps! That would be > breaking the contract. >
Luckily the author of that socket option, and 1 of the 2 people on CC on that patch, are present in this email thread: https://patchwork.ozlabs.org/project/netdev/patch/20130327220028.13267.89112.st...@jekeller-hub.jf.intel.com/ So, I think you or Jacob would be in a good position to answer: What contract, who said that this control channel is _only_ for TX timestamps, and for how many TX timestamps it is? If a future kernel decided to send more data to programs who opted in to the error queue, and that kernel decision were to break ptp4l, could you honestly say it's the kernel's fault? I mean, those packets are already associated with a cmsg, you're supposed to only filter the one you're interested in, and ignore everything else. But ptp4l is clearly not doing that. > > So we need to be correct, and play by the API's > > rules, which means treat the POLLERR returned event. It is a > > correctness issue, not a defense issue. > > I think you are splitting hairs here, but I disagree that the program > was incorrect. There is no reason _today_ for poll to return a > POLLERR event from this call, but, in general, I don't believe this is > guaranteed by anything. > I am splitting the hairs I have left, really. Life would have been _so_much_simpler_ if ptp4l just had this POLLERR check. Who am I to guess what's going on if ptp4l gets a POLLERR event and treats it like a POLLIN? > Would you prefer me leaving your name off the commit message? > If we can't reconcile the fact that this is fixing an API misuse, then you can take my name off of it, sure. I care more about seeing the code modification go in, than I do about seeing my name on it. > Thanks, > Richard > > > Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
