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 -
> [...] Seriously, I believe that this is a fundamental safety We
> presumably won't crash any spacecraft, but we could crash a
> customer's system. Dtrace doesn't have to worry about this so much
> because the user is in a pretty tight straitjacket.
Please be more specific. Having implicitly declared and typed
systemtap variables poses a crash risk to the kernel how?
> > [...]
> > It seems to me that we are really missing only a few constructs:
> > - referring to variables in target space
> > - performing -> . [] on those pointer variables and related names
> > Does something else very useful come to mind?
>
> & lvalue
> * pointer
> functions calls -- to three types of functions:
> a) SystemTap auxiliary functions (as currently parsed)
> b) C functions in the context of the probed function
> c) C functions (set off by yacc/lex escapes such as %% or %{...%}) that
> are copied from the .stp file to the module's .c file.
That looks like way too generous. Can you provide motivation for each
of these constructs as really useful/necessary to a systemtap user?
They clearly toss the barn door wide open.
- 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] |