On Tue, 2026-03-24 at 11:46 +0800, Wen Gu wrote:

On 2026/3/24 10:22, Jakub Kicinski wrote:

quoted

On Wed, 18 Mar 2026 15:33:30 +0800 Wen Gu wrote:

quoted

+PTP EMULATED CLOCK SUPPORT
+M:	Wen Gu [off-list ref]
+M:	Xuan Zhuo [off-list ref]
+L:	linux-kernel@vger.kernel.org
+S:	Maintained

I thought David W was supposed to be the main maintainer?
Two moderately known developers from a single vendor/company
is not enough to delegate this IMO.

Thanks for pointing this out.

We would also very much prefer for this area to be maintained
by people with deeper expertise in the clock/timekeeping domain
(such as David). The reason David was not listed in this version
is that an earlier attempt to ask about maintainership did not
receive a reply[1]. So we avoided adding without confirmation.

If David has no objections to being listed here, that would
definitely be preferable from our perspective. Other suggested
clock/timekeeping experts would also be very welcome.

[1]
https://lore.kernel.org/all/78489ff1-c2fa-47dc-beb4-54e9410f7d5c@linux.alibaba.com/ (local)

Apologies for missing that; yes I'm perfectly happy to be listed as a
maintainer. Thanks for checking.

Still mildly uncomfortable with 'emulated' as the word we chose for the
non-ieee1588 clocks, although there's only so much bikeshedding we can
do and it's ultimately cosmetic.

I see it more as precision RTCs which provide accurate CLOCK_REALTIME
(ideally including UTC not just TAI) — largely to virtual guests but
also on bare metal.

But as long as that's just a nitpick about what the directory is
called, and not an ongoing disagreement about which drivers land where,
I guess it doesn't matter much?

I don't actually want to see many new drivers added here. Going back to
what someone (Jakub?) said in a thread a while back about a pile of
cloud vendors' NIH cruft... I built the vmclock specification
deliberately to be vendor-agnostic and (I think) even implementable in
hardware with PCIe PTM, and I hope that we can consolidate on that and
stop inventing new crap.

https://uapi-group.org/specifications/specs/vmclock/

The next thing I want to do is make the kernel's timekeeping sync from
that as a proper feed-forward clock based on counter readings, instead
of the feedback adjustment that the current NTP hooks permit. And make
it possible to *export* the host's CLOCK_REALTIME to guests in vmclock
form.