search

reverie-rs / reverie

trace and intercept linux syscalls.
Other
14 stars 5 forks source link

systrace server #39

Open wangbj opened 5 years ago

wangbj commented 5 years ago

It becomes more and more clear we need a systrace server, it can be a HTTP server on a unix domain socket, serving RESTful APIs. The motivations is sometimes it may make sense for tracee to notify tracer, such as report a given event happened, like sched_yield, the tracer (systrace) could then take actions based on certain events: when a tracee sent sched_yield event, the tracer know it can safely put the given task into idle/blocked queue. Performance related event is another example, they could change rapidly, and could have something like, process A has a syscall b patched successes at 2nd try at location libc.so+0xabcd, it is not that easy with shared pages because then we have to organize the memory layouts to fit into pre-allocated pages, rather than store them in key-value stores (such as hashmap).

rrnewton commented 5 years ago

So if we're defining the scope of systrace for now as "convert events to function calls" that narrow scope doesn't include anything about blocking/unblocking threads. (Though if some higher level instrumentation tool wants to do that, agreed that it would need communication between processes.)

But in this issue I believe you are arguing for IPC between the ptracer & the tracee even for the narrow purposes of patching & hooking. I'd like to understand that argument better. You give one such use case wrt performance hints, but I don't fully understand that example.

wangbj commented 5 years ago

Performance (counter?) related events are the ones you mentioned in #37, it hard to fit them in a page because many of them are dynamic views on bunch of (different) event sources