On 2025/8/17 23:56, Andrew Lunn wrote:

On Sun, Aug 17, 2025 at 11:01:23AM +0800, Wen Gu wrote:

quoted

On 2025/8/16 23:37, Andrew Lunn wrote:

quoted

quoted

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.

No, they are not contradictory.

For cloud users, they only need to use standard ptp chardev exposed to do time
operations. This is no different from using any other PTP clock.

The sysfs are used by Alibaba cloud's components that monitor the health and behavior
of the underlay device to ensure SLAs.

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.

IMHO, the abstraction has been done by PTP layer, e.g. struct ptp_clock_info,
struct ptp_clock and ptp_clock_{un}register(). For users, the PTP clock provide by
any vendors should be same in terms of usage, Alibaba Cloud is no exception.

But the specific implementation of underlay varies from ventor to ventor. Some depends
on ptp4l and NIC with IEEE 1588, some offload 1588 work to underlay infra and get
timestamps directly. I think it is difficult to require all vendors to provide the same
underlying attributes. Besides, Even the underlying implementation and properties are
different, it does not affect the user's use of them and the abstraction as PTP clocks.

Thanks!

	Andrew