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

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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