Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932531AbcC2UPW (ORCPT ); Tue, 29 Mar 2016 16:15:22 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:49093 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932348AbcC2UPS (ORCPT ); Tue, 29 Mar 2016 16:15:18 -0400 Date: Tue, 29 Mar 2016 20:15:10 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Arnd Bergmann CC: "Zhangjian (Bamvor)" , Yury Norov , , Andreas Schwab , , , , , , "jijun (D)" , , , , , , , , , Bamvor Zhang Jian , Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 In-Reply-To: <3467083.D7LuvS9l35@wuerfel> Message-ID: References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <3298847.t7vI4YM3gJ@wuerfel> <3467083.D7LuvS9l35@wuerfel> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1174 Lines: 26 On Tue, 29 Mar 2016, Arnd Bergmann wrote: > How do we do it then? Should we just define __USE_FILE_OFFSET64 > unconditionally for all new 32-bit architectures and leave the > code dealing with 32-bit off_t/ino_t in place but unreachable, to > minimize the differences? Defining __USE_FILE_OFFSET64 unconditionally would prevent glibc from building (see: how the patches a while back prototyping changing the default had to disable the change when glibc itself is built). A change in the default, though desired (someone needs to pick up those patches together with the analysis done of possible impact on distributions), should not be tied to a new port, and would need to be discussed thoroughly on libc-alpha. > Or should all the obsolete types be defined the same way as their > replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE > and use the same binary implementation regardless of FILE_OFFSET_BITS? I think so (along with using wordsize-64 sysdeps directories as far as possible, like x32 does). But design questions for a glibc port really belong on libc-alpha to get any sort of community consensus. -- Joseph S. Myers joseph@codesourcery.com