Cornelia Huck <> writes:
> On Mon, 02 Sep 2013 10:56:20 +0930
> Rusty Russell <> wrote:
>
>> Cornelia Huck <> writes:
>> > Would it make sense to have a bit 33 "rings big endian" whose validity
>> > depends on bit 32 set? This would make it possible for ccw to keep its
>> > current endianness.
>>
>> Very awkward. Our experience with bi-endian devices on PowerPC suggests
>> it's far better to not negotiate endian. It also avoids a branch
>> everywhere in the driver and host.
>
> Ok, so let's skip this feature bit and make virtio-ccw big endian for
> the ring?
That's one option: it would allow current Linux guests to do a
compile-time endian switch because we currently assume ARCH=s390 is
equivalent to "using virtio-ccw only". QEMU may be able to make the
same assumption.
I worry about future virtio-pci on s390, where this issue will become
more complicated. "LE everywhere" is a simple rule.
We still have the question of the endian of per-device headers
(eg. virtio-blk header) and per-device config space. I'm assuming we'll
use the same endian as for the ring.
>> Legacy devices will not be spec compliant, though we will map out the
>> differences for implementors and to make sure that transitional devices
>> & drivers are still possible. This legacy part will eventually be a
>> separate document.
>>
>> I expect them legacy to be firmly deprecated within a few years: new
>> features will probably only be offered for standard devices, and for PCI
>> there are some nice proposals in the standard which make life easier,
>> eg. for bootloaders.
>
> Is there any reason the legacy version can't stay in, with a big fat
> warning "new devices are not supposed to implement this"?
In the long term, a simpler spec will increase adoption. That's why I
proposed a separate document. That looks better than a document studded
with examples of our previous mistakes :)
> Another thing we need to keep in mind is that switching a device driver
> to support a new version of a device is not the way it works on every
> system. On s390, there's generally no device driver as such - Linux is
> the oddball there.
Yes, this makes the transition more difficult. But I believe we are
still at the stage where there are more implementations ahead of us then
exist now, so my preference is for immediate pain and long-term gain.
Cheers,
Rusty.
