Re: rpctrace improvement -- how I'm going on

[Neal H Walfield]

> This is what I've do in order to improve rpctrace with msg characters names:
>       * I've searched out much header files in order find out if in some 
> structure character name is reposrted, but I ve found noone.
>       * I've understand that in mach and hurd structures rpc msgs are indexed 
> used ONLY unsigned integer.
>       * I've found a fine named subsystems in main hurd source directory wich 
> contain base unsigned integer for all subsystems rpc msgs and in some other 
> sources I've read which anyone of them contain 200 spaces for procedures, 
> functions and so on.
>       * In any other file I've not found hardcoded rpc unsigned integer name.
>       * So I think is mig which generate this number and hardcode it in 
> output file which will be linked whit other souces (clients and server)
>       * So I think two solutions: 
>               * generate in mach and hurd build time a file in /etc (maybe 
> /etc/rpc) with unsigned integer name <-> character name translations.  
>               * in rpctrace build parse file generated by mig and hardcode 
> translation (unsigned integer VS characters names.
> 
> What do you think? This could be right? If yes, IMHO the best solutions is 
> firs one (create a index file in /etc)
> 
> I'm wait for suggestions.

A mig definition file has, at its start, a subsystem keyword which is
used to identify the subsystem and the first RPC id.  For instance in
<hurd/fs.defs> we find:

  subsystem fs 20000;

This means that `file_exec', the first RPC definition in the `fs' family
(as it is the first definition in the fs.defs file) will have ID 20000
and the reply (if it is a routine and not a simple routine) will be
20100.  The next RPC definition that we see is file_chown.  This will
have the ID 20001 and the reply ID will be 20101.

If you encounter the keyword `skip' this means that there is no RPC
associated with this ID.

The protocols are not formal in so far as you can write a new definition
file with subsystem 20000 and implement those functions and everything
can still work.  However, your program will just have to ignore invalid
RPCs and your clients will have to use the same protocol as you.  This
is, of course, nothing new.

Therefore, I propose that you parse the files on the fly (e.g. at
startup) allowing the user of rpctrace to specify other directories and
files to look in.  For instance, by default you will look in
`/include/mach' and then `/include/hurd'.  The user, on the command
line, might indicate `-I$HOME/myproject/defs'.  You could interpret this
to mean look in this directory for other definition files.

Now, a real situation.  A user runs rpctrance and you see RPC 20102.
First, you look at all the definition files in $HOME/myproject/defs and
you find that there is no RPC with this ID.  Then, you go on to
`/include/mach' and finally `/include/hurd' where you discover
`fs.defs'.  In this file, the reply to file_chauthor matches the message
id so you print out something along the lines of `file_chauthor
(reply)'.

pgpuMY7hgeEP7.pgp
Description: PGP signature