Re: [PATCH 1/3] Make struct jprobe.entry a void *
On Tue, 2007-06-26 at 09:29 +0530, Ananth N Mavinakayanahalli wrote: > On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote: > > --- > > > > It isn't obvious where kprobes patches should go, is anyone "the" > > maintainer? > > Instead I've just sent this to everyone who'd touched the code lately, or > > might be otherwise interested. > > There isn't a single maintainer for the kprobes infrastructure as it > contains quite a bit of low level arch specific code. The working model > currently is that the patches are sent to lkml with a cc to the > maintainers listed, as you've rightly done. OK, no worries. I guess that's a bit messy to put into a MAINTAINERS entry. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] Make struct jprobe.entry a void *
On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote: > --- > > It isn't obvious where kprobes patches should go, is anyone "the" maintainer? > Instead I've just sent this to everyone who'd touched the code lately, or > might be otherwise interested. There isn't a single maintainer for the kprobes infrastructure as it contains quite a bit of low level arch specific code. The working model currently is that the patches are sent to lkml with a cc to the maintainers listed, as you've rightly done. Ananth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Make struct jprobe.entry a void *
On Tue, Jun 26, 2007 at 11:48:50AM +1000, Michael Ellerman wrote: > Currently jprobe.entry is a kprobe_opcode_t *, but that's a lie. On some > platforms it doesn't point to an opcode at all, it points to a function > descriptor. > > It's really a pointer to something that the arch code can turn into a > function entry point. And that's what actually happens, none of the > generic code ever looks at jprobe.entry, it's only ever dereferenced > by arch code. > > So just make it a void *. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Tested on powerpc. Ack to all three patches plus Andrew's declaration fixup. Thanks Michael for the patches. Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> > --- > > It isn't obvious where kprobes patches should go, is anyone "the" maintainer? > Instead I've just sent this to everyone who'd touched the code lately, or > might be otherwise interested. > > > include/linux/kprobes.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h > index 23adf60..f4e53b7 100644 > --- a/include/linux/kprobes.h > +++ b/include/linux/kprobes.h > @@ -116,7 +116,7 @@ struct kprobe { > */ > struct jprobe { > struct kprobe kp; > - kprobe_opcode_t *entry; /* probe handling code to jump to */ > + void *entry;/* probe handling code to jump to */ > }; > > DECLARE_PER_CPU(struct kprobe *, current_kprobe); > -- > 1.5.1.3.g7a33b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/