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
