Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split

On 2026/6/2 16:04, David Woodhouse wrote:
> On Mon, 2026-06-01 at 21:20 -0700, Richard Cochran wrote:
>>
>> Still, I don't understand why these new (non-network related ) device
>> drivers can't be implemented in their own class using
>> posix_clock_register()
>> etc.
>>
>> Any of the useful bits (like sysfs interfaces) can be refactored out
>> of ptp_clock.c and shared as a common layer.
> 
> The key is that userspace wants to get snapshots of the reference clock
> either precisely synchronized with the system clock where possible, or
> sandwiched as closely together as possible with ABA readings of the
> system, reference, system clock.
> 
> Those *are* the PTP_SYS_OFFSET* ioctls, which tools like chrony already
> support with 'refclock PHC /dev/ptp…'.
> 
> I'm not sure how factoring those out into separate POSIX AUX clocks
> would help? I think they do want to present as /dev/ptp*.
> 

I agree. Both [1] and [2] independently support the same point:
chrony's PHC refclock relies on ptp-specific ioctls (in sys_linux.c [3]),
not just clock_gettime(), so the ioctl interface needs to stay.
A posix_clock-based class wouldn't provide that.

[1] https://lore.kernel.org/netdev/[email protected]/
[2] https://lore.kernel.org/all/vmwwnl3zv26lmmuqp2vqltg2fudalpc5jrw7k6ifg6l5cwlk3j@i7jm62zcsl67/
[3] https://gitlab.com/chrony/chrony/-/blob/master/sys_linux.c

> There is some extra stuff we want to do for "Precision RTCs" or
> whatever we're going to call them. They might actually have a known TAI
> offset, they might convey leap second indications, we might want to set
> the kernel's CLOCK_REALTIME from them at boot. And in the case of
> VMClock, I'm working on being able to clamp the kernel's timekeeping to
> it directly².
> 
> So maybe what we want is linux/drivers/phc, to host those read-only
> devices which know real time. They can provide a simplified
> implementation; maybe *only* a function like vmclock_get_crosststamp(),
> which is just called in various different permutations by the various
> different PTP methods.
> 
> The core linux/drivers/phc code would then handle the interface to the
> kernel's core timekeeping *and* wrap them to register a PTP device that
> existing userspace can understand. And deal with the kvmclock/TSC
> awfulness where needed.
> 
> How does that sound?
> 

I think a dedicated phc core would make the classification of read-only
clocks clearer, reducing ambiguity around where they belong. I assume
direct timekeeping integration would be optional, drivers providing
only a snapshot-based crosststamp would use /dev/ptpX alone, while the
timekeeping path would require additional capability (as vmclock provides)?

> 
> ² https://lore.kernel.org/all/[email protected]/
> 
> 
> 
> 
>