[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 03/61] virtio-pci-bus : introduce virtio-pci-bus

From: KONRAD Frédéric
Subject: Re: [Qemu-devel] [PATCH 03/61] virtio-pci-bus : introduce virtio-pci-bus.
Date: Wed, 09 Jan 2013 15:55:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 09/01/2013 15:53, Peter Maydell wrote:
On 9 January 2013 09:14, KONRAD Frédéric <address@hidden> wrote:
On 09/01/2013 09:37, KONRAD Frédéric wrote:
On 08/01/2013 19:08, Peter Maydell wrote:
This isn't quite right, I think (somebody correct me if I'm wrong!)
The virtio-pci-bus subclass doesn't have any state of its own, so it
doesn't need a struct, but it does still want a type, so virtio-pci.h
have a
     typedef VirtioBusClass VirtioPCIBusClass;
     typedef VirtioBusState VirtioPCIBusState;
and we then use VirtioPCIBusClass/State where appropriate
(notably in the typeinfo for class/instance size and in the get-class/
class-check/etc macros).

This lets us easily add state later if we need to by turning the
typedef into a typedef'd struct without having to hunt down all
the places that now need to say 'VirtioPCIBus*' rather than
Ok, I'll make the change.
Though, I'm not really sure we will add something here..
The virtio-pci-bus is only added to implement VirtioBusClass functions.
There are no differences between pci, s390, or mmio.
It's just consistency, and as I say it avoids surprises later. We're
basically inventing our own object system in C here, which means
that there's no guard preventing you from doing something in a
way which is inconsistent with our object system but still valid
and functioning C; but it's better style not to do that.

-- PMM
ok then, I'll change it. And for s390 too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]