> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Wednesday, June 24, 2020 9:58 AM
> To: Vladimir Oltean <olte...@gmail.com>
> Cc: linuxptp-devel@lists.sourceforge.net; Keller, Jacob E
> <jacob.e.kel...@intel.com>
> Subject: Re: [PATCH v2 2/3] clock: dump unexpected packets received on the
> error queues of sockets
>
> 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.
Sure, but the POLLERR could (in theory, not in current practice) return other
events/messages besides timestamps.
It was invented/created prior to the Tx timestamps, wasn't it?
>
> > 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.
>
Right. Today there's no other messages that I am aware of.
> Would you prefer me leaving your name off the commit message?
>
> Thanks,
> Richard
>
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
