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

[Jeffrey Hutzelman]

--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
>
> It would accomplish this by extending rxgen to pul the procedure
> identifier and opcode from the specification file: e.g., given the
> following hunks of code:
>
> "package" <Package_ident>
> ...
>  <Procedure description option>:
>
>         ["proc"] [<Procedure_ident>] [<ServerStub_ident>]
>             <Argument list> ["split" | "multi"]
>             ["=" <Opcode_ident>] ";"
>
> would produce new tables which would automatically go into the .h file
> for that specification file: e.g.,
>
> <Package_ident>_name[<Opcode_ident>] = <Procedure_ident>
> and
> <Package_ident>_opcode[<Procedure_ident> = <Opcode_ident>

Sorry, this is about as clear as mud, perhaps because the above isn't valid 
C and certainly isn't a declaration, and perhaps because all the extraneous 
"_ident" is confusing me.  You sound like you're proposing creating a pair 
of arrays to be used as lookup tables, but this has a couple of problems:

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.


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.

-- Jeff