From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: 32-on-64: pvfb issue Date: Fri, 19 Jan 2007 13:45:19 +0000 Message-ID: References: <45B0C0C5.4090009@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45B0C0C5.4090009@suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann , Keir Fraser Cc: Xen devel list , Markus Armbruster List-Id: xen-devel@lists.xenproject.org On 19/1/07 12:59, "Gerd Hoffmann" wrote: >> 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. Then we would make the protocol name structural: '-v2' rather than the extending an enumeration to 3 and 4 (in your scheme). Or take advantage of the stringness and call it '-grant'. Personally I'm of the opinion that the architectural ABI is a fundamental component of our protocol (in fact, the very component that is tripping us up here!). And magic numbers suck compared with intelligible strings for this kind of thing imo. However, I am open to persuasive arguments on this point. I'm not quite as stuck on it as I am regarding use of xenbus for this field: it just occurred to me as a seemingly neat extensible technique. :-) -- Keir