Re: [Xen-devel] [PATCH 04/13] xen: sync public headers

[Tim Deegan <tim@xxxxxxx>]

At 16:36 +0000 on 08 Feb (1360341398), Paul Durrant wrote:
> > > > > > > I don't think so. The reason to use unsigned long here is to
> > > > > > > guarantee each selector (in 2-level case there is only L1
> > > > > > > selector) fits into a word.
> > > > > >
> > > > >
> > > > > That's still going to be a problem with Windows drivers.
> > > > > Unfortunately
> > > > MSVC uses a 64-bit model where longs are still 32-bit. The only
> > > > thing that is word size is a pointer. Any chance we can use
> > > > uintptr_t rather than an unsigned long? (At the moment I have to sed
> > > > all the public headers to replace long with LONG_PTR and it's a PITA).
> > > > >
> > > >
> > > > TBH I don't know much about Windows. But are you suggesting replace
> > > > all the relevant bit in the header or just the specific event channel
> > interface?
> > > >
> > >
> > > I was just pointing out that assumption that unsigned long == native
> > > word size does not hold for 64-bit Windows. So, if we're adding
> > > something new can we avoid use of unsigned long and use an abstract
> > > type defined to be the native word size?
> > 
> > Probably ought to be the existing xen_ulong_t.
> 
> That works for me :-)

Hmm.  xen_ulong_t is a typedef for unsigned long on x86.  Are you
suggesting we change that?  On the grounds that any platform where it
would make a difference to the ABI has already had to adjust its
headers?  I think I can buy that.

In any case, if we are defining up a new native-word-size type, it
oughtn't to be uintptr_t --- there are systems where pointers are not
word-sized (e.g. x32) and we might want to support one of them at some
point.  Explicitly setting it to uint32_t/uint64_t also avoids any
further problems with compiler-specific variations.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel