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

[Jeffrey Hutzelman]

--On Tuesday, May 05, 2009 10:12:49 AM +0200 Felix Frank 
<Felix.Frank@Desy.de> wrote:

> Hi all,
>
> I'm reviving this thread for the benefit of RxOSD integration.
>
> On Thu, 15 Jan 2009, Jeffrey Hutzelman wrote:
>
>> --On Thursday, January 15, 2009 02:00:09 PM -0500 Steven Jenkins
>> <steven.jenkins@gmail.com> wrote:
>>
>>> I would like to expose RPC code<->name mappings so that other programs
>>> within OpenAFS can avoid hard-coding the mappings, as well as be able
>>> to export them to the users (who might find them useful in debugging
>>> network traces, for example, where their particular tool does not know
>>> what a particular opcode corresponds to). From a user-level, it would
>>> work as follows:
>>>
>>> $ translate_rpc -name PR_INewEntry
>>> 500
>
> <snip>
>
>>
>> 1) Translation of opcodes to names could be done by an array lookup, but
>> it  shouldn't be, because the required array will generally be quite
>> large and  very sparse.  Instead, you should emit a _function_ which
>> uses the same logic  as the ExecuteRequest function already emitted by
>> rxgen, and which handles  large gaps in the opcode space in a reasonably
>> efficient way.
>>
>> 2) Translation of names to opcode cannot be done by an array lookup,
>> because  this is C, not awk or python, and strings cannot be used as
>> array indices.  Again, I recommend actually emitting a function which
>> does the required  translation.  This won't be like anything currently
>> in OpenAFS, but shouldn't  be too hard to construct.  I recommend
>> looking at using gperf to generate a  perfect hash table for each set of
>> procedures.
>
> I can see how a translate_rpc program could use a name -> RPC number
> translation, but not the server binaries. The former should be a simple
> script or program powered by a simple lookup table as suggested below.
> Do we need proper functions that do that?
>
> The only translation server or admin command binaries should need is
> number -> name, as far as I can see it.
>
>> It should be possible to get rxgen to produce these functions for any
>> interface, and preferably in a separate file from any of its other
>> outputs,  so that they may be collected together into a library that has
>> no other  dependencies.  I would also very much like to see a mode in
>> which rxgen emits  a simple table of opcode numbers and procedure names,
>> one per line. This  would be useful in constructing a standalone lookup
>> tool that reads one table  per RPC interface (similar to something I've
>> already done for com_err  tables), and may also be of use to the
>> registrars in constructing some of the  procedure number tables we
>> currently don't have.
>
> Simple table can be generated using the attached patch. It's an awful lot
> of copy-paste and I'm not sure if it's valid. I'm also not yet sure
> how to generate lookup functions. I have two approaches in mind:
>
> 1. make uses the lookup tables to feed gperf, and a custom script adds
> actual
>     translation functions
> 2. rxgen receives another mode that generates functions which rely on
> gperf
>     generated hash tables
>
> 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.

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.