From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvV6j-0000WS-Oo for qemu-devel@nongnu.org; Sun, 19 Apr 2009 07:22:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvV6f-0000Pq-SK for qemu-devel@nongnu.org; Sun, 19 Apr 2009 07:22:45 -0400 Received: from [199.232.76.173] (port=50800 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvV6f-0000PQ-NO for qemu-devel@nongnu.org; Sun, 19 Apr 2009 07:22:41 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:57139) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvV6f-0000Tx-7B for qemu-devel@nongnu.org; Sun, 19 Apr 2009 07:22:41 -0400 Received: from localhost ([127.0.0.1] ident=stefan) by flocke.weilnetz.de with esmtp (Exim 4.69) (envelope-from ) id 1LvV6d-0001Wi-8l for qemu-devel@nongnu.org; Sun, 19 Apr 2009 13:22:39 +0200 Message-ID: <49EB097F.6050100@mail.berlios.de> Date: Sun, 19 Apr 2009 13:22:39 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH] Rename qemu into qemu-system-i386 and install a compat symlink References: <20090418160104.GA18120@volta.aurel32.net> <49EA030A.8090104@codemonkey.ws> In-Reply-To: <49EA030A.8090104@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori schrieb: > Aurelien Jarno wrote: >> For historical reasons, qemu system on i386 is called qemu instead of >> qemu-system-i386. This seems to confuse users. >> >> This patch installs it as qemu-system-i386, and create a compatibility >> symlink qemu -> qemu-system-i386 as some tools may call it that way. >> We can change or remove this symlink after a few releases when all the >> tools have migrated to this new name. >> > > I agree. > > Regards, > > Anthony Liguori > I agree partially. For the current situation, qemu-system-i386 is reasonable, and a symbolic link to qemu for non-Windows platforms is a good solution. For the (maybe far) future, I'd prefer to have a qemu executable which is either a frontend to the different user and system emulation executables or which replaces all these executables. This new qemu could auto-detect the target architecture from -M (cpu parameter) or from ELF file argument. It could also auto-detect user or system mode. Calling the correct backend qemu-xxx is then straight forward. And finally, keeping qemu (with enhanced functionality) would also allow to keep the existing documentation unchanged: qemu-doc.texi has lots of references to qemu! Regards, Stefan Weil