From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt1mt-0005c1-Bz for qemu-devel@nongnu.org; Thu, 23 Oct 2008 11:07:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt1mr-0005an-RC for qemu-devel@nongnu.org; Thu, 23 Oct 2008 11:07:46 -0400 Received: from [199.232.76.173] (port=37967 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt1mr-0005ai-Nc for qemu-devel@nongnu.org; Thu, 23 Oct 2008 11:07:45 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53196) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kt1mr-0001ZA-Kf for qemu-devel@nongnu.org; Thu, 23 Oct 2008 11:07:45 -0400 Date: Thu, 23 Oct 2008 13:09:06 -0200 From: Glauber Costa Message-ID: <20081023150906.GM18872@poweredge.glommer> References: <1224771556-11146-1-git-send-email-glommer@redhat.com> <1224771556-11146-18-git-send-email-glommer@redhat.com> <49007FDE.8070806@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49007FDE.8070806@redhat.com> Subject: [Qemu-devel] Re: [PATCH 17/32] build list of available accelerators Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, jan.kiszka@siemens.com, jes@sgi.com, qemu-devel@nongnu.org, Glauber Costa , dmitry.baryshkov@siemens.com On Thu, Oct 23, 2008 at 03:45:02PM +0200, Avi Kivity wrote: > Glauber Costa wrote: >> From: Glauber Costa >> >> instead of hardcoding kqemu_start() in exec.c, which would require >> such a hack for all available accelerators, semantics of register_qemu_accel() >> is changed a little bit. It only builds a list of available accelerators. >> The last one registered is the first tried. >> >> This is a temporary solution, since we don't control exactly the order in which >> things are loaded by the constructor attributes. The final goal is to have command >> line switches and priority lists to determine that. >> >> "info accelerator" is changed to accomodate it. It now prints a list of available >> accelerators, and only if one of them is active, a detailed description of it is printed. >> >> #define MAX_INFO_BUF 1024 >> typedef struct QEMUAccel { >> + char *name; >> > > const, or warnings you get. > >> +typedef struct QEMUCont { >> + QEMUAccel *acc; >> + int active; >> + struct QEMUCont *next; >> +} QEMUCont; >> > > The name is unclear. But you could fold the structure into QEMUAccel, no? Yes, it was folded in my first version. It is separated just to allow external accelerators to register themselves without messing with the accelerator list, which would be internal. But I'm probably just being overzealous. > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. >