Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock

[David Woodhouse]

On Mon, 2026-05-25 at 08:06 +0000, Arthur Kiyanovski wrote:
> Hi Thomas, David,

Thanks, Arthur.

> Thanks for the layout proposal, Thomas. The unified structure with 
> explicit valid flags is a much cleaner approach than bounds-based
> validation.
> 
> I'm the author of the PHC timestamp attributes series [1] that this
> applies to. Before I spin v4 based on this design, I want to confirm
> three implementation details:
> 
> 1. Counter IDs: No stable UAPI clocksource numbering exists today 
> (enum clocksource_ids is kernel-internal). I'll define stable constants
> in include/uapi/linux/ptp_clock.h (e.g., PTP_CSID_X86_TSC,
> PTP_CSID_ARM_ARCH) and map internal IDs in the chardev layer.

I think you'd already done a mapping like this to PTP_COUNTER_xxx,
hadn't you? Although at the time I thought you'd mapped it to the
VIRTIO_RTC_COUNTER_xxx and VMCLOCK_COUNTER_xxx values and now I see
they don't quite match up.

If I understood Thomas correctly, I think he meant that you should make
the kernel's actual CSID values into uapi (which would involve moving
the clocksource_ids.h file to include/uapi/). 

I think I did have a slight preference for keeping an explicit mapping,
and exposing only those CSIDs that we *intend* to expose to userspace
(maybe not CSID_X86_TSC_EARLY, or we might make that to
PTP_COUNTER_X86_TSC). But only if the number space does actually match
VMCLOCK and VIRTIO_RTC. 

I'm also *entirely* prepared to concede if Thomas really does want to
expose CSID values directly; that isn't a hill to die on.



> 2. Array sizing: The timestamps array will be fixed at PTP_MAX_SAMPLES (25)
> in the ioctl struct, not a flexible array, to keep
> copy_from_user/copy_to_user bounded.
> 
> 3. Ioctl numbers: Two separate ioctls (PTP_SYS_OFFSET_EXTENDED_ATTRS and
> PTP_SYS_OFFSET_PRECISE_ATTRS) sharing the same payload struct, matching
> existing PTP convention.
> 
> Arthur
> 
> [1] https://lore.kernel.org/netdev/20260515164033.6403-1-akiyano@xxxxxxxxxx/
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature