From: Thierry Reding <thierry.reding@gmail.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Stephen Boyd <sboyd@kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] clocksource: Add debugfs support
Date: Wed, 1 Apr 2020 00:25:35 +0200 [thread overview]
Message-ID: <20200331222535.GF2954599@ulmo> (raw)
In-Reply-To: <CALAqxLXD78StqLMuaGqHqhSfS9L2FBfNCm6yDyWMZT_7iNX-wQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-03-31 22:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 21:40 [PATCH] clocksource: Add debugfs support Thierry Reding
2020-03-31 21:50 ` John Stultz
2020-03-31 22:25 ` Thierry Reding [this message]
2020-03-31 22:44 ` John Stultz
2020-03-31 23:02 ` Thierry Reding
2020-03-31 22:06 ` Thomas Gleixner
2020-03-31 22:29 ` Thierry Reding
2020-03-31 22:49 ` Thierry Reding
2020-03-31 23:01 ` Thomas Gleixner
2020-03-31 23:06 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200331222535.GF2954599@ulmo \
--to=thierry.reding@gmail.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox