This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/14180] New: Reorganize the tapsets to accommodate different backends
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 30 May 2012 02:08:53 +0000
- Subject: [Bug tapsets/14180] New: Reorganize the tapsets to accommodate different backends
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14180
Bug #: 14180
Summary: Reorganize the tapsets to accommodate different
backends
Product: systemtap
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: tapsets
AssignedTo: systemtap@sourceware.org
ReportedBy: jistone@redhat.com
Classification: Unclassified
As with bug #14179, we'll need some accommodation in the tapsets for different
backends, like the Dyninst backend of bug #14178. This matters most for
embedded-C functions which must assume kernel context. We can also separate
functions and aliases that make no sense in non-kernel context, or have no
feasible hooks to implement them (such as interrupts, scheduler, etc).
For the runtime, I suggested splitting the paths into distinct backends. I'm
less sure that this makes sense for tapsets, but it's a reasonable starting
point -- other ideas are welcome. So tapset/ would be neutral code, stuff like
strlen() and pp() that are generic or internal to stap. Then tapset/linux/
would hold kernel-specific tapset aliases and functions, and tapset/dyninst/
would be for the dyninst context. All three of these can have an $arch/
subdirectory as we do now.
Since we can't #ifdef and #include as in the runtime, the tapsets to use will
have to be decided by stap pass-1 instead, according to
systemtap_session::runtime_mode.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.