On Monday 03 October 2005 17:17, Keir Fraser wrote:
> On 3 Oct 2005, at 20:16, Hollis Blanchard wrote:
> >> However, since we're not actually changing the size of any types, this
> >> change isn't essential to rush through before 3.0, though it might be
> >> nice as it should be very low risk.
> >
> > I'm working on this patch now.
> >
>
> Well, at least this patch will be benign, but on its own it is also
> *totally* pointless. You can't use it to get 64-bit struct arrangement
> on 32-bit builds because it will leave pointers as 32-bit aligned and
> sized fields.
As part of the patch, I'm converting pointers to also use the new type, and
casting the users appropriately.
> We could macro up pointer fields I suppose:
> #define XENIF_PTR(type, name) type name
> So that macro can be overridden to get 64-bit sized and aligned pointer
> fields?
So you would use the above macro above for x86, and so continue with the
existing unstable interface, but this would allow PPC to define its own
macro, and thus have a 32/64-bit clean interface? Like this?
#define XENIF_PTR(type, name) u64 name
And then casts would still be needed to work with those values, right?
> And ureg_t is a name that's bound to clash with something down the
> road. Maybe xenreg_t, or even just be explicit about what it is and
> call it xenif_ulong_t?
I don't like calling it a "ulong," because it isn't, and neither is it a
"register" size...
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home