From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKmXn-0006Hw-1y for qemu-devel@nongnu.org; Mon, 09 Feb 2015 06:30:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKmXi-00051P-I2 for qemu-devel@nongnu.org; Mon, 09 Feb 2015 06:30:22 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:21622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKmXi-00051A-Ct for qemu-devel@nongnu.org; Mon, 09 Feb 2015 06:30:18 -0500 Message-ID: <54D89A42.2010004@imgtec.com> Date: Mon, 9 Feb 2015 11:30:10 +0000 From: Leon Alrae MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Maciej W. Rozycki" , qemu-devel@nongnu.org Cc: Aurelien Jarno On 11/12/2014 00:21, Maciej W. Rozycki wrote: > Rework the MIPS ABIs and CPU emulations available according to the=20 > following target list: >=20 > - mips|mipsel -- 32-bit CPUs only, system and user emulation mode= ,=20 > o32 user ABI, >=20 > - mips64|mips64el -- 32-bit and 64-bit CPUs, system and user emulatio= n=20 > mode, o32 user ABI, I'm not sure if it's a good idea to change the meaning of linux-user qemu-mips64 and qemu-mips64el, this will cause unnecessary confusion in my opinion. I think we=92d be better off leaving it consistent across QEM= U versions. Do we really need MIPS64 executables for o32 ABI for linux-user? They would merely enable MIPS64 CPUs to run o32 programs. So far we've been handling this by using 32-bit CPUs (artificial if the real CPU don't exist), therefore I don't see an issue here. Also I'm concerned that once we add new executables, it will be difficult to revert that change later, thus we must be certain that this is the right way to go. In general I would prefer to avoid changing the user interface and pain related to breaking people's scripts whenever it's possible. Regards, Leon