From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52702 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnGhC-0005fO-39 for qemu-devel@nongnu.org; Sun, 22 Aug 2010 15:59:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnGSq-0004qP-5V for qemu-devel@nongnu.org; Sun, 22 Aug 2010 15:44:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27866) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnGSp-0004qF-SQ for qemu-devel@nongnu.org; Sun, 22 Aug 2010 15:44:20 -0400 Message-ID: <4C717E05.50609@redhat.com> Date: Sun, 22 Aug 2010 22:44:05 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup References: <4C6D86F9.3010602@codemonkey.ws> <4C6D98E7.9020109@codemonkey.ws> <4C70EFC9.2050404@redhat.com> <4C7171EB.7090301@codemonkey.ws> In-Reply-To: <4C7171EB.7090301@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , qemu-devel , Paul Brook 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.