Re: script safety - no outside calls

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


> >[...] By not support calls into kernel code you 
> >create a clean separation (at least conceptually) between kernel
> >code and systemtap code, and avoid invocation of instrumented 
> >kernel code by scripts.

> I don't agree that we should limit accessing kernel functions. If we
> do that, some of the common features kernel provides that we also
> need example dumpstack(), timestamp() etc we will end up duplicating
> the code, which i am sure no one likes. [...]

The translator will have direct control over the interface between the
compiled script and its environment.  I agree with Brad in that I
would expect very little to no actual call-type interaction from the
probes, for the reasons already mentioned.

There is only a small class of kernel functions that could
theoretically be exposed in an unrestricted way - those that operate
locklessly from all sorts of contexts, like printk(), or little struct
access macros.  Anything more complicated would have to be used along
with guard predicates if at all (think of our old friend
copy_from_user).

This is why figuring out a clean way of expressing the safe traversal
of target-side data structures in the scripting language is so
important.


> If some one wants to refer to kernel functions directly in the
> scripts we should let them do so.  [...]

How do you imagine a user specifying an arbitrary kernel function call
from within the script language?


- FChE

Attachment: pgp00000.pgp
Description: PGP signature