Re: 32-on-64: pvfb issue

[Keir Fraser <keir@xensource.com>]

On 19/1/07 15:31, "Gerd Hoffmann" <kraxel@suse.de> wrote:

>> I'm sure however that I'll argue you should make
>> the enumeration local to the backend. It will always support his native
>> architecture. Where it supports cross-architecture (i386-on-x64) he can
>> *privately* have a numeric assignment for that situation which it uses on
>> data paths. Then we don't have redundant info in xenstore and we don't get
>> tied to particular magic numbers.
> 
> I don't want to put numbers into xenstore.  But there are multiple
> backends affected (pvfb, blktab, blkback, tpm, maybe more) and thus it
> would be useful to share the infrastructure IMHO ...

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?

If we can agree on a location for the protocol field (same directory as the
xenbus state field?), and a set of names (yours are fine, including the
'-abi' suffix), and a time in xenbus state machine to write the protocol (as
early as possible I guess!) then let's get the frontend machinery in place
first. Then we can continue to thrash out the backend details.

 -- Keir