linux-kernel - Re: [PATCH net-next v4] ptp: add Alibaba CIPU PTP clock driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <616e3d48-b449-401c-8c8b-501fce66c59d@lunn.ch>
Date: Sun, 17 Aug 2025 17:56:49 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Wen Gu <guwen@...ux.alibaba.com>
Cc: Jakub Kicinski <kuba@...nel.org>, richardcochran@...il.com,
	andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	pabeni@...hat.com, xuanzhuo@...ux.alibaba.com,
	dust.li@...ux.alibaba.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH net-next v4] ptp: add Alibaba CIPU PTP clock driver

On Sun, Aug 17, 2025 at 11:01:23AM +0800, Wen Gu wrote:
> 
> 
> On 2025/8/16 23:37, Andrew Lunn wrote:
> > > These sysfs are intended to provide diagnostics and informations.
> > 
> > Maybe they should be in debugfs if they are just diagnostics? You then
> > don't need to document them, because they are not ABI.
> > 
> > 	Andrew
> 
> Hi Andrew,
> 
> Thank you for the suggestion.
> 
> But these sysfs aren't only for developer debugging, some cloud components
> rely on the statistics to assess the health of PTP clocks or to perform
> corresponding actions based on the reg values. So I prefer to use the stable
> sysfs.

Doesn't this somewhat contradict what you said earlier:

   These sysfs are intended to provide diagnostics and informations.
   For users, interacting with this PTP clock works the same way as with other
   PTP clock, through the exposed chardev.

So users don't use just the standard chardev, they additionally need
sysfs.

Maybe take a step back. Do what Jakub suggested:

   Maybe it's just me, but in general I really wish someone stepped up
   and created a separate subsystem for all these cloud / vm clocks.
   They have nothing to do with PTP. In my mind PTP clocks are simple
   HW tickers on which we build all the time related stuff. While this
   driver reports the base year for the epoch and leap second status
   via sysfs.

Talk with the other cloud vendors and define a common set of
properties, rather than each vendor having their own incompatible set.

OS 101: the OS is supposed to abstract over the hardware to make
different hardware all look the same.

	Andrew