Re: [Xen-devel] [PATCH v8 10/14] xen/common: move the memory_mapping DOMCTL hypercall to common code

[Tim Deegan <tim@xxxxxxx>]

At 15:21 +0100 on 05 Jun (1401978088), Ian Campbell wrote:
> On Mon, 2014-05-26 at 12:03 +0100, Julien Grall wrote:
> > In any case, I don't think we should expose mfn_t and _mfn to ARM. All 
> > the P2M interface used in common code, take an unsigned long in parameter.
> 
> I don't object in principal to the idea that common code should be
> moving towards more semantic types (i.e. mfn_t rather than unsigned
> long) in general. Or even to going as far as x86 has done in the common
> code and having mfn_t be more than a typedef (it's a wrapping struct for
> type safety), which results in the _mfn() and mfn_x() conversion things.
> 
> But I don't think we should be making that transition as part of this
> series.
> 
> I think the right answer here and now is for map_mmio_regions to take
> the mfn as an unsigned long and for the wrapping into a mfn_t to happen
> in the x86-specific implementation of map_mmio_regions etc.

+1.

> That would also get rid of this sort of thing from the previous patch:
>          _mfn(mfn_x(mfn) + i))
> 
> If someone wants to come along later and "type-safe-up" the common code
> too, well, lets think about that then...

Sure.  I think it would be a good idea in general to extend those
type-safe conventions, but no hurry to do it here.

Incidentally, I'd be _delighted_ if anyone can suggest a way of making
mfn_t and gfn_t distinct types (i.e. that the compiler won't silently
cast to/from other types) without requiring the _mfn/mfn_x ugliness.

Tim.

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