Re: multiple capabilities in a single RPC

[Ludovic Courtès]

"Neal H. Walfield" <address@hidden> writes:

> This is a good point.  It is worth pointing out that we don't actually
> need to expose any of the members of a cap use context to users: it is
> just a way to save information for the eventual ctx_end_cap_use call.
> The problem that we solve by exposing the structure is that since
> libhurd-cap-server doesn't know how to best allocate memory, the
> caller has to do it and for this, it needs the size of the ctx
> structure.  We can also expose this information using a function.
> The caller would than have something along the lines of:
>
>   struct hurd_cap_ctx_cap_use *cap_ctx = alloca (hurd_cap_ctx_size ());

More generally, there could be class objects available at run-time.
Like:

  struct hurd_object
  {
    const hurd_class_t *class;
  };

  struct hurd_class
  {
    /* Obviously, classes are objects whose class is `hurd_class_class' */
    hurd_object_t object;

    const char *name;
    const struct hurd_class *parent;

    size_t instance_size;
    /* Optionally, you could have a pointer to ctor, dtor, etc.  */
  };

  extern const hurd_class_t hurd_object_class;
  extern const hurd_class_t hurd_class_class;

  /* Return the size of an instance of CLASS.  */
  static __inline__ size_t
  hurd_class_instance_size (const hurd_class_t *__class)
  {
    return (__class->instance_size);
  }

  #define hurd_class_alloca_instance(_class)                    \
    ((void *)alloca (hurd_class_instance_size (_class)))


This provides what you need and more at (almost) no run-time overhead.
Then any class (structure) for which binary compatibility must be
guaranteed doesn't need to be exposed: only its `hurd_class_t'
representation has to be declared and made available to the caller.  You
can then have a couple of macros for declaring/defining a type and its
`hurd_class_t' object.

Obviously, the down side is that it implies some writing overhead,
mostly casts, unless opaque structs are declared along with the class
objects.

Ludovic.