SystemTap questions: user/kernel communication & pass compiilation options to module build

SystemTap questions: user/kernel communication & pass compiilation options to module build

[Dave Nomura]

I have a few general questions about SystemTap

1. is there any SystemTap mechanism that would allow a user program 
(invoked by the -c SystemTap option) to communicate with the generated 
SystemTap kernel module?  I am trying to port a kernel module to use 
SystemTap and it creates a  character device that the user program can 
use to communicate to the kernel module via ioctls.

2.  is there any way to pass options to the compilation of the SystemTap 
generated module code?  I was thinking that this would allow me to pass 
a library of kernel driver support routines that might otherwise live in 
SystemTaps runtimes/ directory.  Another use might be to pass -D define 
options.

Re: SystemTap questions: user/kernel communication & pass compiilation options to module build

[Frank Ch. Eigler]

Dave Nomura <dcnltc@us.ibm.com> writes:

> 1. is there any SystemTap mechanism that would allow a user program
> [...]

It's probably time to implement this old feature:
  http://sourceware.org/PR1154 
Communicating specifically with the "stap -c CMD" child could be built
on top of that.


> 2.  is there any way to pass options to the compilation of the
> SystemTap generated module code?  I was thinking that this would allow
> me to pass a library of kernel driver support routines that might
> otherwise live in SystemTaps runtimes/ directory.  Another use might
> be to pass -D define options.

You can already pass -D options.  If you want to include libraries of
embedded-C code, you can put it into a private tapset file, and cause
it to be pulled into the script compilation somehow.  Chances are you
will want to make some functions that are callable from script.  See
the tutorial <http://sourceware.org/systemtap/tutorial/node18.html>,
and realize that the embedded-C code can go into a separate file that
systemtap would search (see the -I option).

- FChE

Re: SystemTap questions: user/kernel communication & pass compiilation options to module build

[Dave Nomura]

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.  In my case 
PerformanceInspector contains a lot of code to support instruction 
tracing as well as some other tools on SuSe with a kernel module.  I 
think it is unlikely that the SystemTap communitiy will be interested in 
integrating all of this code into the runtimes/ area so I thought that 
if we can link the SystemTap generated kernel module against a 
PerformanceInspector archive we could satisfy both environments.
Frank Ch. Eigler wrote:
> Dave Nomura <dcnltc@us.ibm.com> writes:
>
>   
>
>
>   
>> 2.  is there any way to pass options to the compilation of the
>> SystemTap generated module code?  I was thinking that this would allow
>> me to pass a library of kernel driver support routines that might
>> otherwise live in SystemTaps runtimes/ directory.  Another use might
>> be to pass -D define options.
>>     
>
> You can already pass -D options.  If you want to include libraries of
> embedded-C code, you can put it into a private tapset file, and cause
> it to be pulled into the script compilation somehow.  Chances are you
> will want to make some functions that are callable from script.  See
> the tutorial <http://sourceware.org/systemtap/tutorial/node18.html>,
> and realize that the embedded-C code can go into a separate file that
> systemtap would search (see the -I option).
>
> - FChE
>   


-- 
Dave Nomura
LTC Linux Power Toolchain

Re: SystemTap questions: user/kernel communication & pass compiilation options to module build

[Frank Ch. Eigler]

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

You must not have meant .so, since kernel modules don't engage in
shared library linking.  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

Re: SystemTap questions: user/kernel communication & pass compiilation options to module build

[Dave Nomura]

Frank Ch. Eigler wrote:
> 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. [...]
>>     

>   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.
>   
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?
> - 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

Re: SystemTap questions: user/kernel communication & pass compiilation options to module build

[Frank Ch. Eigler]

Dave Nomura <dcnltc@us.ibm.com> writes:

> [...]  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?  [...]

Consider either using full-path includes
    %{ #include "/my/custom/file.c" %}
or literally copying the C/H code into embedded-C blocks.

Your usage scenario seems too unusual to justify first-class support
in the translator.  OTOH it'd be only a few lines of code.  Patches
welcome. :-)


- FChE