From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 796ADC3A59E for ; Tue, 3 Sep 2019 00:03:05 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 76DE521881 for ; Tue, 3 Sep 2019 00:03:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76DE521881 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46MnGG1FgGzDqfp for ; Tue, 3 Sep 2019 10:03:02 +1000 (AEST) Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46MnCt6JDHzDqHF for ; Tue, 3 Sep 2019 10:00:58 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 46MnCs4mlgz9s7T; Tue, 3 Sep 2019 10:00:57 +1000 (AEST) From: Michael Ellerman To: Michal =?utf-8?Q?Such=C3=A1nek?= Subject: Re: [PATCH v7 5/6] powerpc/64: Make COMPAT user-selectable disabled on littleendian by default. In-Reply-To: <20190902114239.32bd81f4@naga> References: <87ftlftpy7.fsf@mpe.ellerman.id.au> <20190902114239.32bd81f4@naga> Date: Tue, 03 Sep 2019 10:00:57 +1000 Message-ID: <87h85us0xy.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michael Neuling , Madhavan Srinivasan , Andrew Donnellan , Arnd Bergmann , David Hildenbrand , Greg Kroah-Hartman , Heiko Carstens , linux-kernel@vger.kernel.org, Nicholas Piggin , "Eric W. Biederman" , Diana Craciun , Paul Mackerras , Joel Stanley , Allison Randal , Breno Leitao , Firoz Khan , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, Andrew Morton , Hari Bathini , Alexander Viro Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Michal Such=C3=A1nek writes: > On Mon, 02 Sep 2019 12:03:12 +1000 > Michael Ellerman wrote: > >> Michal Suchanek writes: >> > On bigendian ppc64 it is common to have 32bit legacy binaries but much >> > less so on littleendian.=20=20 >>=20 >> I think the toolchain people will tell you that there is no 32-bit >> little endian ABI defined at all, if anything works it's by accident. > > I have seen a piece of software that workarounds code issues on 64bit > by always compiling 32bit code. So it does work in some way. What software is that? > Also it has been pointed out that you can still switch to BE even with > the 'fast-switch' removed. Yes we have a proper syscall for endian switching, sys_switch_endian(), which is definitely supported. But that *only* switches the endian-ness of the process, it does nothing to the syscall layer. So any process that switches to the other endian must endian flip syscall arguments (that aren't in registers), or flip back to the native endian before calling syscalls. >> So I think we should not make this selectable, unless someone puts their >> hand up to say they want it and are willing to test it and keep it >> working. > > I don't really care either way. Sure. We'll see if anyone else speaks up. cheers