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

[Thomas Gleixner]

Arthur!

On Mon, May 25 2026 at 08:06, Arthur Kiyanovski wrote:
> On 2026-05-24 14:36:35+02:00, Thomas Gleixner wrote:
>> On Fri, May 22 2026 at 17:23, David Woodhouse wrote:
> 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.

Either that or we make the clocksource IDs part of UABI, which avoids
back and forth mapping.

> 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.

Why? If userspace allocates an array size of 10k then the kernel will
still only copy out PTP_MAX_SAMPLES entries.

If it allocates two and asks for 10, that's not a kernel problem when
adjacent data is overwritten. That's not any different from read(2) or
other syscalls which do what they are asked to.

> 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.

As I said, I have no strong opinion on that and that's a question to be
answered by user space people. I personally would prefer one just
because I'm lazy :)

Thanks,

        tglx