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

[David Woodhouse]

On Tue, 2026-03-24 at 11:46 +0800, Wen Gu wrote:
> 
> 
> On 2026/3/24 10:22, Jakub Kicinski wrote:
> > On Wed, 18 Mar 2026 15:33:30 +0800 Wen Gu wrote:
> > > +PTP EMULATED CLOCK SUPPORT
> > > +M:	Wen Gu <guwen@xxxxxxxxxxxxxxxxx>
> > > +M:	Xuan Zhuo <xuanzhuo@xxxxxxxxxxxxxxxxx>
> > > +L:	linux-kernel@xxxxxxxxxxxxxxx
> > > +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@xxxxxxxxxxxxxxxxx/

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.

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