Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Dec 18, 2012 at 12:06:39PM +0000, Peter Maydell wrote:
> On 18 December 2012 11:50, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > Il 18/12/2012 12:26, Peter Maydell ha scritto:
> >> On 18 December 2012 11:01, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>> This is what I am saying: create your own bus and put
> >>> your devices there.
> >>
> >> What bus?
> >
> > A virtio bus like the one in these patches.  But mst is suggesting to
> > leave virtio.c aside, and only use the virtio bus in the virtio-x-mmio
> > devices, to connect to the virtio-mmio device provided by the board.
> 
> That doesn't make any sense to me -- why would you want to make
> mmio be randomly different from the other virtio transports?

Not different at all. virtio-pci uses the pci bus.
It's you who's saying mmio is different and can not
work with existing bindings.

> The code
> as it stands is a mess which ought to be cleaned up anyway...

My experience is all working code is somewhat messy.  This is working
code.

I'm sure we shouldnot add more ways to create devices,
we have two for each device already, that's too much.
You can't seriously add yet another way, keep the two
existing ones around as legacy and claim it's a cleanup.
You are single-handedly making the testing matrix bigger by 1/3.

And what makes virtio so special anyway? e1000 can be used without
exposing users to internal buses and all kind of nastiness like this.
People just want to install a driver and have a faster IO.

> To the extent that it's painful for users to manipulate qdev devices on
> the command line, that's a problem we ought to address at some point
> anyhow.
> 
> -- PMM

It's pretty painful, yes, but adding yet another way to do it is not
addressing the problem.

-- 
MST