Re: rpctrace output improvements?

[Samuel Thibault]

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