Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[Avi Kivity <avi@redhat.com>]

  On 08/22/2010 09:52 PM, Anthony Liguori wrote:
>>> So really, I think this suggests that some devices shouldn't have 
>>> any requirement to sit on a bus.  A UART16650A does not sit on bus.  
>>> It sits on a card and is wired to the ISA bus or is sometimes wired 
>>> directly to pins on a CPU on a SoC.
>>
>> I don't think we want to model individual resistors on a serial card 
>> as separate qdev objects.  We want the serial card itself to be a 
>> qdev (as it is a hotpluggable entity) and the individual serial 
>> interfaces on that card (as they are duplicates of each other and of 
>> interest to the user).
>
>
> You're missing the fundamental problem which arises because we've 
> introduced an object model without thinking through how devices ought 
> to be modelled.
>
> All devices should have a DeviceState associated with them.  
> Otherwise, there's really no point in having qdev at all.
>
> We have lots of devices today that don't have DeviceState's associated 
> with them because the have a separate qdev representation with a 
> reference to the non-DeviceState object.
>
> We have non-DeviceState objects because otherwise we end up with an 
> inheritance diamond.  We have this problem because we want to have 
> relationships like: DeviceState <- SystemDeviceState <- ISADevice <- 
> ISASerialDevice.
>
> But ISASerialDevice is not the only type of serial device.  You can 
> also have a SystemSerialDevice that's directly attached to the System 
> bus.  That means you'd have to have:
>
> SerialDevice -> ISASerialDevice -> SystemDeviceState -> DeviceState
>                      -> SystemSerialDevice -> SystemDeviceState -> 
> DeviceState
>
> Which is a classic MI diamond.  The only way to resolve this modelling 
> problem is to split out the common code and rely on a has-a 
> relationship instead of an is-a.  That gives you:
>
> ISASerialDevice->SystemDeviceState->DeviceState
> SystemSerialDevice->SystemDeviceState->DeviceState
>
> ISASerialDevice has-a SerialDevice
> SystemSerialDevice has-a SerialDevice
>
> And since we want SerialDevice inherit from a DeviceState (recall, all 
> devices should have DeviceStates):
>
> SerialDevice->DeviceState
>
> No more MI diamond and all devices have DeviceStates.  Coincidentally, 
> it matches more closely how hardware works..
>

Well, I agree, but I honestly lost the context.  How does this relate to 
the APIC and cpu hotplug?

I'll take the opportunity to say that we should be using a language that 
has first-class (...) support for these concepts instead of having to 
divine them from the code.

> Generally speaking, any time we have one device that needs to sit on 
> multiple busses, we're going to have to model it in this fashion.

We'll just have to address them one by one then.  Perhaps if many come 
up we can try a generic solution.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.