So it just prints "get the target path of link foo" instead of "readlink(foo)" and so on?
When I read the description I hoped it would match broad strokes like "load library foo.so" but the screenshot shows that it just rewords each syscall name into English.
I'm the author of the repo, your comment seems to paint a false picture of linux syscalls being "very easy" to decipher from their names, filesystem calls like readlink, mkdir, and chmod are unfortunately the exception and not the rule. A syscall which I consider one of the more simple syscalls and I'd point you towards is `madvise` whose action can be customized with over 18 different flags, some of these flags create effects, and some of them have a `dispelling` effect and their purpose is not that obvious from the name.
More complicated syscalls range from semi-decipherable with experience to entirely indecipherable, those syscalls will have arguments that can be a numbers/NULL/a pointer/the number -1, each with its own interpretation rules, some syscalls even have arguments that can be both a pointer or a numeric (int) depending on some other flag in a different argument, some syscalls have their entire logic encoded within multi-level structs like the `sigaction` syscall.
the value that can be derived from something like intentrace becomes apparent when you consider that a lot of programmers don't want to peruse the man pages and in the same time want to wield the power of strace, it allows programmers of every walk to be able to skim a strace-like feed very fast obtaining the optimal amount of information needed to know "what wen't wrong", "how does this binary work", etc..
Thank you and I hope you have an opportunity to notate with Brendan Gregg’s syscall ideas:
The first strace is on display at the Computer History Museum in San Jose. It was made in 1961 using wire wrapped circuitry and core memory, and could trace up to 12 system calls per second. Within its sheet metal enclosure are four seats: for the surgeon, co-pilot, and their two secretaries. It could stay submerged at syscall depth for up to 9 hours.
Yeah, it seems like it could be implemented as a postprocessor of strace --decode-fds. Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored (e.g. collecting /etc/localtime) and which are explicitly requested by the application, piecing together multi-threaded/multi-process logic, etc. strace has a lot of functions to help with that which this doesn't support, like syscall filtering, struct decoding, and stack tracing.
>Knowing what each syscall does isn't really the hard part of strace, it's knowing which ones are important, which ones are part of libc itself and can usually be ignored
An excellent point!
More broadly, since many/most Linux/Unix/etc, programs use one or more libraries (which in turn could use one or more other libraries, etc., etc.), then one very important key for designers of any type of strace program, present or future, is:
Can the traced system calls be set granularly, such that the individual libraries making syscalls (as opposed to the main program!) be identified individually, and possibly filtered in/out from the results accordingly?
Agreed, I'm a bit underwhelmed by intentrace when compared to the richness of strace. For sure, strace could maybe benefit from some UX like colorised output and a TUI that lets you filter syscalls while it is running.
When I read the description I hoped it would match broad strokes like "load library foo.so" but the screenshot shows that it just rewords each syscall name into English.