mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Jason Wessel <jason.wessel@windriver.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/6] x86: Allow the user not to build hw_breakpoints
Date: Thu, 14 Jul 2011 23:51:37 +0200	[thread overview]
Message-ID: <20110714215134.GB26786@somewhere.redhat.com> (raw)
In-Reply-To: <4E1F5EF3.6050601@zytor.com>

On Thu, Jul 14, 2011 at 02:26:11PM -0700, H. Peter Anvin wrote:
> On 07/14/2011 08:03 AM, Frederic Weisbecker wrote:
> > So that hw_breakpoints and perf can be not built on
> > specific embedded systems.
> 
> I want to emphasize I am very, very unhappy about this.  It should be
> possible to not build perf while still have breakpoints available...
> breakpoints are way more important than perf.

I know and that's a long term goal. I believe Will Deacon is currently working
on breakpoints to avoid archs to translate ptrace user arch input into perf generic
information (which afterward is eventually translated back to arch information).
This is a necessary first step to have a ptrace breakpoint implementation independant of
perf. Once we'll have that and all archs are converted to that new mode, we can work
toward having breakpoints not requiring perf to work.

Until we reach that point, it's still nice to have optable breakpoints. I think
it is a desired feature given the feedbacks I get from Prasad for example.
If that makes it possible to try a kernel without perf in x86, good too.

But this is not intended to be a solution of the breakpoint - perf dependency. That
dependency was a design mistake that needs more to be fixed.
We want to be able to have breakpoints without perf in the end. This just requires
deeper and longer term work that is currently in progress.

  reply	other threads:[~2011-07-14 21:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-14 15:03 [GIT PULL] hw_breakpoints updates Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 1/6] hw_breakpoints: Split hardware breakpoints config Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-07-14 21:26   ` H. Peter Anvin
2011-07-14 21:51     ` Frederic Weisbecker [this message]
2011-07-21  7:26     ` Ingo Molnar
2011-07-21 12:36       ` Peter Zijlstra
2011-07-21 13:03       ` Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 5/6] hw_breakpoints: Only force perf events if breakpoints are selected Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 6/6] hw_breakpoints: Drop remaining misplaced dependency on perf Frederic Weisbecker
  -- strict thread matches above, loose matches on Subject: below --
2011-05-24 21:52 [PATCH v2] hw_breakpoint: Let the user choose not to build it (and perf too) Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-04-27 16:59 [PATCH 0/6] hw_breakpoint: Let the user choose not to build it (and perf too) Frederic Weisbecker
2011-04-27 16:59 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-04-27 17:38   ` H. Peter Anvin
2011-04-27 18:26     ` Frederic Weisbecker
2011-04-27 19:10       ` Michael Bohan
     [not found]       ` <008d59a3-bd23-4cb3-8a73-1640137e3ac4@email.android.com>
2011-04-27 19:50         ` Frederic Weisbecker
2011-05-03 15:35           ` H. Peter Anvin
2011-05-03 23:12             ` Frederic Weisbecker
2011-05-03 23:40               ` H. Peter Anvin
2011-05-03 23:54                 ` Frederic Weisbecker
2011-05-03 23:56                   ` H. Peter Anvin
2011-05-04  0:13                     ` Frederic Weisbecker

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=20110714215134.GB26786@somewhere.redhat.com \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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

all inboxes | Powered by JetHome®