Re: [PATCH] clocksource: Add debugfs support

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

On Tue, Mar 31, 2020 at 03:44:25PM -0700, John Stultz wrote:
> On Tue, Mar 31, 2020 at 3:25 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Tue, Mar 31, 2020 at 02:50:47PM -0700, John Stultz wrote:
> > > On Tue, Mar 31, 2020 at 2:40 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > Add a top-level "clocksource" directory to debugfs. For each clocksource
> > > > registered with the system, a subdirectory will be added with attributes
> > > > that can be queried to obtain information about the clocksource.
> > > >
> > >
> > > Curious, what's the need/planned use for this?  I know in the past
> > > folks have tried to get timekeeping internals exported to userland so
> > > they could create their own parallel userland timekeeping system,
> > > which I worry is a poor idea.
> >
> > This was meant to be purely for debugging purposes. That is as an easy
> > way to check that the code was working and that the counter is properly
> > updated.
> >
> > I certainly wasn't planning on implementing any userland on top of this.
> > Well, I guess it could be useful to use these values in test scripts
> > perhaps, since one of the clock sources exposed by one of the drivers I
> > have been working on is used across Tegra SoCs for hardware
> > timestamping. For that it might be interesting to be able to compare
> > those timestamp snapshots to something that I can read from userspace
> > during testing.
> 
> So, other platforms do similar, but utilizing the ktime_get_snapshot()
> interface internally so drivers can share that SoC hardware
> timestamping logic and export that via driver interfaces in a cleanly
> abstracted way to userland, rather than exposing the timekeping
> internals.

The hardware timestamping functionality is going to be exposed by a
different driver. I was merely speculating that the debugfs interface
could be used to also read out the counter value for the TSC as a means
of correlating it to the values from the timestamping hardware. On
second thought that may not be very useful given the non-deterministic
delay between the hardware timestamp and the debugfs read.

Like I said, the original intent here was really only to make it easy to
inspect the clocksources. I can add more fields if that's deemed useful.
I can imagine that different engineers keep writing different test code
to verify clock sources and thought that this might be a good addition
to make this easier.

But if you have concerns that this might get abused for something
unintended I understand that, so if you think exposing this is a bad
idea, I'll just drop this patch.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]