qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Plan for moving forward with QOM


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Thu, 15 Sep 2011 15:35:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

On 09/15/2011 03:26 PM, Anthony Liguori wrote:
class PciConnector : public PciDevice
{
// provides interfaces to register closures which implement
// PCI abstract functions
};

or actually even

class PciConnector : Plug
{
    PciBus *bus;
    uint8_t config_space[4096];
    ...
}

The properties thing is definitely an interesting point, but I'm not
sure how far you can push it. If you start out with a NE2000 device that
is ISA and you decide to abstract it to a shared model, all you need to
do is keep the ISA NE2000 device named NE2000 and call the common chip
and PCI bridge something else.

It still holds, for two reasons. 1) The properties will be named differently for ISA and PCI versions, which is at the very least ugly; 2) if you want to save the property names for the ISA version, you need to duplicate the logic in NE2000 and PCI_NE2000.

If we had C++ and templates, the problem would be much less pressing: just use inheritance for PCI and template for ISA vs. PCI. The code duplication at least is invisible to the programmer, it's only in the object files.

I really think it's important to keep the simple cases simple. I think
any model where you don't do:

class E1000 : public PciDevice
{
};

Is unnecessarily complicated.

I don't think it's any more complicated. It _is_ different from what is done now, which may indeed make conversions slower. That's the main disadvantage of the connector model indeed.

Paolo



reply via email to

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