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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-02-08 at 16:49 +0000, Tim Deegan wrote:
> 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?

I don't think that would be a good idea, but using xen_ulong_t does at
least mean he only needs to change one place rather than sed'ing up the
whole lot.

Ian.



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