This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: portability of scripts for Systemtap


Hi -


ezannoni wrote:

> [...]  What kind of compatibility are we going to support in
> systemtap for scripts that deal with kernel internals? I.e. the
> various versions of the kernels will probably modify their data
> structures etc internally between updates. [...]

I imagine addressing this by a variety of methods.


First is constructing a library of scripts (of the "script tapset"
flavour in the archpaper) that provide a more stationary target for
end-user scripts.  These would abstract, as much as kernel developers
advise is necessary, the particularly unstable or inscrutable portions
of the kernel, by giving fixed names for probe points, and a fixed
suite of data.  Version-ignorant end users would code to this higher
layer.


Second is specifying a search algorithm for these script tapsets that
allows multiple versions' worth of "adaptation layers" to coexist on a
single installation tree.  It might be something like a SYSTEMTAP_PATH
variable, along with a SYSTEMTAP_TRUSTED_PATH too, which list
directories.  Under those directories, systemtap would search for
script fragments satisfying a particular reference in a sequence of
subdirectories, something like this:

        kernel/$arch/$fullversion  (2.6.12.RHEL9+half.9482)
        kernel/$fullversion
        kernel/$arch/$mainversion  (2.6.12)
        kernel/$mainversion
        kernel/$arch/$family       (2.6)
        kernel/$family

This would allow each "adaptation layer" script to be individually
placed in as specific a spot as necessary.  (The classifications may
need to be broken down a little further, like SMP vs UP.  It might
come out looking like the gnu toolchain multilib search algorithm.)


Last is reliance on the translator to catch version drift problems, in
assuring that any script that makes references that just cannot be
satisfied against the selected kernel and the applicable library
scripts (be that a variance by version, architecture, whatever), the
translator will spit out errors.  There should be no possibility of a
silent failure of this kind.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]