| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home