Re: Hurd IPC (client side)

[Neal H. Walfield]

> On Tue, Oct 29, 2002 at 10:25:44AM -0500, Neal H. Walfield wrote:
> > The calling conventions will be the same, i.e. we pass the handle.
> > The client stubs will do the correct transformations.
> 
> How can this be done? Can IDL4 be "tuned" to generate code for this? And how
> will the client stubs know the server thread id?

This is an excellent point and for those who did not immediately
follow, consider the following definitions:

  struct user_handle
    {
      threadid_t server;
      user_handle_id_t handle;
    };
  typedef struct user_handle user_handle_t;

  ...

  typedef user_handle_t file_t

An interface definition might look like this:

  error_t file_chown (in file_t file,
                      in uid_t new_owner,
                      in gid_t new_group);

The generated stub will actually be:

  error_t file_chown (threadid_t server,
                      user_handle_t uh,
                      uid_t new_owner,
                      gid_t new_group);

Note the repetition of the server thread id (in SERVER and in
uh.SERVER) and the complete lack of transparency.  To solve the first
problem, we will have IDL4 generate different stubs: file_t will just
be a user_handle_id_t--not a user_handle_t.  Thus, the stub will be:

  error_t file_chown (threadid_t server,
                      user_handle_id_t uhi,
                      uid_t new_owner,
                      gid_t new_group);

The latter problem can be solved using some preprocessor magic to
transform calls from `file_chown (uh, owner, group)' to `file_chown
(uh.server, uh.handle, owner, group)'.

However, the question remains: why can we not modify IDL4 to
understand attributes.  And the answer of course lies in the question
itself: an IDL is not about attributes; it is the wrong level of
abstraction.  Andreas Haeberlen, the author of IDL4, can give you much
better arguments for why these annotations belong someplace else; I
would only be repeating his arguments.