WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] 32-on-64: pvfb issue

To: Gerd Hoffmann <kraxel@xxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] 32-on-64: pvfb issue
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 19 Jan 2007 12:01:59 +0000
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>
Delivery-date: Fri, 19 Jan 2007 04:01:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45B0AED3.2020503@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc7wZ9C3az1Cqe0EduuowAX8io7RQ==
Thread-topic: [Xen-devel] 32-on-64: pvfb issue
User-agent: Microsoft-Entourage/11.2.5.060620
On 19/1/07 11:43, "Gerd Hoffmann" <kraxel@xxxxxxx> 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?
Pvfb does interact with xenbus already, so poking a protocol field in there
seems reasonable and makes the scheme the same as blkfront/blkback.
Furthermore, as I already pointed out, this allows tools to poke a default
value and hence we can support e.g., old 32-bit frontends on new 64-bit
backend.

Furthermore, if we use a xenstore node then we are not restricted to a
protocol number. This is rather nice because it allows us to give more
meaningful names to our supported protocols. 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. Yes, some of
these protocols are actually identical but I don't think this redundancy in
the definition of the protocol field matters at all -- a little bit more
information can sometimes be useful, and this definition of the protocol
field is imo clearer than a simple enumeration.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel