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] |
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] |