On 2026/1/13 12:21, Richard Cochran wrote:

On Fri, Jan 09, 2026 at 10:56:56AM +0800, Wen Gu wrote:

quoted

Introducing a new clock type or a new userspace API (e.g. /dev/XXX) would
require widespread userspace changes, duplicated tooling, and long-term
fragmentation. This RFC is explicitly NOT proposing a new userspace API.

Actually I disagree.

The PHC devices appear to user space as clockid_t.

The API for these works seamlessly and interchangeably with SYS-V clock IDs.

The path that is opened, whether /dev/ptpX or some new /dev/hwclkX etc
is a trivial detail that adds no burden to user space.

Thanks,
Richard

Thanks, Richard.

This might be true for applications using the POSIX clock API.
(However in practice there is also an ecosystem aspect: apps
and scripts assume /dev/ptpX explicitly, introducing a new
clock path can still incur real adoption/compatibility costs.)

More importantly, the existing ecosystem also relies on the
ioctl APIs (PTP_* ioctls).

Taking chrony as an example. For PHC refclock, chrony's PHC
handler (RCL_PHC_driver) explicitly relies on PTP ioctls[1],

e.g.,

ioctl(fd, PTP_SYS_OFFSET_PRECISE/PTP_SYS_OFFSET_EXTENDED/PTP_SYS_OFFSET, etc)

So a new clock type and APIs would require non-trivial userspace
changes. That would be a lengthy process of adaptation and tool
availability across different distributions. Similar problems
may also arise in other tools.

That's why this RFC is not proposing new userspace APIs.

[1] https://gitlab.com/chrony/chrony/-/blob/master/refclock_phc.c?ref_type=heads#:~:text=static%20int%20phc_poll,%7D

Regards.