From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH] clocksource: arm_arch_timer: disable the evtstrm via the cmdline
Date: Mon, 20 Jun 2016 14:30:02 +0100 [thread overview]
Message-ID: <20160620133001.GE29165@arm.com> (raw)
In-Reply-To: <5767E89F.5020809@linaro.org>
On Mon, Jun 20, 2016 at 02:59:11PM +0200, Daniel Lezcano wrote:
> On 06/20/2016 10:21 AM, Will Deacon wrote:
> >On Sun, Jun 19, 2016 at 10:08:38PM +0200, Daniel Lezcano wrote:
> >>On 06/17/2016 03:43 PM, Will Deacon wrote:
> >>
> >>[ Cc'ed tglx ]
> >>
> >>>Disabling the eventstream can be useful for debugging and development
> >>>purposes
> >>
> >>If it is for debugging and development, why upstream this change ?
> >
> >Mainly because it's desirable to be able to debug systems remotely, on
> >machines that you don't have direct access to and where recompiling the
> >kernel isn't necessarily an option. There are plenty of "no*" kernel
> >parameters already that fall into a similar category.
>
> if the kernel is in development and debug, why this option can't be part of
> debugging code ?
>
> If recompiling isn't an option, how this can be for "debugging and
> development" ?
Sorry, I wasn't very clear. The sort of use-case I'm envisaging is where
somebody is running a distro kernel on non-public hardware and sends me an
email about spinlock performance. Being able to disable the event stream
easily is a powerful tool in the small box of remote debugging tools and
would be useful in pinning down things like missing events.
So when I say "development and debug" I'm really thinking about *remote*
debug via a user, and then potentially the subsequent development of a
patch.
> I'm not a big fan of the all the specific driver options for the kernel
> parameters. If there is a real need to disable some parts of a driver, it
> would be much more interesting to write a framework for that and then use it
> from arm_arch_timer, thus giving the other drivers the opportunity to
> provide the same feature.
Such a framework sounds horribly ill-specified and far beyond the scope
of the simple change I'm proposing here. Are you planning to submit
patches for this?
Will
next prev parent reply other threads:[~2016-06-20 13:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 13:43 [RFC PATCH] clocksource: arm_arch_timer: disable the evtstrm via the cmdline Will Deacon
2016-06-17 14:36 ` Mark Rutland
2016-06-20 1:28 ` Kefeng Wang
2016-06-19 20:08 ` Daniel Lezcano
2016-06-20 8:21 ` Will Deacon
2016-06-20 8:34 ` Marc Zyngier
2016-06-20 12:59 ` Daniel Lezcano
2016-06-20 13:27 ` Mark Rutland
2016-06-20 13:30 ` Will Deacon [this message]
2016-06-20 13:44 ` Mark Rutland
2016-06-20 13:30 ` Catalin Marinas
2016-06-27 14:44 ` Daniel Lezcano
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=20160620133001.GE29165@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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