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] |
On Mon, Apr 11, 2005 at 10:59:10PM -0700, Vara Prasad wrote:...
Maneesh Soni wrote:
I think synchronization should be left to the users of the probes rather than trying to complicate the interface with exclusive probes and non exclusive probes.
Indeed. That is exactly the point -- we can impose the requirement of verification on systemtap probes or multihandler probes in general, but changing all kprobes users to do this may not be appropriate. Simply keeping the same name of the interface and changing its semantics is potentially problematic.
kprobes is a simple low level interface - the only expectation on kprobes handlers today is ability to execute in interrupt context and not recurse into itself. Other than that, a handler is a kernel function - which can do whatever it wants ... it would be rather hard if not impossible to verify everything.
So, I can't see a way to make unrelated sets of users of probes to synchronize themselves :(
This is why having the higher level kprobe call chain (for want of a better
name), abstracted on top of kprobes made sense to me.
Could you explain the need for systemtap to takeover or insert additional handlers to existing kprobes in the system (potentially installed by other utilities or even by a kernel programmer for quick experimentation) a little more clearly ? Where did that requirement originate ? (I'm sorry I haven't really been following the design discussions on system tap)
Regards Suparna
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |