On 03/18/2010 11:36 AM, Gerd Hoffmann wrote:
Hi,
But I still think that this is independent that VirtIO being 1st (or
not) memer of VirtIOBlock.
There is no strong reason for this other than memory allocation. As
long as virtio_common_init() does the allocation there is no way
around VirtIODevice being the first member. If this changes (and we
must change it if we want embed VirtIODevice and superclasses into
other structs) no reason is left.
Just changing it for the snake of change isn't a good reason either.
But if it helps cleaning the code we can change it without running
into trouble. You can't cast VirtIODevice to VirtIOBlock any more,
but you don't really want to anyway for type checking reasons.
It's almost certainly not worth the effort, but the proper way to model
is it probably to have a VirtioIOPCIBus that is a PCIDevice. The
VirtIOPCIBus then creates a single VirtIODevice. The VirtIODevice would
then take a VirtioTransport which would be implemented as part of the
VirtIOPCIBus.
Regards,
Anthony Liguori
cheers,
Gerd
