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

Re: [Xen-devel] pointers in public headers


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Fri, 25 Aug 2006 15:14:25 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 25 Aug 2006 07:14:39 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbIUMS4A4IaIDREEduEDAAKle7CWA==
  • Thread-topic: [Xen-devel] pointers in public headers

On 25/8/06 2:15 pm, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> While there are none there, even for those it would seem ill; but there
> pointers in
> - struct mmuext_op (xen.h)
> - struct vcpu_register_runstate_memory_area (vcpu.h)
> - struct xsd_errors (io/xs_wire.h)
> - struct ioreq (hvm/ioreq.h)

Io/xs_wire.h does not define a hypervisor interface so no need for guest
handles there. The rest are all x86-specific, and represent pointers that
don't really cleanly fit into the guest handle model and its accessor
macros. Since on x86 the guest handle stuff is really only an enforcement
method for ensuring we use the correct accessors I just left the tricky few
as they were. Are you trying to macro/typedef the world for compat
compilation, and these are annoying for you? :-) If so we could hide them
behind a different macro -- we'd need to do that anyway to avoid breaking
API compatibility.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.