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

Steven Jenkins steven.jenkins@gmail.com
Tue, 5 May 2009 09:35:45 -0400


On Tue, May 5, 2009 at 4:12 AM, Felix Frank <Felix.Frank@desy.de> wrote:
> Hi all,
>
> I'm reviving this thread for the benefit of RxOSD integration.
>
...
> 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
> =A0 translation functions
> 2. rxgen receives another mode that generates functions which rely on gpe=
rf
> =A0 generated hash tables
>
> Is that about what you had in mind?
> Further suggestions/criticism?
>

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

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.

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.

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.

--=20
Steven Jenkins
End Point Corporation
http://www.endpoint.com/