[lkml]   [2020]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 <> wrote:
> >
> > From: Thierry Reding <>
> >
> > 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

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.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2020-04-01 00:27    [W:0.077 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site