From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIyPi-0004dx-Mi for qemu-devel@nongnu.org; Thu, 27 Feb 2014 05:42:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIyPc-00056x-N5 for qemu-devel@nongnu.org; Thu, 27 Feb 2014 05:42:02 -0500 Message-ID: <530F1670.2070701@redhat.com> Date: Thu, 27 Feb 2014 11:41:52 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <530F14C2.2050808@suse.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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: =?ISO-8859-15?Q?Andreas_F=E4rber?= , Alexey Kardashevskiy , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, Alexander Graf , Marcel Apfelbaum Il 27/02/2014 11:34, Andreas F=E4rber 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 m= e >> 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 int= o > a race of creating /machine through qdev_get_machine() via command line > option handling or whatever other code paths. 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? Yes, that was Marcel. I think that Alexey's patch and Marcel's approach are just two different=20 parts of the same project. 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. Each of them highlights one of the two aspects that, in my opinion, make=20 QOM interesting (respectively, unification of interfaces and the=20 containment tree). Paolo > Anyway it was an > idea that I once had, Anthony didn't like at first and then someone els= e > (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 above. > If we go with such an interim solution then at least qdev.c needs to > grow an assert.