One of the things I'm starting to work on is adding support for your
kernel markers to systemtap. I know the marker stuff is still in a bit
of flux because you are trying to meet the (sometimes conflicting)
requirements of the people on lkml.
One of the things systemtap is going to need is to be able to parse the
'__markers' section so it will be able to look up a user-specified
marker. For instance, if the user says 'probe kernel.mark("foo") {}',
I've got to see if marker "foo" really exists.
There are 2 problems with this currently, since systemtap is a user-land
program:
1) include/linux/markers.h isn't currently installed by "make
headers_install"
2) even if include/linux/markers.h was installed, it is completely
surrounded by "#ifdef __KERNEL__"
So, I've attached a patch that tries to fix those 2 problems. I've
moved "#ifdef __KERNEL__" down a bit past the structure and flag
definitions and included marker.h in Kbuild so it will get installed.
I'd appreciate any comments you have. I'd like to get either this
patch or something like it included in the next version you post to lkml.
Signed-off-by: David Smith <[email protected]>
Signed-off-by: Mathieu Desnoyers <[email protected]>
---
include/linux/Kbuild | 1 +
include/linux/marker.h | 8 ++++----
2 files changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6-lttng/include/linux/marker.h
===================================================================
--- linux-2.6-lttng.orig/include/linux/marker.h 2007-05-09 18:15:55.000000000 -0400
+++ linux-2.6-lttng/include/linux/marker.h 2007-05-09 21:44:47.000000000 -0400
@@ -14,8 +14,6 @@
* See the file COPYING for more details.
*/
-#ifdef __KERNEL__
-
struct __mark_marker_data;
typedef void marker_probe_func(const struct __mark_marker_data *mdata,
@@ -35,8 +33,6 @@
void *enable;
} __attribute__((packed));
-#ifdef CONFIG_MARKERS
-
/* Marker flags : selects the mechanism used to connect the probes to the
* markers and what can be executed within the probes. This is primarily
* used at reentrancy-unfriendly sites. */
@@ -45,6 +41,10 @@
#define MF_PRINTK (1 << 2) /* vprintk can be called in the probe */
#define _MF_NR 3 /* Number of marker flags */
+#ifdef __KERNEL__
+
+#ifdef CONFIG_MARKERS
+
/* Generic marker flavor always available */
#define trace_mark_generic(flags, name, format, args...) \
do { \
Index: linux-2.6-lttng/include/linux/Kbuild
===================================================================
--- linux-2.6-lttng.orig/include/linux/Kbuild 2007-05-09 21:41:55.000000000 -0400
+++ linux-2.6-lttng/include/linux/Kbuild 2007-05-09 21:46:07.000000000 -0400
@@ -254,6 +254,7 @@
unifdef-y += llc.h
unifdef-y += loop.h
unifdef-y += lp.h
+unifdef-y += marker.h
unifdef-y += mempolicy.h
unifdef-y += mii.h
unifdef-y += mman.h
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
On Wed, May 09, 2007 at 09:55:58PM -0400, Mathieu Desnoyers wrote:
> One of the things I'm starting to work on is adding support for your
> kernel markers to systemtap. I know the marker stuff is still in a bit
> of flux because you are trying to meet the (sometimes conflicting)
> requirements of the people on lkml.
>
> One of the things systemtap is going to need is to be able to parse the
> '__markers' section so it will be able to look up a user-specified
> marker. For instance, if the user says 'probe kernel.mark("foo") {}',
> I've got to see if marker "foo" really exists.
NACK. This shouldn't be includedable from userspace and systemtap people
should stop doing crap like that but use kernel infrastructure everyone
else uses including runtime kernel code instead of stuffin all kinds of
crap into their broken translator.
Christoph Hellwig wrote:
> NACK. This shouldn't be includedable from userspace and systemtap people
> should stop doing crap like that but use kernel infrastructure everyone
> else uses including runtime kernel code instead of stuffin all kinds of
> crap into their broken translator.
Christoph,
I was using the above information to parse all the available markers in
a kernel, but I believe I've found a way where I don't need the marker.h
header, so I'm OK with your NACK.
Out of curiosity, what is the kernel infrastructure you believe I should
be using to get a list of all available markers in a kernel? Note that
I also have a requirement to get a list of all available markers in a
kernel that isn't the currently running one.
--
David Smith
[email protected]
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
On Thu, May 10, 2007 at 05:14:25PM -0500, David Smith wrote:
> Christoph Hellwig wrote:
> >NACK. This shouldn't be includedable from userspace and systemtap people
> >should stop doing crap like that but use kernel infrastructure everyone
> >else uses including runtime kernel code instead of stuffin all kinds of
> >crap into their broken translator.
>
> Christoph,
>
> I was using the above information to parse all the available markers in
> a kernel, but I believe I've found a way where I don't need the marker.h
> header, so I'm OK with your NACK.
>
> Out of curiosity, what is the kernel infrastructure you believe I should
> be using to get a list of all available markers in a kernel? Note that
> I also have a requirement to get a list of all available markers in a
> kernel that isn't the currently running one.
None. Modules using markers should ship with the kernel or be written
on deman and not beeing created by some unreliable parser.
O> > Out of curiosity, what is the kernel infrastructure you believe I should
> > be using to get a list of all available markers in a kernel? Note that
> > I also have a requirement to get a list of all available markers in a
> > kernel that isn't the currently running one.
>
> None. Modules using markers should ship with the kernel or be written
> on deman and not beeing created by some unreliable parser.
And what do you think should happen in the real world instead of
Christoph fantasy land ?
Getting the marker exports right is what is needed to avoid having an
unreliable parser and ending up with a reliable one.
Or would you rather someone loaded a JVM into kernel space so it was
"shipped with the kernel"
Alan
On Sat, Jun 23, 2007 at 10:25:15AM +0100, Alan Cox wrote:
> Getting the marker exports right is what is needed to avoid having an
> unreliable parser and ending up with a reliable one.
>
> Or would you rather someone loaded a JVM into kernel space so it was
> "shipped with the kernel"
You're totall missing the point here. We're talking about kernel internal
interface, and the point for them has always been not to care about out
of tree users. There is no relation to anything involving a JVM here.
On Sat, 23 Jun 2007 10:32:09 +0100
Christoph Hellwig <[email protected]> wrote:
> On Sat, Jun 23, 2007 at 10:25:15AM +0100, Alan Cox wrote:
> > Getting the marker exports right is what is needed to avoid having an
> > unreliable parser and ending up with a reliable one.
> >
> > Or would you rather someone loaded a JVM into kernel space so it was
> > "shipped with the kernel"
>
> You're totall missing the point here. We're talking about kernel internal
> interface, and the point for them has always been not to care about out
> of tree users. There is no relation to anything involving a JVM here.
Of course there is Christoph.
If you have a system which generates and loads modules then they can't be
in tree (as they don't exist except transiently). On the other hand if it
outputs java byte codes then a JVM to process them can be in tree. It
would be a stupid solution to the problem but you appear to be objecting
to sane ones.
The system to create the dynamic modules could certainly be in-tree but to
argue that code dynamically created should be "in tree" already is a
bit silly really isn't it ?
A second way of point out your argument is totally and utterly bogus
would be the MODULE_ interface. The modutils are clearly out of tree
users.
So whats the difference between modutils and markers ? Would it suddenely
change if modutils developed modinfo --dump-markers ?
Alan
On Sat, Jun 23, 2007 at 10:49:05AM +0100, Alan Cox wrote:
> The system to create the dynamic modules could certainly be in-tree but to
> argue that code dynamically created should be "in tree" already is a
> bit silly really isn't it ?
I never argued that. Creating them intree is equivalent to having the
generated modules in tree for all purposes related to interface stability.
The important bit is that we should not even pretend to allow external
users that we keep a tiny part of the interface stable while the major
part isn't.
On Sat, 23 Jun 2007 11:06:00 +0100
Christoph Hellwig <[email protected]> wrote:
> On Sat, Jun 23, 2007 at 10:49:05AM +0100, Alan Cox wrote:
> > The system to create the dynamic modules could certainly be in-tree but to
> > argue that code dynamically created should be "in tree" already is a
> > bit silly really isn't it ?
>
> I never argued that. Creating them intree is equivalent to having the
> generated modules in tree for all purposes related to interface stability.
So if all the applications using markers are shoved into the kernel
source tree you are happy, and if they are distributed elsewhere you are
not ?
Or do you want a single controlled 'with the kernel' tool for doing the
outputting which alone has close links with the kernel (ie modinfo
--dump-markers) or similar ?