From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: 32-on-64: pvfb issue Date: Fri, 19 Jan 2007 13:59:49 +0100 Message-ID: <45B0C0C5.4090009@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Xen devel list , Markus Armbruster List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 19/1/07 11:43, "Gerd Hoffmann" wrote: > >>> How about a patch to clear the page *and* write a newly-defined protocol >>> field? Or are you still planning to kludge the bitwidth check in the >>> backend? >> That is better, yes. Minimum patch attached. For unstable I'll brew a >> nicer version with defines and so on when adjusting the backend code to >> be able to deal with both protocols. > > Thinking about this some more -- isn't it a bit skank to have the protocol > field embedded in the middle of the structure which it effectively defines? When writing something new I would have placed it at the start of the struct, but with the situation we have now it is more important not shuffle the fields around. All the fields before the new protocol field have a fixed size and no alignment problems, so you can be sure the protocol field has a fixed place everythere. Changing the struct is only possible after the protocol field of course. The only pending change is switching from the page directory to grant tables, so this isn't too bad. > Pvfb does interact with xenbus already, so poking a protocol field in there > seems reasonable and makes the scheme the same as blkfront/blkback. Would be more consistent across drivers, yes. I still think it would be placed better in the struct next to the fb config, but if you insist on having it in xenstore I can do it that way too. > Right now, since we make no > effort to ensure protocol compat across machine architectures (for example > we use native endianness) I suggest that we define a per-architecture > protocol name: 'x86_32', 'x86_64', 'ia64', 'powerpc64', etc. Hmm, not sure I like that idea, especially for pvfb as there certainly will come the protocol switch to grant tables, so using the arch names doesn't sound like a good idea to me. cheers, Gerd -- Gerd Hoffmann