[Top][All Lists]

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

Re: libhurd-cap-server: making API compatibility easier

From: Neal H. Walfield
Subject: Re: libhurd-cap-server: making API compatibility easier
Date: Tue, 08 Mar 2005 16:30:47 +0000
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 08 Mar 2005 17:13:13 +0100,
Ludovic Courtès wrote:
> "Neal H. Walfield" <address@hidden> writes:
> > I am not entirely clear what you intend.  Do you want to apply this
> > technique to hurd_cap_obj_t and hurd_cap_class_t?
> I was trying to address the question of how to allow caller object
> allocation while not exposing data structures.  In your previous
> example, you mentioned that this would be needed for `struct
> hurd_cap_ctx_cap_use' and you suggested that this could be achieved by
> defining a function that returns the size of this data structure:
>   struct hurd_cap_ctx_cap_use *cap_ctx = alloca (hurd_cap_ctx_size ());
> I'm just saying that instead of making an actual function call (not
> inlined) to `hurd_cap_ctx_size ()', the caller could do something like:
>   struct hurd_cap_ctx_cap_use *cap_ctx =
>     alloca (hurd_class_instance_size (&hurd_cap_ctx_cap_use_class));
> And this even saves a function call since `hurd_class_instance_size ()'
> can be inlined.

I understand your intention a bit better, thanks.

I am against putting the size of the class into a structure if we can
avoid it.  I think this doesn't save enough CPU cycles relative to a
function to justify the per-class memory overhead.  Further, it makes
compile time optimization harder.  For instance, if we decide to
expose the structure for another reason, hurd_cap_ctx_size will reduce
to an inline sizeof.


reply via email to

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