This is the mail archive of the
mailing list for the systemtap project.
Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code
- From: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- To: Roland McGrath <roland at redhat dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Denys Vlasenko <vda dot linux at googlemail dot com>, systemtap at sources dot redhat dot com, Christoph Hellwig <hch at infradead dot org>, Rusty Russell <rusty at rustcorp dot com dot au>, akpm at linux-foundation dot org, linux-kernel at vger dot kernel dot org
- Date: Thu, 25 Oct 2007 15:17:22 -0400
- Subject: Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code
- References: <email@example.com> <20070919113737.GA18177@Krystal> <firstname.lastname@example.org> <email@example.com> <20070921125819.GA13129@Krystal> <20070921133006.GF8964@redhat.com> <20070921133820.GD13129@Krystal> <20071015194120.GA22562@redhat.com> <20071015231209.GA18994@Krystal> <20071015235033.321E84D0389@magilla.localdomain>
* Roland McGrath (firstname.lastname@example.org) 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 %s
> name2 fs/nfs/nfs %d
> All the modules built by the same kernel build go into this one file.
> Modules packaged separately for the same kernel could provide additional
> files of the same kind.
> > I will soon come with a marker iterator and a module that provides a
> > userspace -and in kernel- interface to enable/disable markers. Actually,
> > I already have the code ready in my LTTng snapshots. I can provide a
> > link if you want to have a look.
> That's clearly straightforward to do given the basic markers data structures.
> It does not address the need for an offline list of markers available in a
> particular kernel build or set of modules that you are not running right now.
> The approach now available for that is grovelling through the markers data
> structures extracted from vmlinux and .ko ELF files offline. That is more
> work than one should have to do, and has lots of problems with coping with
> different packaging details, etc.
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 ?
I guess you must already need to extract the symbols for your kprobes.
Do you use kallsyms for this ? The way I see it, you could maybe extract
kallsyms symbols corresponding to the markers data structures quite
I would rather prefer not to implement superfluous built-time data
extraction in the kernel build system just to make userspace simpler. If
we can leverage what currently exists, that would be better.
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68