From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdK1N-0002sE-3I for qemu-devel@nongnu.org; Wed, 10 Sep 2008 03:21:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdK1L-0002rb-GX for qemu-devel@nongnu.org; Wed, 10 Sep 2008 03:21:48 -0400 Received: from [199.232.76.173] (port=35381 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdK1L-0002rS-CS for qemu-devel@nongnu.org; Wed, 10 Sep 2008 03:21:47 -0400 Received: from mx20.gnu.org ([199.232.41.8]:39337) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KdK1K-000077-O4 for qemu-devel@nongnu.org; Wed, 10 Sep 2008 03:21:47 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdK1G-0004Wx-8z for qemu-devel@nongnu.org; Wed, 10 Sep 2008 03:21:42 -0400 Message-ID: <48C77583.5070003@siemens.com> Date: Wed, 10 Sep 2008 09:21:39 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1220978258-30894-1-git-send-email-dmitry.baryshkov@siemens.com> <20080909164955.GD7490@poweredge.glommer> In-Reply-To: <20080909164955.GD7490@poweredge.glommer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/2] qemu-accel: unbreak non-default accelerators Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: qemu-devel@nongnu.org, Dmitry Baryshkov Glauber Costa wrote: > On Tue, Sep 09, 2008 at 08:37:37PM +0400, Dmitry Baryshkov wrote: >> Make noaccel accelerator "registered" early so that >> kqemu has a change to be enabled (it's registered >> via __constructor__ feature, so called before main()). > fyi: we're probably changing that. There has been a lot of mail exchange > this days about the general acceptability of this feature, and the overall [ That was a private discussion, I guess. ] > feeling is that it's a negative construct. So if the problem you hit happens because > the constructor itself, it's probably worthy to drop it altogether, and invest time > in a new method for registering the accelerators. Do you plan to update/rebase QEMUAccel in the near future? Or what is the short-term roadmap of this approach? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux