From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRLcg-00057H-C2 for qemu-devel@nongnu.org; Fri, 27 Feb 2015 09:10:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YRLcb-0005Y0-Qw for qemu-devel@nongnu.org; Fri, 27 Feb 2015 09:10:34 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54564 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRLcb-0005Xk-LL for qemu-devel@nongnu.org; Fri, 27 Feb 2015 09:10:29 -0500 Message-ID: <54F07AD3.1090400@suse.de> Date: Fri, 27 Feb 2015 15:10:27 +0100 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1424894306-26740-1-git-send-email-ehabkost@redhat.com> <1424894306-26740-5-git-send-email-ehabkost@redhat.com> <54EE477F.4000106@suse.de> <20150226155949.GA3513@thinpad.lan.raisama.net> In-Reply-To: <20150226155949.GA3513@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 04/11] target-i386: Rename cpu_x86_init() to cpu_x86_init_user() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Peter Maydell , qemu-devel@nongnu.org, Paolo Bonzini Am 26.02.2015 um 16:59 schrieb Eduardo Habkost: > On Wed, Feb 25, 2015 at 11:06:55PM +0100, Andreas F=E4rber wrote: >> Am 25.02.2015 um 20:58 schrieb Eduardo Habkost: >>> The function is used only for CONFIG_USER, so make its purpose clear. >>> >>> Reviewed-by: Paolo Bonzini >>> Signed-off-by: Eduardo Habkost >>> --- >>> target-i386/cpu.c | 2 +- >>> target-i386/cpu.h | 4 ++-- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> Please don't. I happily got all architectures aligned that it's at lea= st >> cpu_something_init, and it only happens to be user-only for x86. It is >> rather the legacy function that was used in both system and user. >=20 > If that's a legacy function, what are the steps you plan to follow to > eliminate it? I would be glad to help eliminating legacy code. >=20 > Initialization of CPUs in *-user and *-softmmu is different in i386, so > we are going to have different code for both. How do you think I should > name the *-user-specific CPU init function in target-i386, then? I would prefer to leave its name as it is (unless we are renaming all, which would probably be a waste of effort giving the next steps) and simply not use it in PC code. If you want to enforce this, you could #ifdef CONFIG_USER_ONLY it. For some targets - as can be seen in your uc32 patch - there is already a cpu_generic_init() that calls into the CPUClass hooks of the given CPU type. I would like to call that from linux-user directly (or from a lightweight wrapper to be shared between linux-user and bsd-user, I assume we're going need some target-specific #ifdefs) and drop cpu_init() in its current form. In particular I want to somehow move the realized=3Dtrue part out of it, which means either inlining it into dozen= s of machines or finishing the recursive realization work so that we only need one central realized=3Dtrue for /machine. My branch with the last realize_children code unfortunately ran into conflicts with hotplug handler code and recursive un-realization and hasn't been rebased in months. Paolo's comment had been that we would need to assure by reordering (or at least prove it not-yet-necessary by assertions) that the qdev-bus topology in addition to the QOM parents have been realized before a given child device gets realized. Additionally, /machine is its own type iirc, so will either need to become a device or have its own "realized" property implementation iterating over its direct, unassigned and peripheral children. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)