This is the mail archive of the systemtap@sourceware.org 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 -
Dave Nomura <dcnltc@us.ibm.com> writes:
I was thinking more along the lines of linking in an archive (*.a or
*.so) of C routines that could be shared between a SystemTap
implementation and a non-SystemTap implementation. [...]
Good point. I hadn't given these issues much thought. Perhaps the most reliable and easiest way of ensuring compatibilty is to #include of the embedded C source code as you suggested earlier. Is there a way to pass an -I<path> option to the module builder? I tried this but it didn't appear to work. Would I have to use INCLUDE_PATH?I can't think of a good reason not to permit additional .a/.o's to be included in a systemtap module. SOme issues:
- the .a/.o files need to be built to be perfectly compatible with
the target kernel. It is rare to do this via means other than
actually shipping sources and compiling them on the fly, which is
tantamount to the embedded-C method I already described.
- buildrun.cxx would have to be taught to include references to these libraries/objects in the module makefile
- licenses need to be compatible if the combined result is to be
distributed
- some headers will need to be shared too in order for the systemtap
code to be able to refer to the stuff in the .a/.o
- FChE
-- Dave Nomura LTC Linux Power Toolchain
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |