Patch for idl4

[ness]

[sorry for compressed attachment, but I've had some troubles with too
large ones]
I guess you know how to apply patch (since it's from cvs diff -up), I
don't. patch2 should be applied using
$ cd hurd-l4
$ patch -p0 ../patch2
patch.idl4 should be applied using
$ cd idl4-1.0.2
$ patch -p1 ../patch.idl4
The make process will fail, don't ask me why. Simply run ./configure and
then make again.

patch and patch2 are my tries to integrate idl4 in the hurd source tree,
but since I spent not much time on this (because I'll be on vacation
since tommorrow), this is pretty incomplete (like all the modification
on idl4 I did). Biggest problem is that the hurd-l4/Makefile.idl4 is
broken. patch.idl4 is the patch for idl4. It's from a maintainer-clean'd
tree. I know you like to read the patch directly and 12000 don't make
this easy, but shorter wasn't possible, because of the idl4 tree is
designed to provide the Makfile.in files and I had to (automaticaly)
change some of these.

Concrete information for what these patches do:
patch:
-edits configure.ac to search for idl4, check whether it's new enough,
set IDL4FLAGS
-edits ruth/Makefile.am to build the idl4 example
-edits ruth/ruth.c to make a test call using the idl4 generated interface
patch2:
-creates:
 -test.idl (used for checking if idl4 is new enough)
 -Makefile.idl4 (rules to handle *.idl files, BROKEN)
 -ruth/test.idl (test interface)
 -ruth/test_server.h (generated server header. I give this because of it
won't compile without, see README.idl4)
 -ruth/test_client.h
 -ruth/test_template.c (implementation of the test interface, generated
template edited by me)
patch.idl4:
patches lots of files of the idl4 source tree

miniturorial:
Assume we want to implement an interface called foo_class, that returns
an int, expects a long and gives a foo_t by value. Let's say foo_t is in
foo.h. If you have a look at test.idl, you see all that. (in foo.h foo_t
is a typedef to int). If we now want to generate the client stub, we do
this:
$ idl4 -i V4_GNU -p generic -T -fctypes -c test.idl
explination:
-i V4_GNU says we want the V4_GNU (resp. Hurd/L4) interface
-p generic says that we don't want any platform dependend optimization
(pltform dependend optimization is not implemented yet)
-T says idl4 to use the compiler to determine the size and alignment of
unknown types (foo_t). Since the default mapping is C and we didn't
specify any other and the default compiler for C mapping is gcc, this is
used. If you want any other, you can give the call to the compiler as
additional option -C, e.g. -C "i686-pc-linux-gnu -I/my/special/include"
-fctypes is a stabdard option that says idl4 not to use CORBA_* typedefs
for standard types
-c says that we want to create a client stub
You'll then have test_client.h. You won't want to include it dirctly, se
below. Don't wonder about some types with prefix idl4_ instead of hurd_.
These are typedefs in the idl4 header file(s). You'll see a method called
static inline int foo_class_foo(idl4_thread_id_t _server,
idl4_cap_handle_t _cap, const int a, foo_t *f)
The first parameter is the thread id of the server to call, the second
one the capability to operate on, and the others are the actual
interface parameters.
To create the server stub, you have to type
$ idl4 -i V4_GNU -p generic -T -fctypes -s test.idl
The options are similar to to those above, the only difference, -s,
indicates that we want to create server stubs.
Mainly, you have 3 function prototypes in that file:
void foo_class_server(idl4_cap_bucket_t _bucket);
void foo_class_discard(idl4_cap_rpc_context_t _ctx);
error_t foo_class_demuxer(idl4_cap_rpc_context_t _ctx);
foo_class_server can be called by a thread to start receiving and
answering requests.
foo_class_discard should be called if we get an unknown request.
foo_class_demuxer can be given as demuxer to hurd_cap_class_init.
Theoreticly, this would be enough for a code generator. But idl4 is able
to generate server templates. To do so, type
$ idl4 -i V4_GNU -p generic -T -fctypes -t -l test.idl
Options are similar to them above, except -t that indicates that we want
to generate a server template and -l. -l says idl4 to create sth. i call
cap class stubs. If you have a look at server_template.c, the following
is generated only because of we gave -l:
static idl4_cap_class foo_class;
error_t foo_class_init(void)
error_t foo_class_alloc(idl4_cap_obj_t* _r_obj)
As you can see, at least the last one usually gets more parameters. All
these functions you usually don't or with other parameters want in the
header. You can change the prototypes in the template, but since the
headers are typicaly generated new very often, these should not be
changed. That's why I told you not to include the generated files
directly. Better use wrapper headers.

idl4 --help:
Usage: idl4 [OPTIONS]... IDL_FILE
Generate stub code for the L4 microkernel platform

  -c                     generate client stubs
  -d, --debug=MODE       show verbose debug output
  -h, --header=FILE      rename output header file
  -o, --output=FILE      use different name for implementation file
  -s                     generate server stubs
  -t                     produce template
  -w, --word-size=BITS   set word size
  -f                     supply flags to the compiler
  -D                     preprocessor definition
  -I                     specifiy additional include directory
  -W                     enable specific warnings
  -v, --version          display version information
  -p, --platform=SPEC    specify platform (ia32, arm)
  -i, --interface=SPEC   choose kernel interface (V2, X0, V4)
  -m, --mapping=SPEC     use specific mapping (C)
  -l, --class            add cap-class stubs (very rudimentary, better
use wrapping for headers)
  -M, --make-depend      build make compliant dependencies
  -C, --compiler         specifiy the compiler (and the flags) to use
[gcc/g++]
  -T, --user-types       use the compiler to find out align and size of
unknown types
  -N, --no-erase         don't erase temporary files


Option summary (from idl4/NEWS) (-l isn't shown since I forgot it, but
the example should have shown what it does):
patch by ness
  - BE    : new CBEInterface_gnu and CBEOperation_gnu
            with some overwritten virtual functions,
            a new cross visitor (everything needed for
            V4_GNU)
  - V4_GNU: new interface (for use with GNU Hurd/L4)
            This is very rudimentary. No exceptions are
            supported, no data larger then 32 bit (shouldn't
            be hard to change), no strings, no fpages, no ...
            I skipped the implicit _env parameter, since
            the implementation doesn't use it.
            I added a new implicit parameter _cap, because of
            every IPC uses capabilities in hurd.
  - command line options:
    --make-depend [-M]: create make compliant dependencies
                        using the compiler (this creates a
                        temporary file including all imported
                        files and calls the compiler -MM,
                        afterwards the temporary file is
                        deleted)
    --compiler [-C]   : allws to specify the compiler command
                        (standard is gcc if mapping is C, g++
                        if mapping is C++). All include options
                        given to idl4 are given to the compiler
                        call (as -I...), too (anything else
                        wouldn't make sense, IMHO)
    --user-types [-T] : in principle this an other way to handle
                        import directives in the .idl files. See
                        the CHangeLog for longer explination of
                        why I implemented that. Here I'll list
                        the issues:
                          - all types are assumed to be trans-
                            fered by copying them
                          - parser.yy is not yet hacked to accept
                            imported structures (shouldn't be hard
                            to change [only enlarge the point
                            structures [struct ...] are parsed to
                            let them look up (see scoped_name, or
                            so)], but I'm not a yacc/bison geek)
                        This creates a temporary file that includes
                        all imported files and (as compiled binary)
                        prints size an alignment of the unknown
                        types. This file is compiled and executed
                        and it's output is parsed.

btw: I forgot to indent the file ruth/ruth.c in GNU style.

patches.tar.bz2
Description: Binary data

#ifndef FOO_H
#define FOO_h FOO_H
typedef int foo_t;
#endif

import "foo.h";
interface foo_class
{
        int foo(in long a,out foo_t f);
};