All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Maneesh Soni <maneesh@linux.vnet.ibm.com>,
	srinivasa@in.ibm.com, Jim Keniston <jkenisto@us.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Masami Hiramatsu <hiramatu@sdl.hitachi.co.jp>,
	Rusty Lynch <rusty.lynch@intel.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>
Subject: Re: FInal kprobes rollup patches
Date: Mon, 17 Dec 2007 15:27:33 -0800	[thread overview]
Message-ID: <1197934053.23402.124.camel@brick> (raw)
In-Reply-To: <476702C4.8070205@redhat.com>

On Mon, 2007-12-17 at 18:14 -0500, Masami Hiramatsu wrote:
> Hi Harvey,
> 
> Harvey Harrison wrote:
> > On Mon, 2007-12-17 at 16:52 -0500, Masami Hiramatsu wrote:
> >> Hi Harvey,
> >> Before porting, could you tell me what differences are important
> >> to you? We can discuss about it.
> > 
> > I've already ported it and sent it to you.  It's not really important to
> > me I just think my fine-grained patches may be of some use to see where
> > the differences between X86_32/64 ended up being.  Your patches end up
> > being just about entirely removal of ifdefs when rebased onto my
> > patches, so it's at least a good secondary check of your patches even
> > if mine don't go in.  Your patches end up being much smaller against
> > my version too.
> 
> OK, I'll review that.
> 
> >
> > I like my version slightly better because the remaining ifdefs (wrmsr,
> > etc) and others could be done in a few more small patches that are more
> > easily reviewable than your large final unification patch.
> 
> I agreed that your patches are including some goodness.
> So let us merge it into one.
> 
> 

OK, I'll take the last bits of your patches 5/6 that aren't already
cleaned up and send out a unified patchset for you to add your
acked/signed off by/reviewed by as appropriate.

These are:

-add stack_addr() macro
-I prefer the table defintion macros in mine as it avoids the need to
cast the pointer passed to test_bit, but if you want them
to be u32 as in your patch, I can change it.
-wrmsr/wrmsrl - use wrmsr() for both
-call is_IF_modifier with p->ainsn.insn in both
-check casting of jprobe_saved_sp, I get some compile warnings currently
with pointer comparisons to signed/unsigned types.

That will eliminate nearly all of the remaining ifdefs in my version,
let me work through this and I'll send out a set for review.

CHeers,

Harvey



  reply	other threads:[~2007-12-17 23:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-15  8:45 FInal kprobes rollup patches Harvey Harrison
2007-12-15  8:50 ` Ingo Molnar
2007-12-15  9:04   ` Harvey Harrison
2007-12-15 13:12     ` Ingo Molnar
2007-12-17 14:12       ` Srikar Dronamraju
2007-12-17 14:13       ` Masami Hiramatsu
2007-12-17 14:30         ` Final " Ingo Molnar
2007-12-17 15:29           ` Masami Hiramatsu
2007-12-17 16:06             ` Ingo Molnar
2007-12-17 16:19               ` Masami Hiramatsu
2007-12-17 20:17               ` Harvey Harrison
2007-12-17 14:22       ` FInal " Srikar Dronamraju
2007-12-17 19:20         ` Harvey Harrison
2007-12-17 21:28           ` Masami Hiramatsu
2007-12-17 21:36             ` Harvey Harrison
2007-12-17 21:52               ` Masami Hiramatsu
2007-12-17 22:00                 ` Harvey Harrison
2007-12-17 23:14                   ` Masami Hiramatsu
2007-12-17 23:27                     ` Harvey Harrison [this message]
2007-12-17 23:56                       ` Masami Hiramatsu
2007-12-18  0:27                         ` Masami Hiramatsu
2007-12-18  2:15                           ` Harvey Harrison
2007-12-18  3:10                           ` [PATCH] x86: kprobes use stack_addr() macro Harvey Harrison

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=1197934053.23402.124.camel@brick \
    --to=harvey.harrison@gmail.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=hiramatu@sdl.hitachi.co.jp \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@linux.vnet.ibm.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=rusty.lynch@intel.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=srinivasa@in.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.