The counter (or echo) tool should be like "hello world". If there's a bunch of ugly stuff in those examples, that means a minimal usage of our library by a client must include a bunch of ugly stuff. Right now I see three major problems:
ffi.rs -- includes all kinds of mysterious details like the particular names of trampolines (with long hex suffixes). The code cites this Rust issue, but is there really no way that this can be hidden from our user? I.e. can it be done by `tools_helper?
Counters code is not self contained.. it uses note_syscall which is hardcoded into the tools library, and further information is hard-coded into the tracer itself. We need to move to a strategy tools to define their state types, and the core systrace infrastructure to be agnostic to it (i.e. trait bounded polymorphism).
captured_syscall is implemented in place, rather than separating out individual syscalls of interest (which is fine for the counter tool, but not as good for others).
The last of these probably deserves its own issue to discuss. If the user wants to override just, say read/write, rather than building their own switch statement inside captured_syscall, and having an essentially untyped argument list, wouldn't it be better if they instead created a trait impl and defined only the read/write we're interested in? Furthermore, we would use more strongly typed signatures when doing so. The idea is that trait-provided methods would provide defaults, including the big fat captured_syscall definition which would have a giant switch statement dispatching to all the specific methods of the trait.
The counter (or echo) tool should be like "hello world". If there's a bunch of ugly stuff in those examples, that means a minimal usage of our library by a client must include a bunch of ugly stuff. Right now I see three major problems:
ffi.rs-- includes all kinds of mysterious details like the particular names of trampolines (with long hex suffixes). The code cites this Rust issue, but is there really no way that this can be hidden from our user? I.e. can it be done by `tools_helper?note_syscallwhich is hardcoded into the tools library, and further information is hard-coded into the tracer itself. We need to move to a strategy tools to define their state types, and the core systrace infrastructure to be agnostic to it (i.e. trait bounded polymorphism).captured_syscallis implemented in place, rather than separating out individual syscalls of interest (which is fine for the counter tool, but not as good for others).The last of these probably deserves its own issue to discuss. If the user wants to override just, say
read/write, rather than building their ownswitchstatement insidecaptured_syscall, and having an essentially untyped argument list, wouldn't it be better if they instead created a trait impl and defined only theread/writewe're interested in? Furthermore, we would use more strongly typed signatures when doing so. The idea is that trait-provided methods would provide defaults, including the big fatcaptured_syscalldefinition which would have a giant switch statement dispatching to all the specific methods of the trait.