[Bug tapsets/14180] New: Reorganize the tapsets to accommodate different backends

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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.