On Wed, 16 Apr 2014 20:32:07 +0300 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Wed, Apr 16, 2014 at 05:42:22PM +0100, Peter Maydell wrote: > > On 16 April 2014 17:34, Michael S. Tsirkin <m...@redhat.com> wrote: > > > so it looks like virtio is currently compiled per-target. > > > So why isn't it reasonable to keep it per-target for > > > purpose of this enhancement? > > > What am I missing? > > > > "virtio" is more than one C file. Currently per-target: > > hw/virtio/virtio.c > > hw/virtio/virtio-balloon.c > > hw/scsi/virtio-scsi.c > > hw/block/virtio-blk.c > > hw/char/virtio-serial-bus.c > > hw/net/virtio-net.c > > > > Currently built once: > > hw/char/virtio-console.c > > hw/virtio/virtio-bus.c > > hw/virtio/virtio-mmio.c > > hw/virtio/virtio-pci.c > > hw/virtio/virtio-rng.c > > > > If we can move files from the first group to the second > > that's cool. > > But doesn't have to be part of this series, yes? > I would say let's at least have virtio 1.0 out > and implemented in qemu and linux guests, then > we can start deprecate virtio 0.X in favor of it. > > > Moving files from the second to the first is > > what I'd like to avoid... > > > > thanks > > -- PMM > > Absolutely. > > Looks like we are in agreement after all. > > So as far as I could see the only issue is with config access > e.g. in virtio-pci? > That one already has a branch around virtio_is_big_endian, > so it's not a problem, there's no need to optimize that. > It is because you haven't looked at the other patches... When the whole serie is applied, all virtio files use inlined helpers from virtio-access.h to access memory and fix endianness. That is why we'd rather not add target dependency here... This being said, if you have an insight to have branch-less code for fixed endian targets, and dedicated code for ambivalent endian targets, please send something. Cheers. -- Greg
