Hello,
Sergey Bugaev, le mer. 12 mai 2021 20:37:55 +0300, a ecrit:
> 111<--144(pid1004)->dir_lookup ("proc/loadavg" 1 0) = 0 1 "loadavg"
> 163<--162(pid1004)
> task133(pid1004)->mach_port_mod_refs (pn{ 21} 0 1) = 0
> 163<--162(pid1004)->dir_lookup ("loadavg" 1 0) = 0 1 ""
> 165<--158(pid1004)
>
> I was thinking it could look like this instead (mock-up):
>
> dir_lookup (file 111 (/), "proc/loadavg", O_READ, 0) -> FS_RETRY_NORMAL,
> "loadavg", file 163 (/proc)
> mach_port_mod_refs (task 133 (pid 1004), pn 21, MACH_PORT_RIGHT_SEND, 1) =
> KERN_SUCCESS
> dir_lookup (file 163 (/proc), "loadavg", O_READ, 0) -> FS_RETRY_NORMAL, "",
> file 165 (/proc/loadavg)
>
> The few changes I've made here are:
> * Moved the request port into the parens, like in C and MIG
Yes, I understand that it was meant to make RPCs look like a method, but
this is quite surprising when the caller *and* the callee actually have
the object as first parameter, it looks better to me to have it as first
argument.
> * Added commas
That would be also less surprising.
> * Dropped the 0 return code, except when there are no out params
That, however looks surprising when strace always put it, I would say
keep it.
> * Replaced = with -> for denoting out params
"->" seems useful indeed, but I'd say still keep the return code:
dir_lookup (file 111 (/), "proc/loadavg", O_READ, 0) = 0 -> FS_RETRY_NORMAL,
"loadavg", file 163 (/proc)
> * Symbolicated flags and file paths (potentially, also proc and auth handles)
Yes, that's the most useful part. It'd probably mean introducing types
here and there, but that'd be a really good thing to do.
For file path it'll probably be much harder since there can be several
path (or even no path!) for a given file port.
> * Some other misc tweaks to how ports are represented
The port type is useful indeed and is most often available in the types
already.
> P. S. There are other interesting features that we could copy from
> strace, such as dynamically attaching to a process
There has been some work on this at some point, I don't remember which
keywords to look for in the list history.
> tracing a subset of all calls (maps very well to different RPC
> subsystems),
Yes filtering would be welcome.
> and injecting errors (very useful for testing all error handling code
> paths).
That's probably a bit tricky to express.
Samuel
