public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Roland McGrath <roland@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	prasad@linux.vnet.ibm.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	David Gibson <dwgibson@au1.ibm.com>,
	Torez Smith <torez@us.ibm.com>
Subject: Re: [patch 02/11] x86 architecture implementation of Hardware Breakpoint interfaces
Date: Sat, 14 Mar 2009 14:51:06 +1100	[thread overview]
Message-ID: <1237002666.25062.85.camel@pasglop> (raw)
In-Reply-To: <20090312024617.3F392FC3B6@magilla.sf.frob.com>

On Wed, 2009-03-11 at 19:46 -0700, Roland McGrath wrote:
> 
> I think it would be illustrative to have a second arch implementation to
> compare to the x86 one.  Ingo has a tendency to pretend everything is an
> x86 until shown the concrete evidence.  The obvious choice is powerpc.
> Its facility is very simple, so the arch-specific part of the
> implementation should be trivial--it's the "base case" of simplest
> available hw_breakpoint arch, really.  Also, it happens that Prasad's
> employer is interested in having that support.
> 
> For example, a sensible powerpc implementation would clearly demonstrate
> why you need accessors or at least either pre-registration setters or
> explicit type/len arguments in registration calls.

Well, we happen to be just in the middle of implementing support for
BookE HW debug facilities :-) (which have more HW breakpoints &
watchpoints than server PPCs along with fancy features like ranged
breakpoints or value compare) so it's a right time to give that a try.

I'm Ccing David Gibson and Torez Smith who both have been working on the
infrastructure to control the debug regs. For now we are just giving
pretty much direct access to the debug regs from ptrace (since they are
somewhat architected they are very similar if not identical between a
whole bunch of embedded powerpc's) but a more abstract interface would
be nice.

Ben.



  parent reply	other threads:[~2009-03-14  3:52 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090305043440.189041194@linux.vnet.ibm.com>
2009-03-05  4:37 ` [patch 01/11] Introducing generic hardware breakpoint handler interfaces prasad
2009-03-10 13:50   ` Ingo Molnar
2009-03-10 14:19     ` Alan Stern
2009-03-10 14:50       ` Ingo Molnar
2009-03-11 12:57         ` K.Prasad
2009-03-11 13:35           ` Ingo Molnar
2009-03-05  4:38 ` [patch 02/11] x86 architecture implementation of Hardware Breakpoint interfaces prasad
2009-03-10 14:09   ` Ingo Molnar
2009-03-10 14:59     ` Alan Stern
2009-03-10 15:18       ` Ingo Molnar
2009-03-10 17:11         ` Alan Stern
2009-03-10 17:26           ` Ingo Molnar
2009-03-10 20:30             ` Alan Stern
2009-03-11 12:12               ` Ingo Molnar
2009-03-11 12:50                 ` K.Prasad
2009-03-11 13:10                   ` Ingo Molnar
2009-03-14  3:46                     ` Benjamin Herrenschmidt
2009-03-11 16:39                   ` Alan Stern
2009-03-11 16:32                 ` Alan Stern
2009-03-11 17:41                   ` K.Prasad
2009-03-14  3:47                     ` Benjamin Herrenschmidt
2009-03-14  3:43                 ` Benjamin Herrenschmidt
2009-03-14  3:41               ` Benjamin Herrenschmidt
2009-03-14  3:40             ` Benjamin Herrenschmidt
2009-03-12  2:46     ` Roland McGrath
2009-03-13  3:43       ` Ingo Molnar
2009-03-13 14:04         ` Alan Stern
2009-03-13 14:13           ` Ingo Molnar
2009-03-13 19:01             ` K.Prasad
2009-03-13 21:21               ` Alan Stern
2009-03-14 12:24                 ` Ingo Molnar
2009-03-14 16:10                   ` Alan Stern
2009-03-14 16:39                     ` Ingo Molnar
2009-03-14  3:51       ` Benjamin Herrenschmidt [this message]
2009-03-05  4:38 ` [patch 03/11] Modifying generic debug exception to use virtual debug registers prasad
2009-03-05  4:38 ` [patch 04/11] Introduce virtual debug register in thread_struct and wrapper-routines around process related functions prasad
2009-03-10 14:35   ` Ingo Molnar
2009-03-10 15:53     ` Alan Stern
2009-03-10 17:06       ` Ingo Molnar
2009-03-12  2:26     ` Roland McGrath
2009-03-05  4:38 ` [patch 05/11] Use wrapper routines around debug registers in processor " prasad
2009-03-05  4:40 ` [patch 06/11] Use virtual debug registers in process/thread handling code prasad
2009-03-10 14:49   ` Ingo Molnar
2009-03-10 16:05     ` Alan Stern
2009-03-10 16:58       ` Ingo Molnar
2009-03-10 17:07       ` Ingo Molnar
2009-03-10 20:10         ` Alan Stern
2009-03-11 11:53           ` Ingo Molnar
2009-03-05  4:40 ` [patch 07/11] Modify signal handling code to refrain from re-enabling HW Breakpoints prasad
2009-03-05  4:40 ` [patch 08/11] Modify Ptrace routines to access breakpoint registers prasad
2009-03-10 14:40   ` Ingo Molnar
2009-03-10 15:54     ` Alan Stern
2009-03-12  3:14     ` Roland McGrath
2009-03-05  4:41 ` [patch 09/11] Cleanup HW Breakpoint registers before kexec prasad
2009-03-10 14:42   ` Ingo Molnar
2009-03-05  4:41 ` [patch 10/11] Sample HW breakpoint over kernel data address prasad
2009-03-05  4:43 ` prasad
2009-03-05  4:43 ` [patch 11/11] ftrace plugin for kernel symbol tracing using HW Breakpoint interfaces prasad
2009-03-05  6:37   ` Frederic Weisbecker
2009-03-05  9:16     ` Ingo Molnar
2009-03-05 13:15       ` K.Prasad
2009-03-05 13:28         ` Ingo Molnar
2009-03-05 11:33     ` K.Prasad
2009-03-05 12:19       ` K.Prasad
2009-03-05 12:30         ` Frederic Weisbecker
2009-03-05 12:28       ` Frederic Weisbecker
2009-03-05 15:00     ` Steven Rostedt
2009-03-05 14:54   ` Steven Rostedt
     [not found] <20090307045120.039324630@linux.vnet.ibm.com>
2009-03-07  5:05 ` [Patch 02/11] x86 architecture implementation of Hardware " prasad
     [not found] <20090319234044.410725944@K.Prasad>
2009-03-19 23:48 ` K.Prasad
     [not found] <20090324152028.754123712@K.Prasad>
2009-03-24 15:25 ` K.Prasad

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=1237002666.25062.85.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=akpm@linux-foundation.org \
    --cc=dwgibson@au1.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=roland@redhat.com \
    --cc=stern@rowland.harvard.edu \
    --cc=torez@us.ibm.com \
    /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