arch paper section on safety

[Chen, Brad]

The "other aspects" below are great; I will add them to the
next draft.

>> [...]
>> By default, kernel code cannot be invoked directly from a Systemtap 
>> script.  
>
>Not just by default: I am aware of no construct being contemplated...
I may be getting old but I thought I remembered a previous
discussion about the need to invoke any kernel routine as
a kernel debugging requirement. Perhaps that was in the 
context of kprobes rather than Systemtap? Vara, I'm 
remembering you as the main proponent. Care to comment?

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Thursday, April 07, 2005 6:18 PM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: arch paper section on safety

Hi -


brad.chen wrote:

> Before I check this in I was hoping to get through
> one round of review.

Looks good overall, within the context of the ongoing debate
about portals and static checkers.

> [...]
> By default, kernel code cannot be invoked directly from a Systemtap 
> script.  

Not just by default: I am aware of no construct being contemplated for
supporting invocation of kernel code from script.  Perhaps an abuse of
the "embedded C" idea, or of the dpcc expression string could do it,
but both of these are hypothetical and nonessential to the system.

> The Systemtap runtime can use kernel subroutines, and these
> references are assumed to be safe.

It may be informative to enumerate here certain other aspects of
safety, in terms of operating probes within the tight constraints
of the kernel:

- avoiding excessive usage of kernel stack by using explicitly
  synthesized frames in heap/static memory for probe local variables
- strictly terminating, nonblocking body code in probes
- no assumption of user context, as far as possible
- as little as possible dynamic memory allocation during probe
  operation


- FChE