Hi -
On Thu, Oct 25, 2007 at 03:17:22PM -0400, Mathieu Desnoyers wrote:
> [...]
> Since gcc is required to build the systemtap probes on the development
> marchine, I don't see why it would be much harder to also require prople
> to install drawf ? Or maybe the "crash" tool ?
The crash tool
Hi -
On Thu, Oct 25, 2007 at 03:17:22PM -0400, Mathieu Desnoyers wrote:
[...]
Since gcc is required to build the systemtap probes on the development
marchine, I don't see why it would be much harder to also require prople
to install drawf ? Or maybe the crash tool ?
The crash tool requires
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> > I think the main issue with the solution you propose is that it doesn't
> > deal with markers in modules, am I right ?
>
> My suggestion applies as well to modules as anything else.
> What "like Module.symvers" means is something like:
>
> name1
* Roland McGrath ([EMAIL PROTECTED]) wrote:
I think the main issue with the solution you propose is that it doesn't
deal with markers in modules, am I right ?
My suggestion applies as well to modules as anything else.
What like Module.symvers means is something like:
name1 vmlinux
> I think the main issue with the solution you propose is that it doesn't
> deal with markers in modules, am I right ?
My suggestion applies as well to modules as anything else.
What "like Module.symvers" means is something like:
name1 vmlinux %s
name2 fs/nfs/nfs %d
All the
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
> Hi -
>
> I wrote:
>
> > [...]
> > > The marker metadata must be stored in at least one place in the kernel
> > > image - this just happens to be a convenient one that David Smith's
> > > recent systemtap code used. Without it, we'd probably have
Hi -
I wrote:
> [...]
> > The marker metadata must be stored in at least one place in the kernel
> > image - this just happens to be a convenient one that David Smith's
> > recent systemtap code used. Without it, we'd probably have to do a
> > more complicated search, following the pointers
Hi -
I wrote:
[...]
The marker metadata must be stored in at least one place in the kernel
image - this just happens to be a convenient one that David Smith's
recent systemtap code used. Without it, we'd probably have to do a
more complicated search, following the pointers within the
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
Hi -
I wrote:
[...]
The marker metadata must be stored in at least one place in the kernel
image - this just happens to be a convenient one that David Smith's
recent systemtap code used. Without it, we'd probably have to do a
more
I think the main issue with the solution you propose is that it doesn't
deal with markers in modules, am I right ?
My suggestion applies as well to modules as anything else.
What like Module.symvers means is something like:
name1 vmlinux %s
name2 fs/nfs/nfs %d
All the
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> On Tue, Sep 18, 2007 at 05:13:25PM -0400, Mathieu Desnoyers wrote:
> > +/*
> > + * Sets the probe callback corresponding to one marker.
> > + */
> > +static int set_marker(struct marker_entry **entry,
> > + struct __mark_marker *elem)
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
> Hi -
>
> On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
> > [...]
> > > > Current systemtap marker support code relies on the __markers_strings
> > > > section.
> > > Let users know that in comment above section definition in ld
Hi -
On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
> [...]
> > > Current systemtap marker support code relies on the __markers_strings
> > > section.
> > Let users know that in comment above section definition in ld script.
> [...]
> /* Markers: strings (used by
On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
> Ok, I am changing it to:
As I mentioned before pleae just kill this gunk entirely as it's not needed
at all intree. markers are already getting far too complex, I'd rather
want a simple useable version in now than trying to
* Denys Vlasenko ([EMAIL PROTECTED]) wrote:
> On Wednesday 19 September 2007 14:53, Frank Ch. Eigler wrote:
> > Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> >
> > > [...] Do you think I should also remove the __markers_strings
> > > section from here ?
> >
> > Current systemtap marker
* Denys Vlasenko ([EMAIL PROTECTED]) wrote:
On Wednesday 19 September 2007 14:53, Frank Ch. Eigler wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
[...] Do you think I should also remove the __markers_strings
section from here ?
Current systemtap marker support code relies on
On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
Ok, I am changing it to:
As I mentioned before pleae just kill this gunk entirely as it's not needed
at all intree. markers are already getting far too complex, I'd rather
want a simple useable version in now than trying to
Hi -
On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
[...]
Current systemtap marker support code relies on the __markers_strings
section.
Let users know that in comment above section definition in ld script.
[...]
/* Markers: strings (used by SystemTAP) */
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
Hi -
On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
[...]
Current systemtap marker support code relies on the __markers_strings
section.
Let users know that in comment above section definition in ld script.
[...]
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Tue, Sep 18, 2007 at 05:13:25PM -0400, Mathieu Desnoyers wrote:
+/*
+ * Sets the probe callback corresponding to one marker.
+ */
+static int set_marker(struct marker_entry **entry,
+ struct __mark_marker *elem)
+{
+
On Tue, Sep 18, 2007 at 05:13:25PM -0400, Mathieu Desnoyers wrote:
> +/*
> + * Sets the probe callback corresponding to one marker.
> + */
> +static int set_marker(struct marker_entry **entry,
> + struct __mark_marker *elem)
> +{
> + int ret;
> +
On Tue, Sep 18, 2007 at 05:13:25PM -0400, Mathieu Desnoyers wrote:
+/*
+ * Sets the probe callback corresponding to one marker.
+ */
+static int set_marker(struct marker_entry **entry,
+ struct __mark_marker *elem)
+{
+ int ret;
+ BUG_ON(strcmp((*entry)-name,
On Wednesday 19 September 2007 14:53, Frank Ch. Eigler wrote:
> Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>
> > [...] Do you think I should also remove the __markers_strings
> > section from here ?
>
> Current systemtap marker support code relies on the __markers_strings
> section.
Let
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...] Do you think I should also remove the __markers_strings
> section from here ?
Current systemtap marker support code relies on the __markers_strings
section.
- FChE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> * Denys Vlasenko ([EMAIL PROTECTED]) wrote:
> > On Wednesday 19 September 2007 12:37, Mathieu Desnoyers wrote:
> > > > Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
> > > >
* Denys Vlasenko ([EMAIL PROTECTED]) wrote:
> On Wednesday 19 September 2007 12:37, Mathieu Desnoyers wrote:
> > > Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
> > > ===
> > > ---
On Wednesday 19 September 2007 12:37, Mathieu Desnoyers wrote:
> > Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
> > ===
> > --- linux-2.6-lttng.orig/include/asm-generic/vmlinux.lds.h 2007-09-14
> > 10:11:18.0
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> The marker activation functions sits in kernel/marker.c. A hash table is used
> to keep track of the registered probes and armed markers, so the markers
> within
> a newly loaded module that should be active can be activated at module load
> time.
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
The marker activation functions sits in kernel/marker.c. A hash table is used
to keep track of the registered probes and armed markers, so the markers
within
a newly loaded module that should be active can be activated at module load
time.
On Wednesday 19 September 2007 12:37, Mathieu Desnoyers wrote:
Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===
--- linux-2.6-lttng.orig/include/asm-generic/vmlinux.lds.h 2007-09-14
10:11:18.0 -0400
+++
* Denys Vlasenko ([EMAIL PROTECTED]) wrote:
On Wednesday 19 September 2007 12:37, Mathieu Desnoyers wrote:
Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===
---
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
* Denys Vlasenko ([EMAIL PROTECTED]) wrote:
On Wednesday 19 September 2007 12:37, Mathieu Desnoyers wrote:
Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===
---
Mathieu Desnoyers [EMAIL PROTECTED] writes:
[...] Do you think I should also remove the __markers_strings
section from here ?
Current systemtap marker support code relies on the __markers_strings
section.
- FChE
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Wednesday 19 September 2007 14:53, Frank Ch. Eigler wrote:
Mathieu Desnoyers [EMAIL PROTECTED] writes:
[...] Do you think I should also remove the __markers_strings
section from here ?
Current systemtap marker support code relies on the __markers_strings
section.
Let users know
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Fri, 2007-08-24 at 12:26 -0400, Mathieu Desnoyers wrote:
> > * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > > On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
> > > > +{
> > > > + struct hlist_head *head;
> > > > + struct
On Fri, 2007-08-24 at 12:26 -0400, Mathieu Desnoyers wrote:
> * Rusty Russell ([EMAIL PROTECTED]) wrote:
> > On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
> > > +{
> > > + struct hlist_head *head;
> > > + struct hlist_node *node;
> > > + struct marker_entry *e;
> > > + size_t len =
On Fri, 2007-08-24 at 12:26 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
+{
+ struct hlist_head *head;
+ struct hlist_node *node;
+ struct marker_entry *e;
+ size_t len = strlen(name) + 1;
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Fri, 2007-08-24 at 12:26 -0400, Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
+{
+ struct hlist_head *head;
+ struct hlist_node *node;
+
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
> > The marker activation functions sits in kernel/marker.c. A hash table is
> > used
> > to keep track of the registered probes and armed markers, so the markers
> > within
> > a newly
* Rusty Russell ([EMAIL PROTECTED]) wrote:
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
The marker activation functions sits in kernel/marker.c. A hash table is
used
to keep track of the registered probes and armed markers, so the markers
within
a newly loaded module
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
> The marker activation functions sits in kernel/marker.c. A hash table is used
> to keep track of the registered probes and armed markers, so the markers
> within
> a newly loaded module that should be active can be activated at module
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
The marker activation functions sits in kernel/marker.c. A hash table is used
to keep track of the registered probes and armed markers, so the markers
within
a newly loaded module that should be active can be activated at module load
42 matches
Mail list logo
