From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35924 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwbsk-0000Gl-05 for qemu-devel@nongnu.org; Mon, 07 Mar 2011 09:57:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwbsi-0003aw-NK for qemu-devel@nongnu.org; Mon, 07 Mar 2011 09:57:57 -0500 Received: from mail-iw0-f173.google.com ([209.85.214.173]:41038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwbsi-0003an-Fv for qemu-devel@nongnu.org; Mon, 07 Mar 2011 09:57:56 -0500 Received: by iwl42 with SMTP id 42so4836812iwl.4 for ; Mon, 07 Mar 2011 06:57:55 -0800 (PST) Message-ID: <4D74F26D.4060404@codemonkey.ws> Date: Mon, 07 Mar 2011 08:57:49 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4D73B6CA.8070000@codemonkey.ws> <4D73C8CE.6080800@codemonkey.ws> <4D73CD43.1010004@web.de> <4D73F272.50105@codemonkey.ws> <4D73FA15.8090107@web.de> <4D742780.1050000@codemonkey.ws> <4D74900C.90408@web.de> In-Reply-To: <4D74900C.90408@web.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 4/4] i8254: convert to qdev List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , qemu-devel On 03/07/2011 01:58 AM, Jan Kiszka wrote: > On 2011-03-07 01:32, Anthony Liguori wrote: > >> On 03/06/2011 03:18 PM, Jan Kiszka wrote: >> >>>> It's far from academic as this is user-visible and visible via the >>>> command line. >>>> >>>> >>> I thought it was stated before that there is no guarantee on the >>> internal structure of our device tree as the user may explore it (as >>> long as it's stable for the guest). >>> >> We have a lot of "unstable" interfaces that folks yell about every time >> it changes (like the -help output). Providing a bad external interface >> and justifying by saying its unstable is just asking for pain later. >> > This is really a "harmless", mostly read-only interface we are > discussing here. > > >> >>> Regarding command line: What are >>> your worries here? The user can't mess with built-in devices. >>> >>> >> -global still applies to no_user devices. >> > Already tried "-global isa-pit.iobase=0x4711"? -global changes property > defaults, not directly their values. > And as soon as we do time drift catch-up, it's going to be an important interface to work with. >>> I still think we have more important things to improve than these >>> cosmetic issues. >>> >>> >> What does converting this device to qdev actually add other than an >> interface that we're not going to be able to support long term? >> > This device is probably no big deal. But generally those conversions > help to clean up or at least uncover twisted dependencies between > devices. They are surely a step in the right direction as everything > that follows qdev will have to improve it evolutionary (we can't effort > a third device model in qemu), so will be able to build on top. > We can convert it to a DeviceState, and then have it hang off of Sysbus (but created under PIIX3). It's less pretty from a tree perspective but at least the modelling is correct. We should model based on logic relationships, not how we want things to look in info qtree. > The major issues I see when looking at more complex devices, > specifically in the x86 world: > - IRQ/GPIO binding should become a generic qdev service instead of a > sysbus bonus (and its interface should be improved). > - Buses may benefit from generic IRQ management as well. > - We need a generic connector between devices, maybe multi-bus binding > (e.g. to bind the IOAPIC both to the sysbus and the inter-processor > bus), maybe PROP_TYPE_BUS that could be set via qtree path or > alternatively a plain pointer. That should obsolete PROP_TYPE_PTR. > > And there are likely thousand things in the qdev model that could be > made simpler, more handy to use. > My biggest concern moving forward is that the more legacy baggage we accumulate with the current qdev implementation, the tougher its going to be to improve it down the road. Regards, Anthony Liguori > Jan > >