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: architecture paper draft


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

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]