Messages in this thread | | | Date | Wed, 1 Apr 2020 00:25:35 +0200 | From | Thierry Reding <> | Subject | Re: [PATCH] clocksource: Add debugfs support |
| |
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.
But that's about as far as I was planning on taking this. I agree that basing some userland timekeeping system on a debugfs interface sounds like a very bad idea.
Thierry [unhandled content-type:application/pgp-signature] | |