Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-10-26 Thread Frank Ch. Eigler
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 requi

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-10-25 Thread Mathieu Desnoyers
* 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 v

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-10-15 Thread Roland McGrath
> 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 mo

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-10-15 Thread Mathieu Desnoyers
* 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

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-10-15 Thread Frank Ch. Eigler
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 with

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-21 Thread Mathieu Desnoyers
* 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)

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-21 Thread Mathieu Desnoyers
* 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 s

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-21 Thread Frank Ch. Eigler
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 System

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-21 Thread Christoph Hellwig
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 cate

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-21 Thread Mathieu Desnoyers
* 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

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-20 Thread Steven Rostedt
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)->

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-19 Thread Denys Vlasenko
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 user

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-19 Thread Frank Ch. Eigler
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

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-19 Thread Mathieu Desnoyers
* 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 > > > > ==

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-19 Thread Mathieu Desnoyers
* 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 > > > === > > > --- linux-2.6-lttng.orig/include/asm-generic/vm

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-19 Thread Denys Vlasenko
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 -040

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-09-19 Thread Mathieu Desnoyers
* 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. >

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-08-25 Thread Mathieu Desnoyers
* 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_

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-08-25 Thread Rusty Russell
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 = st

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-08-24 Thread Mathieu Desnoyers
* 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

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

2007-08-20 Thread Rusty Russell
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 l