On Wed, 24 Jun 2020 at 20:56, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, Jun 24, 2020 at 08:21:22PM +0300, Vladimir Oltean wrote: > > > What contract, who said that this control channel is _only_ for TX > > timestamps, and for how many TX timestamps it is? > > Um, there can't be more time stamps than transmitted frames. > > > 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? > > You are missing the point entirely. This is about poll(2) and not > about the socket error queue. POLLERR might possibly one day acquire > some kind of push semantics (i.e. unwanted by user space) on the kind > of DGRAM sockets we use. In addition, if ever a pipe-like transport > appears (and I think it not unlikely), then POLLERR will definitely > appear, and this patch prepares for that day. > > If a given driver is spewing out extra time stamps, then it is most > definitely the kernel's fault! > > Thanks, > Richard > >
I think it boils down to something very simple. The kernel is waking up a user process with revents = POLLIN | POLLERR. That has a certain meaning. Then the process says "Oh, yay, I have revents = POLLIN. Let me process that!". That has an entirely different meaning. Timestamps are just excuses here. Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
