[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiple capabilities in a single RPC

From: Ludovic Courtès
Subject: Re: multiple capabilities in a single RPC
Date: Tue, 08 Mar 2005 14:13:20 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)

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

  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]