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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-02-07 at 09:22 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > > > -#define NR_EVENT_CHANNELS (sizeof(unsigned long) *
> > > > > sizeof(unsigned long) * 64)
> > > > > +#define NR_EVENT_CHANNELS_L2 (sizeof(unsigned long) *
> > > > > +sizeof(unsigned long) * 64)
> > > >
> > > > We did a bit of header change to make the ARM code always use
> > > > 'unsinged long long' on 32-bit (so it is a nice 8-bytes) and
> > > > 'unsigned long' on 64-bit. This was all done using the xen_pfn_t and
> > xen_mfn_t typdefs.
> > > >
> > > > Any chance you can do that here? That way on ARM - irregardless if
> > > > it is 32-bit or 64-bit it is always of the 64-bit size?
> > > >
> > >
> > > 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).

It's considered pretty normal these days that users of these headers
import them and manipulate them to fit their environment (often by hand
and manual synching).

For example in the Linux copy we remove the struct typedefs because
Linux coding style doesn't use them.

Ian.


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