Re: 32-on-64: pvfb issue

[Gerd Hoffmann <kraxel@suse.de>]

Keir Fraser wrote:

> Then we would make the protocol name structural: '<arch>-v2' rather than the
> extending an enumeration to 3 and 4 (in your scheme). Or take advantage of
> the stringness and call it '<arch>-grant'.

Hmm, well, I think we never ever should need "<arch>-v2".  It would suck
big time if we manage to layout the structs for some future protocol
version in a way which is abi-dependent *again*.

> 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!).

Yep.

> And magic numbers
> suck compared with intelligible strings for this kind of thing imo.

We'll need both then.  Strings are certainly nice for human-visible
stuff, but you don't want to strcmp() all the time in the backend.
Wouldn't be a problem for pvfb, but for blkfront/back where the ring
protocol is abi-dependent and thus the backend has to check often.

> 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. :-)

How about the patch below?  It adds both names and enums for the
protocols, the enums to be used internally in the backend, the names for
xenbus, plus conversion helpers (not used yet, want to collect feedback
on the idea first).

Location most likely isn't final, not sure where to place that best so
all parties involved can see it, probably xen/include/public/io/

comments?

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>