From: dave.long@linaro.org (David Long)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 00/15] uprobes: Add uprobes support for ARM
Date: Thu, 05 Dec 2013 15:17:46 -0500 [thread overview]
Message-ID: <52A0DF6A.1010402@linaro.org> (raw)
In-Reply-To: <529F6B88.2050005@linaro.org>
Masami/Tixy,
As I just noted in a previous email the kprobes.h thing has come back to
haunt me. Something more is needed in my last patchset. Tixy's
suggestion regarding the arch_specific_insn structure:
> However, I also wonder if we should instead leave arch_specific_insn as
> a kprobes specific structure and on ARM define it in terms of a new more
> generic 'struct probe_insn'? The drawback with that is that we'd
> probably end up with a struct just containing a single member which
> seems a bit redundant:
>
> struct arch_specific_insn {
> struct probe_insn pinsn;
> };
>
> Thought's anyone?
...got me thinking. When I do as he suggests and create a new
arch-specific structure for sharing between kprobes and uprobes then it
turns out simply #define'ing the arch_specific_insn structure tag to the
new structure tag in arch/arm/include/kprobes.h makes everything happy.
When KPROBES is not configured that include file is (still) not
included and the generic kprobes.h include file still continues to make
a dummy structure for it. My question is: Is it too hacky to use a
#define for a structure tag this way?
-dl
WARNING: multiple messages have this Message-ID (diff)
From: David Long <dave.long@linaro.org>
To: "Jon Medhurst (Tixy)" <tixy@linaro.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Taras Kondratiuk <taras.kondratiuk@linaro.org>,
linux-arm-kernel@lists.infradead.org,
Russell King <linux@arm.linux.org.uk>,
Rabin Vincent <rabin@rab.in>, Oleg Nesterov <oleg@redhat.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
davem@davemloft.net, Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
linux-kernel@vger.kernel.org,
Linaro Networking <linaro-networking@linaro.org>
Subject: Re: [PATCH v3 00/15] uprobes: Add uprobes support for ARM
Date: Thu, 05 Dec 2013 15:17:46 -0500 [thread overview]
Message-ID: <52A0DF6A.1010402@linaro.org> (raw)
In-Reply-To: <529F6B88.2050005@linaro.org>
Masami/Tixy,
As I just noted in a previous email the kprobes.h thing has come back to
haunt me. Something more is needed in my last patchset. Tixy's
suggestion regarding the arch_specific_insn structure:
> However, I also wonder if we should instead leave arch_specific_insn as
> a kprobes specific structure and on ARM define it in terms of a new more
> generic 'struct probe_insn'? The drawback with that is that we'd
> probably end up with a struct just containing a single member which
> seems a bit redundant:
>
> struct arch_specific_insn {
> struct probe_insn pinsn;
> };
>
> Thought's anyone?
...got me thinking. When I do as he suggests and create a new
arch-specific structure for sharing between kprobes and uprobes then it
turns out simply #define'ing the arch_specific_insn structure tag to the
new structure tag in arch/arm/include/kprobes.h makes everything happy.
When KPROBES is not configured that include file is (still) not
included and the generic kprobes.h include file still continues to make
a dummy structure for it. My question is: Is it too hacky to use a
#define for a structure tag this way?
-dl
next prev parent reply other threads:[~2013-12-05 20:17 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 2:53 [PATCH v3 00/15] uprobes: Add uprobes support for ARM David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 01/15] uprobes: allow ignoring of probe hits David Long
2013-11-27 2:53 ` David Long
2013-11-28 18:41 ` Oleg Nesterov
2013-11-28 18:41 ` Oleg Nesterov
2013-11-27 2:53 ` [PATCH v3 02/15] ARM: move shared uprobe/kprobe definitions into new include file David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 03/15] ARM: Move generic arm instruction parsing code to new files for sharing between features David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 04/15] ARM: move generic thumb instruction parsing code to new files for use by other feature David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 05/15] ARM: use a function table for determining instruction interpreter actions David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 06/15] ARM: Disable jprobes test when built into thumb-mode kernel David Long
2013-11-27 2:53 ` David Long
2013-11-27 10:16 ` Masami Hiramatsu
2013-11-27 10:16 ` Masami Hiramatsu
2013-11-27 10:41 ` Jon Medhurst (Tixy)
2013-11-27 2:53 ` [PATCH v3 07/15] ARM: Remove use of struct kprobe from generic probes code David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 08/15] ARM: Use new opcode type in ARM kprobes/uprobes code David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 09/15] ARM: Make the kprobes condition_check symbol names more generic David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 10/15] ARM: Change more ARM kprobes symbol names to something more David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 11/15] ARM: Rename the shared kprobes/uprobe return value enum David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 12/15] ARM: Change the remaining shared kprobes/uprobes symbols to something generic David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 13/15] ARM: Add an emulate flag to the kprobes/uprobes instruction decode functions David Long
2013-11-27 2:53 ` David Long
2013-11-27 2:53 ` [PATCH v3 14/15] ARM: add uprobes support David Long
2013-11-27 2:53 ` David Long
2013-12-04 17:23 ` Taras Kondratiuk
2013-12-04 17:23 ` Taras Kondratiuk
2013-11-27 2:53 ` [PATCH v3 15/15] ARM: Remove uprobes dependency on kprobes David Long
2013-11-27 2:53 ` David Long
2013-12-04 17:51 ` [PATCH v3 00/15] uprobes: Add uprobes support for ARM Taras Kondratiuk
2013-12-04 17:51 ` Taras Kondratiuk
2013-12-05 19:48 ` David Long
2013-12-05 19:48 ` David Long
2013-12-05 20:17 ` David Long [this message]
2013-12-05 20:17 ` David Long
2013-12-20 16:10 ` Jon Medhurst (Tixy)
2013-12-20 16:10 ` Jon Medhurst (Tixy)
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=52A0DF6A.1010402@linaro.org \
--to=dave.long@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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.