From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gianluca Guida Subject: Re: page ref/type count overflows Date: Thu, 29 Jan 2009 14:04:35 +0000 Message-ID: <4981B773.8080704@eu.citrix.com> References: <4981782A.76E4.0078.0@novell.com> <498198E1.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <498198E1.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Tim Deegan , xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org 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? Personally, while I don't have (and I can't have) anything against this, I think that this kind of unified struct would make the shadow code more error-prone, by making shadow pages and guest pages being casted by the same type. Of course, every bug is fixable, and good programmers shouldn't do this kind of errors. But I think that being able to differentiate between shadow's page_info and normal page_info by something more than just a variable name would help a lot the clarity of this already complex code. Thanks, Gianluca