"Neal H. Walfield" <[EMAIL PROTECTED]> 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.
_______________________________________________
L4-hurd mailing list
L4-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd
