architecture paper draft

[Frank Ch. Eigler]

Hi, Stephen -


> I've asked, but nobody has been able to give me a list of what you're
> wanting to actually *do* here.  What are the important cases?  Have we
> got examples of the sorts of things we expect the users to want to do?

They include even basic things like system call tracing, where we
would want to pull out open(2) arguments.  We might like to poke
in the user process's stack, in order to compute a backtrace.

I can't enumerate every possibility that a user might dream up,
which is why having a general soft-fail mechanism that the probe
functions could use is so attractive.  

(There is also some confusion in my mind about how come in_interrupt()
is zero within kprobe functions, even though they're called from the
breakpoint int handler.  It's convenient, but I wonder if it has any
negative implications.)

> [...]
> Do you want probes to be able to access arbitrary process contexts?  Or
> just the current one?

Maybe.

> What about locks --- do you want to be able to access the memory deep
> inside locked sections of the kernel? [...]

Maybe, which suggests a need to enumerate all the possible locks that,
if held by someone else, would render access_process_vm() illegal, 
assuming that is a computable list at all.  If it were, then the probe
functions could test them all and abort early.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050214/2b965977/attachment.sig>