From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ274-0000OA-29 for qemu-devel@nongnu.org; Thu, 27 Feb 2014 09:39:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJ26y-0005ky-2Z for qemu-devel@nongnu.org; Thu, 27 Feb 2014 09:39:01 -0500 Message-ID: <1393511950.31381.34.camel@localhost.localdomain> From: Marcel Apfelbaum Date: Thu, 27 Feb 2014 16:39:10 +0200 In-Reply-To: <530F1670.2070701@redhat.com> References: <1392904246-15575-1-git-send-email-aik@ozlabs.ru> <1392904246-15575-4-git-send-email-aik@ozlabs.ru> <530609F9.1060105@redhat.com> <530F14C2.2050808@suse.de> <530F1670.2070701@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alexey Kardashevskiy , Alexander Graf , qemu-ppc@nongnu.org, Andreas =?ISO-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org On Thu, 2014-02-27 at 11:41 +0100, Paolo Bonzini wrote: > Il 27/02/2014 11:34, Andreas F=C3=A4rber ha scritto: > > Am 20.02.2014 14:58, schrieb Paolo Bonzini: > >> Il 20/02/2014 14:50, Alexey Kardashevskiy ha scritto: > >>> From: Paolo Bonzini > >>> > >>> This is a first step towards QOMifying /machine. > >>> > >>> Signed-off-by: Paolo Bonzini > >> > >> The patch was originally mine, so I could get it in if Andreas wants= me > >> to handle patches 2-3. But for anyone else it would be missing your > >> S-o-b line. > > > > With this patch I have been plagued by doubts of whether we can run i= nto > > a race of creating /machine through qdev_get_machine() via command li= ne > > option handling or whatever other code paths. I'd like to understand this issue, can anybody elaborate a little on the = possible race? > I'm at a conference and > > did not find time yet to test this out - if you two could investigate > > and clarify, that would be helpful in moving forward. > > > > Also I thought that someone else had looked into replacing the whole = of > > machine_init and QEMUMachine with QOM infrastructure? >=20 > Yes, that was Marcel. Yes, I am working on that and planning to send an RFC V2 really soon. >=20 > I think that Alexey's patch and Marcel's approach are just two differen= t=20 > parts of the same project. >=20 > Marcel's is more general and focused on option handling, and the main=20 > idea is to convert -machine suboptions to properties. Alexey's is=20 > instead focused on using the QOM tree and the "contained-in"=20 > relationship as a basis for providing machine-specific (and possibly=20 > SoC-specific) hooks. >=20 > Each of them highlights one of the two aspects that, in my opinion, mak= e=20 > QOM interesting (respectively, unification of interfaces and the=20 > containment tree). I was planning to tackle the replacement of the machine from a container to an actual object too, however this patch conflicts with my series because I already have a QOM Machine object created *always* and this patch adds another object *sometimes*. Is this patch's functionality in use yet? Any idea how to merge those ide= as? > Paolo >=20 > > Anyway it was an > > idea that I once had, Anthony didn't like at first and then someone e= lse > > (Luiz?) convinced Anthony to do it after all but then somehow it got > > stuck with no patches posted... The discussed approach was instead of > > creating a type in machine init depending on some > > QEMUMachine::class_name, always create the type. But either approach > > conflicts with creating /machine as Container type, as mentioned abov= e. As I am going with the *always* approach and hoping to replace /machine with a QOM object, what is the conflict here? Thanks, Marcel > > If we go with such an interim solution then at least qdev.c needs to > > grow an assert. >=20 >=20