Re: Hurdish TCP stack

[Lluis]

El Thu, Apr 03, 2008 at 05:16:24PM +0200, Ludovic Courtès ens deleit� amb les 
seg�ents paraules:
>> 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).

But as I understand it, rpctrace can only look at ongoing messages, so you 
won't be able to build a FS interface for functions that have not been 
called before, unless the translator exposing RPCs to FS already knows the 
available methods (the IDs) *and* their signature, which renders the 
translator as totally non-generic.

My idea about introspection was to have a dumb and generic translator build 
the FS interface for any given server.


>> 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.

Well, the only idea behind embedding that info in the ELF was to avoid 
having "useless" code in the binary.


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

There probably is none, except for the case you want to expose any server 
operation through the FS, which I'm not sure of its worthiness. It was just 
a random thought from the /net FS discussion :)

Read you,
  Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth