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: tapset taxonomy


Hi -


On Thu, Apr 14, 2005 at 08:21:33PM -0700, Chen, Brad wrote:
> [...]
> >Naturally, such power would be left to "guru-mode" users and to
> >privileged script "tapsets" located in a library.
>
> This notion of priviledged script "tapsets" in a tested and 
> trusted library is a critical one for me. [...]

Right, we agree.

> [...]
> >...  Those needing to interact
> >with future peculiar chunks of kernel (e.g., Brad's list of future
> >instrumentables) likely need to emit strange new C code to talk to
> >them, so need language and/or translator extensibility.
> >[...]
> 
> I think the list of mine you refer to above is this one:
> - hardware performance counters
> - power management hardware
> - virtualization technologies
> - strange new hardware to support multicore architectures

Yes.

> [...]  The library, language, and translator extensibility options
> you describe below sound like useful abstractions, but I don't see
> the justification for prohibition of C.

But there is no prohibition of C!  Rather, I try to identify where
custom C code would fit in.  For example, I would like to not see
general C code within scripts.  Instead, tapset-specific translator
extensions could emit custom C code when they process particular
script constructs (function or variable references).  The translator
logic is being designed to permit these kinds of hooks.


- FChE


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