From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: 32-on-64: pvfb issue Date: Mon, 22 Jan 2007 08:50:23 +0100 Message-ID: <45B46CBF.7010406@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 Hi, > And we can do so. xenbus_get_native_protocol()? Frontends can write the > returned string; backends can strcmp with the returned string (and usually > fail on mismatch). The few mismatches we do care about will result in us > executing driver-specific code anyway: drivers can declare 'native' ABI to > be 0 and have special-case driver-specific non-zero values for the > non-native protocols they care about. Would that actually be more code than > the potentially-knows-about-every-driver-in-the-world approach of > protocols.h? I'll go code up both front and back bits for block and pvfb to see how it works out in practice, I think I'll have patches later today or tomorrow ... > If we can agree on a location for the protocol field (same directory as the > xenbus state field?), Yes. > and a set of names (yours are fine, including the > '-abi' suffix), Yep, those I'll plan to put into a common header file so they can be shared in any case. Not sure any more how useful sharing the enum for the protocol actually is, I'll see when coding up things. > and a time in xenbus state machine to write the protocol Same transaction event-channel is written. stay tuned, Gerd -- Gerd Hoffmann