Is there any reason to retain some instances of uses of pointers in the public headers? I would have expected that only guest handles should be used there. Thanks for clarification, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/8/06 8:05 am, "Jan Beulich" <jbeulich@novell.com> wrote:> Is there any reason to retain some instances of uses of pointers in the > public headers? I would have expected that only guest handles should > be used there.There might be some pointers in io/ring.h but that ought to be all, I think. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 25.08.06 09:41 >>> >On 25/8/06 8:05 am, "Jan Beulich" <jbeulich@novell.com> wrote: > >> Is there any reason to retain some instances of uses of pointers in the >> public headers? I would have expected that only guest handles should >> be used there. > >There might be some pointers in io/ring.h but that ought to be all, I think.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) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/8/06 2:15 pm, "Jan Beulich" <jbeulich@novell.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
>Io/xs_wire.h does not define a hypervisor interface so no need for guest >handles there.Good.>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.Yes, they present a lurking problem once the converted structures get accessed - clearly any kind of pointer is invalid when considering compatibility mode guests. I could certainly try to make the script catch them and convert them (to a integer type), but then the automation of copying the respective fields will trigger compiler warnings about converting integrals to/from pointers of different size. So, yes, some kind of macro would help, but I can''t see how you would want to get away with not breaking API compatibility (which requires to leave a pointer in there somehow) but eliminating the pointer. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/8/06 4:13 pm, "Jan Beulich" <jbeulich@novell.com> wrote:> Yes, they present a lurking problem once the converted structures get > accessed - clearly any kind of pointer is invalid when considering > compatibility > mode guests. I could certainly try to make the script catch them and convert > them (to a integer type), but then the automation of copying the respective > fields will trigger compiler warnings about converting integrals to/from > pointers of different size. > So, yes, some kind of macro would help, but I can''t see how you would > want to get away with not breaking API compatibility (which requires to > leave a pointer in there somehow) but eliminating the pointer.I don''t know enough about the scheme you are implementing to be able to comment. I mean API compat from the p.o.v. of guests -- any macro would only be defined as other than a plain pointer for Xen and your scripts, which would presumably know what they''re doing and avoid compile warnings. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>I don''t know enough about the scheme you are implementing to be able to >comment.You could look at the patches posted earlier today. In short, it simply takes the public headers and replaces all occurrences of ''long'' in there with ''int'' (while obviously properly renaming everything to not result in name collisions) - whether other types are used that need adjustment will need to be seen later.>I mean API compat from the p.o.v. of guests -- any macro would only >be defined as other than a plain pointer for Xen and your scripts, which >would presumably know what they''re doing and avoid compile warnings.Yes, if the whole Xen tree (including the tools) is not of concern, then this would work - Xen (and implicitly the conversion script) would see an unsigned long there then, which match all other places needing conversion. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel