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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel