On Sun, 2026-07-26 at 18:41 -0700, Richard Cochran wrote: > On Tue, Jul 14, 2026 at 02:03:01AM +0000, Arthur Kiyanovski wrote: > > This series adds quality attributes to PTP Hardware Clock (PHC) > > timestamps, allowing userspace to obtain error bound, clock status, > > timescale, and system counter values alongside timestamps in a > > single > > call. > > > > Motivation > > ---------- > > The existing PTP APIs return timestamps without any indication of > > their quality. Applications that need clock accuracy and > > synchronization status commonly rely on external tools such as > > ptp4l, which implement synchronization logic and can export their > > measurement of clock accuracy. > > Yes, and what is wrong with that? Nothing, AFAICT
Sure, there's nothing wrong with that when it's userspace which is actually doing the discipline of the clock. This is for the cases where the device itself is responsible for the discipline, and the driver is merely transporting the clock status. > ? For managed PHC devices — such as > > the ENA network adapter, whose clock is synchronized by the device > > without userspace involvement — these tools are not available, and > > the existing APIs lack a way to report quality metrics to consumers > > of time. > > So make some user space tool that advertises your device's qualities. I suppose we could invent different device-specific ways for each of the drivers to expose the same information? But let's not.
smime.p7s
Description: S/MIME cryptographic signature
