Re: Hurdish TCP stack

[Ludovic Courtès]

Hi,

Lluis <xscript@gmx.net> writes:

> Well, I don't know how rpctrace internally works, but I suppose it's 
> someting similar to ptrace, which gives information at "use-time", while 
> such a filesystem would need some kind of introspection mechanism on the 
> destination servers, in order to be able to figure out what methods are 
> available, as well as their signature.

It should suffice to have information about message IDs, rather than a
full description of RPC signatures, which would be complex.  `rpctrace'
looks at the IDs of messages that are exchanged and fetches RPC
descriptions from special files that map those IDs to RPC descriptions
(roughly).

> A quick hack to that could be to store that information in a special 
> section in the ELF (generated by the idl compiler), which simply lists the 
> available RPCs and their signature.

You are not necessarily able to access the executable that's translating
a given node.  A better approach would be to have all translators
implement a "meta-interface" that provides RPCs such as
"get_supported_msgids ()", etc (this is similar to what D-Bus has, for
instance, except that D-Bus is able to produce a stand-alone interface
description in XML).  The server-side RPC handling for this interface
could probably be automatically generated, with special support from
MiG.

Anyway, I'm not sure there's so much value in doing this.  ;-)

Thanks,
Ludovic.