Re: rpctrace output improvements?

[Sergey Bugaev]

On Wed, May 12, 2021 at 11:48 PM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> It'd probably mean introducing types
> here and there, but that'd be a really good thing to do.
>
> The port type is useful indeed and is most often available in the types
> already.

Oh, do you mean the types specified in .defs? If so, the problem is
rpctrace doesn't read those, it only reads the msgids files, which
contain lines like this:

fs 20000 dir_lookup 18 20018 20118

(meaning, subsystem fs whose base msgid is 20000, routine name is
dir_lookup, msgid relative to subsystem base is 18, absolute msgid is
20018, reply msgid is 20118). There are no types in there.

So either:
* rpctrace has to learn to parse defs, instead of (or in addition to) msgids
* GNU MIG needs to be taught to emit more info into msgids files
* rcptrace itself would hardcode knowledge of signatures of some common RPCs

My plan has been the latter, since there likely aren't that many RPCs
that need specific treatment, and since rpctrace already knows to
treat some RPCs (slightly) specially.

But perhaps you would recommend something else? Or did you mean
something else entirely?

On Thu, May 13, 2021 at 12:15 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> > And as far as I can see, there's no RPC to get the parent directory of
> > a file.
>
> Sure since the file can be hardlinked from various places.

Yes; but other systems manage to still make this work. E.g. on my GNU/Linux box:

$ touch foo
$ ln foo bar
$ ls -l /proc/self/fd/{3,4} 3>foo 4>bar
l-wx------. 1 sergey sergey 64 May 13 14:59 /proc/self/fd/3 -> /tmp/foo
l-wx------. 1 sergey sergey 64 May 13 14:59 /proc/self/fd/4 -> /tmp/bar

I don't know how this work in Linux; but in the SerenityOS kernel, an
open FileDescription keeps a reference to a Custody (an which is a
chain of Inode's + file names), which can then be used to recreate the
path the FileDescription has been opened through.

And the Hurd also does this, in fact! libnetfs and libdiskfs already
have char *path in struct peropen, meaning they already know for which
path this individual peropen was created, even if there are several
paths that can be used to get to the [i]node. It's just that there's
no RPC that exposes this info to clients.

> > P. S. Could you please take a look at my glibc patches in the other thread?
>
> It's piled up in the middle of so many dozens of stuff that people throw
> at me to do.

Well... thank you for reviewing my patches and otherwise guiding me so
far. And if there's a better way to contribute beside throwing even
more patches at you, I'd be glad to.

Sergey