At 10:54 +0000 on 29 Jan (1233226449), Jan Beulich wrote:
> Below is what I currently have it at. I'm afraid it won't get much simpler,
> but I think it reasonably expresses the individual overlays. There are three
> more transformations I plan to make:
> - _domain -> unsigned int
> - next_shadow -> __mfn_t
> - split u into two unions (one having type_info, type/pinned/count, and
> cpumask, the other having _domain, back, and order).
>
> That last step is to avoid having to re-add __attribute__ ((__packed__)),
> so that other (future) changes to the structure won't risk mis-aligning any
> fields again.
>
> Does this look acceptable?
Seems fine, which is to say I don't see much advantage but have no 
objection. :) Please try to make it clear in the comments which fields
belong to a page which _has_ a shadow and which to a page that _is_ a
shadow.
Cheers,
Tim.
-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel