This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 2/3] RFC: libxl: API changes re event handling

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/3] RFC: libxl: API changes re 
event handling"):
> Something with mask/unmask perhaps? (e.g. libxl_event_unmask_FOO or
> libxl_event_FOO_unmask?) That fits in with the idea that events start of
> masked and you unmask them if you want to receive them and is consistent
> with the terminology used for the equivalent parameter to
> libxl_event_register_callbacks.
> Or else just a simple enable/disable?

That's probably better.  "mask" gives the impression that they're
being generated anyway, just filtered, whereas in fact the library
might have to go to some effort to provide them.

> > We don't want to put a void* in an idl type.  A "foreign" caller (eg,
> > one in a different process communicating by IPC) can't easily invent
> > pointers.
> Well, the pointer is only useful once it completes the circuit and gets
> back to the "foreign" caller but I take your point.

Programs which communicate via IPC shouldn't rely on pointers provided
by their peers.  IMO.  OK perhaps there are exceptions (eg, the kernel
and xenstore) but I think it's a good general rule.   And a void*
can't be used to store integers, whereas the reverse is true.

> It might nice to declare something akin to intptr_t in the IDL and us
> that?

That would be fine IMO.  Although it ought to be a type which is (a)
big enough for pointers (b) big enough for uint64.  So not intptr_t.
The bigger of uint64_t or uintptr_t would do.

> I think it's consistent with the libxl naming convention (such as it is)
> by distinguishing this case from a non-opaque struct getting typedef'd.
> There are a bunch of existing things declared that way.

Are there ?  That just goes to show what you assume if you don't read
carefully.  OK then.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>