From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHZso-00070F-Bu for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:55:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHZsj-0006wD-Cj for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:55:37 -0400 Received: from [199.232.76.173] (port=56295 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHZsj-0006wA-4F for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:55:33 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39828) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHZsi-0006yD-I7 for qemu-devel@nongnu.org; Fri, 19 Jun 2009 04:55:32 -0400 Message-ID: <4A3B527C.2010203@redhat.com> Date: Fri, 19 Jun 2009 10:55:24 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] sending pci information over the wire References: <20090618193946.GH3517@poweredge.glommer> <4A3A9D89.5000305@codemonkey.ws> <20090618201227.GI3517@poweredge.glommer> <4A3AA5D8.8050303@codemonkey.ws> In-Reply-To: <4A3AA5D8.8050303@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; 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: Glauber Costa , qemu-devel@nongnu.org, armbru@redhat.com On 06/18/09 22:38, Anthony Liguori wrote: > Glauber Costa wrote: >> Sure. >> >> Question is, whether or not there is any value in doing this now. Prototyping, playing with it, figure any roadblocks: yes. Merging: no. I think we should go for the "big" solution, i.e. machine-config for *everything*, not just PCI. The move from the current model to the machine-config based one will be difficuilt enougth, we should not make it even harder to support by merging a half-done interim solution. > We're really close to a machine config for pc though, I'm not sure that > that's not a quicker solution. Well, we are not *that* close. Paul Brooks fdt works fine for some simple embedded boards. To make it fly with pc a noticable amount of work is needed (I'm working on that ;). Partly that is a simple conversion of drivers to qdev. Partly that involves reorganization and cleanup of drivers and subsystems and the dependencies they have. Which certainly is a good thing because it cleans up the code. But it needs to be done before machine-config can work for pc. Speaking of qdev: You seem to be reluctant committing qdev patches (except obviously correct one-liners), which is quite understandable as qdev is done by Paul. Problem is that there are lots of qdev patches on the list from me and others which are largely ignored. Some of my patches got committed. Fine. Some got comments from Paul. Fine too, so I know why they are not committed and can work on the issues. Most of my patches are ignored. Hmm. How to go forward here? I suspect reposting over and over wouldn't help here. Likewise devtree: Paul posted the patches, got a number of reviews comments. No discussion of the concerns happened though. There is also no activity in Pauls git tree. There are some quite fundamental design issues which need to be decided: (1) How will we handle fdt and hotplug? We can keep the qdev tree and the fdt in sync all the time. Or we generate a fresh fdt from the qdev tree when needed (i.e. for savevm, migration and maybe the ppc kernel). (2) Depending on (1): How will we handle attributes? Read/write directly from/to the fdt? Keep them in qdev data structures? I really like to see some progress here, otherwise 2017 wouldn't be just a running gag. cheers, Gerd