From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures Date: Fri, 18 Jan 2019 20:33:25 +0100 Message-ID: References: <20190118161835.2259170-1-arnd@arndb.de> <20190118161835.2259170-30-arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: y2038 Mailman List , Linux API , LKML , linux-arch , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Paul Burton , Helge Deller , Benjamin Herrenschmidt , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Rich Felker , David S. Mi List-Id: linux-api@vger.kernel.org On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > - Once we get to 512, we clash with the x32 numbers (unless > > we remove x32 support first), and probably have to skip > > a few more. I also considered using the 512..547 space > > for 32-bit-only calls (which never clash with x32), but > > that also seems to add a bit of complexity. > > I have a patch that I'll send soon to make x32 use its own table. As > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > not special. But let's please not reuse 512..547 for other purposes > on x86 variants -- that way lies even more confusion, IMO. Fair enough, the space for those numbers is cheap enough here. I take it you mean we also should not reuse that number space if we were to decide to remove x32 soon, but you are not worried about clashing with arch/alpha when everything else uses consistent numbers? Arnd