Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices using the /dev/ptpX API

[Wen Gu <guwen@linux.alibaba.com>]

On 2026/1/13 12:21, Richard Cochran wrote:
> On Fri, Jan 09, 2026 at 10:56:56AM +0800, Wen Gu wrote:
> 
>> 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.