Received: by 10.213.65.68 with SMTP id h4csp229709imn; Wed, 21 Mar 2018 17:16:52 -0700 (PDT) X-Google-Smtp-Source: AG47ELszVLCEH/aATtqdQKv+qrBoeBNHWbcbzBrzknEYNSGxHc0QfpU9D6k3phaUkzaR3Jsih9Ld X-Received: by 2002:a17:902:5681:: with SMTP id j1-v6mr6588136pli.383.1521677812510; Wed, 21 Mar 2018 17:16:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521677812; cv=none; d=google.com; s=arc-20160816; b=MDvzIvWS1fZkicGi1ALzUpg6IKvfkGyOmds1JCWrOsbAvJo2fNLmCmyjAMk9FllzqA CKTR9WwklfAndQsi6GauYpu4jyfMReaHKZW49e1D2lFN1BNbofHXgQ1kSaemTyXkos8k 3gGWPZzAlQVlYcylu2RX9M8vEB02oma9qSjdc0LRPjlRNP4M553Nw1jhtgiSuH0Ez2sj 4VggxqzS4FyqEtNPZzJPFrIINWEj0dZtKFJ+dGgQP0HO81b2noGyMZp3wDEUd5smzqF3 fzsZurJCy2ds6fLqMcsaN6q1a2HgFsQqOnQSjQyYyhB454GniA0jvtmRENQVuOyyxb+b DBmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=j7z33Ul0pvCHSGgWAtah8qJ9hKZeHgUmxl3ZHJZ9zUY=; b=ccmpouEgMv2LSLXLFKslfUT/ZflX8K2OJotKsDBKTGows4Q9Kh4BnlLT3hiOcFdphJ Yab3j+w8cuJA6aIjetJ5pKgX/U9/X3nlmV1HUNNwzlhBLpJamNA/EAtR2untcl2YzQ0Z 1rR2tsHXAeQCNvSxlpfKtjXun3nJO38wrsdk4dn74mpuBUctDfAZoOEIRjE881r1Vinw vzVqjYQSk9KTyddyKiHUuRMFZ5kXWDIqloX66cZQD5S96mTlaNY8cpW9G1cWUn7YQ5zv YziNaiQncu1GeVM3W3JXbH8GgIMnpKluo/RtRQ8Kx68Ska3YzAM0bJ5m0+wrpjSjgY0m +YCw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14si3498207pge.393.2018.03.21.17.16.37; Wed, 21 Mar 2018 17:16:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754220AbeCVAPq (ORCPT + 99 others); Wed, 21 Mar 2018 20:15:46 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:44166 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753884AbeCVAPn (ORCPT ); Wed, 21 Mar 2018 20:15:43 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1eyntE-0005mp-Vb; Thu, 22 Mar 2018 00:15:33 +0000 Date: Thu, 22 Mar 2018 00:15:32 +0000 From: Al Viro To: Ingo Molnar Cc: Linus Torvalds , Dominik Brodowski , Linux Kernel Mailing List , Arnd Bergmann , linux-arch , Ralf Baechle , James Hogan , linux-mips , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , ppc-dev , Martin Schwidefsky , Heiko Carstens , linux-s390 , "David S . Miller" , sparclinux@vger.kernel.org, Ingo Molnar , Jiri Slaby , the arch/x86 maintainers Subject: Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation Message-ID: <20180322001532.GA18399@ZenIV.linux.org.uk> References: <20180318161056.5377-1-linux@dominikbrodowski.net> <20180318161056.5377-5-linux@dominikbrodowski.net> <20180318174014.GR30522@ZenIV.linux.org.uk> <20180318181848.GU30522@ZenIV.linux.org.uk> <20180319042300.GW30522@ZenIV.linux.org.uk> <20180319092920.tbh2xwkruegshzqe@gmail.com> <20180319232342.GX30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319232342.GX30522@ZenIV.linux.org.uk> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 19, 2018 at 11:23:42PM +0000, Al Viro wrote: > Benefits: > * all SyS... wrappers (i.e. the thing that really ought to > go into syscall tables) have the same type. > * we could have SYSCALL_DEFINE produce a trivial compat > wrapper, have explicit COMPAT_SYSCALL_DEFINE discard that thing > and populate the compat syscall table *entirely* with compat_SyS_..., > letting the linker sort it out. That way we don't need to keep > track of what can use native and what needs compat in each compat > table on biarch. > * s390 compat wrappers would disappear with that approach. > * we could even stop generating sys_... aliases - if > syscall table is generated by slapping SyS_... or compat_SyS_... > on the name given there, we don't need to _have_ those sys_... > things at all. All SyS_... would have the same type, so the pile > in syscalls.h would not be needed - we could generate the externs > at the same time we generate the syscall table. > > And yes, it's a high-squick approach. I know and I'm not saying > it's a good idea. OTOH, to quote the motto of philosophers and > shell game operators, "there's something in it"... FWIW, I have something that is almost reasonable on preprocessor side; however, that has uncovered the following fun: void f(unsigned long long); void g(unsigned a, unsigned b) { f((((unsigned long long)b)<<32)|a); } which does compile to "jump to f" on i386, ends up with the following joy on arm: mov r3, r1 mov r2, #0 push {r4, lr} orr r2, r2, r0 mov r0, r2 mov r1, r3 bl f pop {r4, lr} bx lr with gcc6; gcc7 is saner - there we have just mov r2, #0 orr r0, r2, r0 b f The former is r3 = r1 r2 = 0 r2 |= r0 r0 = r2 r1 = r3 The latter - r2 = 0 r0 |= r2 which is better, but still bloody odd And I'm afraid to check what e.g. 4.4 will do with that testcase...