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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-02-08 at 17:06 +0000, Tim Deegan wrote:
> At 16:59 +0000 on 08 Feb (1360342741), Ian Campbell wrote:
> > 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.
> 
> Ah, OK. 
> 
> But on arm32 it's explicitly the wrong thing (i.e. bigger than a word).
> Is that just going to be part of the cost of using explicit sizes
> everywhere on arm?

Actually, Stefano and I were discussing this the other day, the use of
unsigned long in the evtchn stuff on ARM32 is a 32/64 ABI snafu and
should be fixed -- using xen_ulong_t would fix this too...

Ian.



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