[OpenAFS] Re: [OpenAFS-devel] exposing RPC code<->name mappings via rxgen extension, a library, and a new utility

[Felix Frank]

On Tue, 5 May 2009, Steven Jenkins wrote:

> I'm glad you revived this thread.  Some time ago I started a similar
> implementation for this that leverages the output from rxgen.  The
> translate_rpc mechanism just does a simple string or numeric match
> (and I can't seem to find that at the moment, so I may not have
> written anything beyond a throw-away program...).

That'll be straight forward, yes. I'll look into it.

> rxgen can be told to dump out its data definitions (via the -h
> option), which looks like it will do almost everything we need in
> terms of collecting the data.   I've attached the patch of what I
> hacked up in the rxgen source, but I actually don't think it's
> necessary.

Isn't that -x? "Not necessary" - are you implying your patch was gratuitous?
Which I wouldn't deem true.

> The one problem I hadn't decided how to handle is that two of the Rx
> IDL specifications overlap (FS and CM, if I recall correctly), so that
> needs to be resolved.

Does it? Won't the translate functions retain the package prefix? I thought
there might be going to be one for each interface. Or should callers not be
required to know what package they are talking about?

The only user in the immediate future will be RxOSD's fs and osd, 
which need only translate fileserver and rxosd operations respectively,
for example.

> I think it's probably only a little more work to get this to a usable
> state.  Even if the -h output won't quite work, the hacking I started
> in rxgen (or the changes you've started) could be leveraged.
>
> Also, note that I don't think the gperf approach is necessary for the
> first implementation.  We're only looking at a few hundred RPCs, so
> the search time, even though O(n), will be fairly fast.  If someone
> finds a need to do a repeated programmatic use of the table, then we
> could add a better hashing function at that time.

On Tue, 5 May 2009, Jeffrey Hutzelman wrote:

> --On Tuesday, May 05, 2009 10:12:49 AM +0200 Felix Frank 
> <Felix.Frank@Desy.de> wrote:
>
>> Is that about what you had in mind?
>> Further suggestions/criticism?
>
> Hm?  For number->name mapping, the right thing is to _generate a function_ 
> which works exactly like the ExecuteRequest function that rxgen already 
> generates, except that instead of calling a server RPC implementation, it 
> returns a (static) string containing the procedure name.

I fully agree. Steven suggested that the inverse translation should
work the same way, which would be much to my liking as well.

> At first glance, the patch you included does appear to generate a table like 
> the one I was describing.  No, I wouldn't feed these into gperf or modify 
> rxgen or any other component to use gperf.  My point was to use them as input 
> to a tool analogous to /afs/cs.cmu.edu/user/jhutz/scripts/error, which is a 
> perl script that parses a directory of com_err tables to translate an error 
> code or name:

> ]] [jhutz@minbar ~] 3> error 101
> ]]         101          ENETUNREACH
> ]]   Network is unreachable
> ]]         101          VSALVAGE
> ]]   volume needs to be salvaged
> ]]
> ]]
> ]] [jhutz@minbar ~] 4> error VNOVOL
> ]]         103          ECONNABORTED
> ]]   Software caused connection abort
> ]]         103          VNOVOL
> ]]   volume does not exist / did not salvage
> ]]
> ]] [jhutz@minbar ~] 19> error krb5.7
> ]] -1765328377 krb5.7   KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN
> ]]   Server not found in Kerberos database
>
> The tables aren't large enough for it to be worth doing anything fancy; just 
> slurp them all in and look for what you're looking for.

So the consesus is to
- generate very simple translation functions and
- generate lookup tables and branch off a proper script to parse them?

Thanks for all the input
  - Felix