pointers in public headers

pointers in public headers

[Jan Beulich]

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

Re: pointers in public headers

[Keir Fraser]

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

Re: pointers in public headers

[Jan Beulich]

>>> 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

Re: pointers in public headers

[Keir Fraser]

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

Re: pointers in public headers

[Jan Beulich]

>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

Re: pointers in public headers

[Keir Fraser]

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

Re: pointers in public headers

[Jan Beulich]

>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