Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp7362imc; Thu, 10 Jan 2019 16:31:31 -0800 (PST) X-Google-Smtp-Source: ALg8bN6qDTAfx/QDVgTkEvcwmEdhcCR3jOSy/y+fiRt76fe/4jpG84x84fga7WNBzfRU4UGzlYoP X-Received: by 2002:a65:5bc4:: with SMTP id o4mr11467178pgr.426.1547166691105; Thu, 10 Jan 2019 16:31:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547166691; cv=none; d=google.com; s=arc-20160816; b=fAL6H5jmJgz+oplXhLf2BtASNQa1im9KzpL8tj9ZabRDfSHQ6pgagPBusGm9kZqbiH XQg4l0ry7/DQaCKiTtP1x94YbsRFBl/e5wS1K87OitfwrzaPYFNWeGNcS4OJrewzavJg pig4tLMOTlu2+lp9+MPs2h7QnnWsWoHaHF+jGjOBdcMvNhUF97j13pbSZmJwNoGrBXwx vBdZYYzC4TnsHN7EGSzyttb/3/gBGp2b0qLz6iM/YJZTaSKWNxZB42de/KeZg7rrYMc+ q/ovitgk0CQvOF8dQlQ4RdgHUM5XOkpOP+iwb5EKXVwROq42QtJFCFe0THxsQvwhNU2T CDSw== 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:mail-followup-to :message-id:subject:cc:to:from:date; bh=NB4YMRvJR1qR9L7dEEaLk1EOoysz0JY6o8x4LD/CFxs=; b=sH3HnJZNkaAA4cEOQeILkyrKmD64kifn4a/nBQiq5Wf7McQpfitUvK76R9GamHkWKr dK5LCky6X0Fczv7hKjvxcCCpwtprKxr0WObsuEtL3vCExs+7OJSRhAKZ0VcAQ0T/UTvE kKzQ3tvJwmbYj2Y8sGdkX7I9BhzNf5Qj+JsU7iDwDKGSAj6EY+Zrl7KzBU0vurPNQRJ6 MMM1jIvdgyKxwsMd16FZm5sK5/M82Gp4o3yY5XEeZ4xsoAArGC4jDMhEJDMQeAcXwAus pPiF9Si7AOeyiRqXH7UUDox/tvQYc0tr+y/BEzc++HWTQLqwXuhXFgGZovAnJD2VmHpd MPXQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=orcon.net.nz Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4si12497704pls.262.2019.01.10.16.31.16; Thu, 10 Jan 2019 16:31:31 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=orcon.net.nz Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730071AbfAJXP4 (ORCPT + 99 others); Thu, 10 Jan 2019 18:15:56 -0500 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:53442 "EHLO smtp-1.orcon.net.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728787AbfAJXPz (ORCPT ); Thu, 10 Jan 2019 18:15:55 -0500 Received: from [121.99.228.40] (port=24388 helo=tower) by smtp-1.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1ghjX2-0006MW-NK; Fri, 11 Jan 2019 12:14:37 +1300 Date: Fri, 11 Jan 2019 12:14:31 +1300 From: Michael Cree To: Arnd Bergmann Cc: Joseph Myers , y2038 Mailman List , Linux API , Linux Kernel Mailing List , Ivan Kokshaysky , Matt Turner , Russell King - ARM Linux , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Paul Burton , Helge Deller , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Rich Felker , David Miller , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Max Filippov , Firoz Khan , "Eric W . Biederman" , Deepa Dinamani , Dominik Brodowski , Andrew Morton , Davidlohr Bueso , alpha , Linux ARM , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, Parisc List , linuxppc-dev , linux-s390 , Linux-sh list , sparclinux Subject: Re: [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038 Message-ID: <20190110231431.ho6mjhjkj4p47hww@tower> Mail-Followup-To: Michael Cree , Arnd Bergmann , Joseph Myers , y2038 Mailman List , Linux API , Linux Kernel Mailing List , Ivan Kokshaysky , Matt Turner , Russell King - ARM Linux , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Paul Burton , Helge Deller , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Rich Felker , David Miller , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Max Filippov , Firoz Khan , "Eric W . Biederman" , Deepa Dinamani , Dominik Brodowski , Andrew Morton , Davidlohr Bueso , alpha , Linux ARM , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, Parisc List , linuxppc-dev , linux-s390 , Linux-sh list , sparclinux References: <20190110162435.309262-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote: > On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote: > > > > On Thu, 10 Jan 2019, Arnd Bergmann wrote: > > > > > - Add system calls that have not yet been integrated into all > > > architectures but that we definitely want there. > > > > glibc has a note that alpha lacks statfs64, any plans for that? > > Good catch, I missed that because all other 64-bit architectures > have a statfs() call with 64-bit fields. I see that it also has an > osf_statfs64 structure and system call with lots of padding and some > oddly sized fields: f_type, f_flags and f_namemax are only 16 bits > wide, the rest is all 64-bit. > > Adding the regular statfs64() should be easy enough, we just need to > decide which layout to use: > > a) use the currently unused 'struct statfs64' as provided by the > alpha uapi headers, which has a 32-bit __statfs_word but > 64-bit f_blocks, f_bfree, f_bavail, f_files, and f_ffree. > > b) copy asm-generic/statfs.h to the alpha asm/statfs.h and > change statfs64 to have the regular layout that we use > on all other 64-bit architectures, using all 64-bit fields. > > The other open question for alpha (as mentioned in one of the > patches I sent) would be whether to add get{eg,eu,g,p,pp,u}id() > with the regular calling conventions. I would be interested in seeing those provided on Alpha. There are a handful of projects choosing to sidestep glibc for these syscalls and they break on Alpha. Such projects are never keen to include special assembler code (because the extant syscalls on Alpha are not C ABI compliant) to support a legacy arch. Cheers Michael.