From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752590AbcFFUjh (ORCPT ); Mon, 6 Jun 2016 16:39:37 -0400 Received: from mail-bn1bon0087.outbound.protection.outlook.com ([157.56.111.87]:2913 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751058AbcFFUjf (ORCPT ); Mon, 6 Jun 2016 16:39:35 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Mon, 6 Jun 2016 23:39:26 +0300 From: Yury Norov To: "Manuel A. Fernandez Montecelo" , "Pinski, Andrew" CC: "Norov, Yuri" , , , , , , Subject: Re: FW: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures? Message-ID: <20160606203926.GA3372@yury-N73SV> References: <20160606185149.GA11555@reva.itsari.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [50.233.148.158] X-ClientProxiedBy: DM2PR0501CA0028.namprd05.prod.outlook.com (10.162.29.166) To BN4PR07MB2225.namprd07.prod.outlook.com (10.164.63.143) X-MS-Office365-Filtering-Correlation-Id: e7d7b8a9-c2e9-44a3-016d-08d38e4aa8b5 X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2225;2:69Lz1LlpYtUZyCgp0QTk4qevbfWZ39S3xlps54UDvJ+PiI6uxTZK/bjwJBPqjtVdeOi9TAOLQPtwRoxg959rJo6SYtSbSXenjycvaCMS04ErtN6liYsejW0T6G5wwgjm+WQr5T/o92dxb79Sx6mpzZE2uwTZS5mHoPrRg275sB8oCT1zUqXNGNx1vT9B9qDA;3:wqMNXFh2GqWZpVdyxijR5Xg4SrirNp4CR60+NI9lF7jfr0KR8AQ0rI7RzhePmaPzChTAs0qGgRCYTIX0bFKd9IGiUTlpZrILUt0CakPydnKg23afFGs3Zbbv47xC/N6y;25:jPXcmUWpv12Axu7ErBotXyujboRdcQIrdJvYcKXouzLb6FBfLcR+S09G1bBnxBIVJLfpOqu4UmBHgQm2XWMw7QycqGRVK6qKuHS/DZ7MnlvlI7XeXB1GOfQLlaA17f+owRgG5z8Y5eIv4y1iqNcgWtcl2wNcsWgsAUFLpN+Ft8oFZ8EhB3NmcUPXyVLGApjggZgjW3ZdaNbuqFb8MapM6dapcfpoBjnqGb0yBwUh4StsjfsM2nqI6/ibZ8ZQZEbsDExXLJraEthSUndw/BRL2XlWt0h4P2kEblmS8dkfzBbtuy5DVPX8UYsVuppcW8AASysRWNt/NEe3Vvb50yyygKrNSIi0nlvOKGHENdU3tAdk4vK1CryRzq3ni3vGOypd/38jcSYgCLUv/iMCgWouLuQhkdkXnvtstuY9hulc65Q= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN4PR07MB2225; X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2225;20:4SYXGO7Uhqv9f2wLQnRRxPNLr9RXlQC2RiWYNzisqRZoy1X2AsMXJLsF0mEse1lxU3kfYG+tTt/gZxVr9+35wU7VnXpY63nqqDGkzSoIELwd2Tmjkc8OCV9AXE99xMpK7srRTvcIqS+oIYfFCXlsYs7mGy5skfMs3wYkq9kFuoQtmcW9nxEQftNlcnef6QFOfVlz6OEqQqxhiZ5kNChgEOZo+VrvyYmUJ6H9i+RBmkyJNT6c5eotRCra7JaI1UiY354rriA8fONtgGgWyCxd2fuMUnFlwCxe5SnuQJ5PJFqyQohxP4IL8zb7s8eSusR/mSuRKyS/0IOXX6VZ3frnFWoe7k4u9jjESvQ7M3+JwXtjwobIIBjSPy0KsCXeaa6SZU2MU1DDzG25hwkwd+ysCHv+QNJ+4mCqhTNiWADp9TqK+WuZWKqXDbJlrQW4ryOlZLZLtMYb7Wrj8pJqKAbgg+m/HuKM/9k0YXTvLhoo1OWyTG/9/qvCEBzwB53KOLE/aepBIkX45SYsj9CvEgOc/rytA00w/BwJVxLYvzALggZoudA5NlYBlBNN5fiw+W1Qs8IJ6xw0ny8SuIO/0Lm/FDgLKeO4W7eC7VfMAcxv15M= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(9452136761055)(278021516957215); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);SRVR:BN4PR07MB2225;BCL:0;PCL:0;RULEID:;SRVR:BN4PR07MB2225; X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2225;4:3pH/xLyxBlRomFFhgSPVg0IbhAO6RIpOvvGpxxq6PG3q2MDiv+8kzk6GrVSP19hIpaZkxkyM81zjOYIxm5hNGssWXS4BJ+l2CVZ9a8817l+r4+pdlyX27ZUvWutiMsYO+UAbxJHsPDvVq/GUHrEqBw2NoCkg0A58I23EHOnz76Rv2cvr2RDJtyRoqPm0h8iA3hR53QwbU2D1GBSxj3YQ3A1+6PejAX0pYuGVdjeOfC9l1F9OIANeNoq81JbNjKfh5o/DUSLlJKkbcdtQY/icvkoclnJVVTyBIp0PmeLKVd6cyS5yu5DJY/gk8iPjb4z/Z+LTf3TQGRJRuLzJNByWt7faF4vo73XDwKAwVbBS4GXnONFf7E8lx4uUKeBmXx6uvNYk6xp8xVOol2PFqvK83Dj2LEa0GwSGOFumRpmgJGnPLx7wOts7CXg9mHpwCqV4QIy5mYJ3piGaK4TmLf8UCGk+QuDz7TPqv+24mw7jmvI= X-Forefront-PRVS: 096507C068 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6069001)(189002)(377454003)(199003)(24454002)(13464003)(68736007)(77096005)(23726003)(1076002)(106356001)(15975445007)(76176999)(2950100001)(54356999)(5004730100002)(5890100001)(47776003)(83506001)(2906002)(33716001)(50986999)(19580405001)(8676002)(101416001)(105586002)(81166006)(9686002)(19580395003)(189998001)(81156014)(42186005)(6116002)(3846002)(4001450100002)(50466002)(4001350100001)(92566002)(76506005)(586003)(33656002)(5008740100001)(66066001)(4326007)(97756001)(5001770100001)(97736004)(46406003);DIR:OUT;SFP:1101;SCL:1;SRVR:BN4PR07MB2225;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN4PR07MB2225;23:LJDZo4Fs7pNrFSYZRTXFUgC8LPUlIGupbVA9L/UMZ?= =?us-ascii?Q?b4ntwDLRdA2uNQxg/JhIuyKIj1SyHEHRHTJAPna8l8rQT98RuJfOWOVSXLfH?= =?us-ascii?Q?5K5Fpi+N2CtigYhFSCgSyRNcXqgBdJGdeKmAgRZlygoOpAk/eo3MnEM0SPCs?= =?us-ascii?Q?g6CV7WIrAejiiuGyF8iiTRZBSmdmraxm/Jn1lkPDKGNzKKeUfak2uFmkt440?= =?us-ascii?Q?ucJS0R3jXNaiX9VnN8UDJyHjMJnkAG5pG0v44UvXM87QNL1I1J5C3EF1+KU+?= =?us-ascii?Q?E79r5MMyJ8VQ9eAFk837+Av8XSGEpMFzZFMC8eXlN4xYA14Nnqvfx1tn2rhf?= =?us-ascii?Q?FbPvkazYyD4NnIuYXngFV2slXxDxVUl47Xh5XUGwvK/EJmR4kqgSKLrce2/k?= =?us-ascii?Q?Vry8iQjY8SeHFWMy6hq7sp2FXrRlCABGrztTWCQ1EwZQrRDJ4jf4UjerwHyO?= =?us-ascii?Q?KLfJg5lWOeqsidvTpmQdjkUGLa6p7r8re3urvJxuJxfRjO0jkZ86Rd7pMJaE?= =?us-ascii?Q?yamGMaFKmui+2k8iifEJJHK55+TGFZ603HgVxQzqB6OOjuiJ5DLlalbm799l?= =?us-ascii?Q?VXXCRLbqxlFxtzi7pjiKhovTbKE6gVmRCXV/LXoMw1XHhJPx1GBcTFt0HKGE?= =?us-ascii?Q?La2D9jMoUPg2i80KRpCUG2RSNRr6bml2c1MvmcPTD3FKZAlPLJMxgmL3JvGb?= =?us-ascii?Q?FU4Zb5tEJ6/aM8+wXpfTEddzrbjG361Dq5f5YE2dDX7sNoIgtx+lOnLZfSd2?= =?us-ascii?Q?aSY2rdwGJyg1p2eppxQ89Yuu2zwC6Y2VGdjcl/NWuY4QqYvIicAEc4r06gAE?= =?us-ascii?Q?NHO1g1Q1Djliay5g3Bm+9Xgk0Ub6mIHFqzVtiisR6OZa07W72t8ygBHojryK?= =?us-ascii?Q?ZCfL3QYkhOL2gfhQ66JW4A0v0P2HthxSRl0g5anvKd+5r53c3np/ZudJGhKl?= =?us-ascii?Q?G4STALi+RBsTfSSMiA/mVlOR1H7tajhGfH3H4ahQJ7bMLL0VXV25166uCHBS?= =?us-ascii?Q?ctWN1mZActHlTlDIhgsruAWQu6TgwKcsM8QCZiy8DcECy0DmPyeMarVZi2qg?= =?us-ascii?Q?DQxmeyxoavnLpDXuhz6n7/z9Q4QXJ+At+yVzkmvmXfR4e/DbqkxjG3LQ6Lf+?= =?us-ascii?Q?9vgC6a8y5mzL8wGJZe1pyX3yn0AZD5BXhaCgEhUfYCWFHT8/EmtqCwjxvm4G?= =?us-ascii?Q?hRUVVF30dmIES48a+KzppkFauck5LF84ldW29JYMl2vwuOyqCDhR+1CizDKP?= =?us-ascii?Q?oO4m1Actk+suykkiShbIMegCKbA46L/Zwa8rIJJtEoE8HQMhAd/WSfGRtNY0?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1;BN4PR07MB2225;5:Pb0db+e/ucFh+i6e5eIBJDAwjVV8jXNWQunGurMR3mtXWEaZUhc49SCFMWbLnFcMdka1Ppb/9tS4miLOUi4/laB0FzkfhDJqOtP4SEp/Um3JzNwrqgydXUtjLDz+1y0XzQBkVclwqZm5NlO7PgZzyw==;24:zSqP3w3d9FXvPKB6S4sh/DXCJVPXMcSUm9OLmUN9XMTWM8yxcLM5RxIz3kio931dDRjTD7R+ZGGCRqV+oH2b5YwfU4YhZUtxGRd40wXxDgU=;7:fi+nIaSl3nHtWN6hALg/qWPNrUnRxYbT+hSv4pkfMwFcNc7XxuGnl2VVgPzhXITf57+t6Ul10agFXRSheXiuhzbuXJnk1d9ySQQt2+Csdm9COiCntOBI8Qn5bRGZLj/AHgzOH1e6YJRCmC3YfDj/I36ltWoQyMveNoVEU9dr683AyWma1FatuzJFilSnFRnusu4x2OUDhtl1qVYNNOL6TPsvSzl3/GnPdMc1wbxCxfE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2016 20:39:29.6343 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN4PR07MB2225 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 06, 2016 at 10:03:49PM +0300, Pinski, Andrew wrote: > You may also want to look into this thread. It just got started too. > > -----Original Message----- > From: Andrew Pinski [mailto:pinskia@gmail.com] > Sent: Monday, June 6, 2016 12:03 PM > To: Pinski, Andrew > Subject: Fwd: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures? > > ---------- Forwarded message ---------- > From: Manuel A. Fernandez Montecelo > Date: Mon, Jun 6, 2016 at 11:51 AM > Subject: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures? > To: libc-alpha@sourceware.org > > > Hi, > > When discussing how to implement these types for the RISC-V architecture (32, > 64 and 128-bit flavours), it seems that there's a drive [1][2] to force new > arches to use the 64-bit versions of these types (so they would be the same > as __OFF64_T_TYPE and __INO64_T_TYPE), even for 32-bit arches. > > Does this look like a reasonable approach? > > https://github.com/manuelafm/riscv-gnu-toolchain/commit/764f5ac958618c1ca8761845864164365282ffbd > > (also attached) > Hi Manuel, It seems, we are working on the same issue. AARCH64/ilp32 ABI is going to work the way you described below. I found next types to be turned to 64-bit [https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1157969.html]: > So for AARCH64/ILP32 we turn next types to 64-bit in glibc: > #define __INO_T_TYPE __UQUAD_TYPE > #define __OFF_T_TYPE __SQUAD_TYPE > #define __BLKCNT_T_TYPE __SQUAD_TYPE > #define __FSBLKCNT_T_TYPE __UQUAD_TYPE > #define __FSFILCNT_T_TYPE __UQUAD_TYPE > > And define: > # define __INO_T_MATCHES_INO64_T 1 > # define __OFF_T_MATCHES_OFF64_T 1 > # define __BLKCNT_T_MATCHES_BLKCNT64_T 1 > # define __FSBLKCNT_T_MATCHES_FSBLKCNT64_T 1 > # define __FSFILCNT_T_MATCHES_FSFILCNT_T 1 > > If so, stat and statfs structures for ilp32 are turning the same as > for lp64. And so we'd handle related syscalls with native lp64 > handlers (wrapped, to zero top halves) in kernel. ^^^ The main goal ^^^ > > And we don't need stat64 for ilp32. > > Did I miss something? Is everything correct? > > https://github.com/norov/glibc/commits/ilp32-dev > https://github.com/norov/linux/commits/ilp32 > Under links below you can find my current progress on this work. Also notice how I redeclared struct timespec. #ifdef timespec_needs_pads # if __BYTE_ORDER == __LITTLE_ENDIAN struct timespec { __time_t tv_sec; /* Seconds. */ int sec_pad; __syscall_slong_t tv_nsec; /* Nanoseconds. */ int nsec_pad; }; # else struct timespec { int sec_pad; __time_t tv_sec; /* Seconds. */ int nsec_pad; __syscall_slong_t tv_nsec; /* Nanoseconds. */ }; # endif #else struct timespec { __time_t tv_sec; /* Seconds. */ __syscall_slong_t tv_nsec; /* Nanoseconds. */ }; #endif /* timespec_needs_pads */ I'm little worry about correctness of this approach. But if you define the whole new RISC-V arch, I think, new timeskpec is OK there. BTW, just curious, why RISK-V. I think it will work for CISC as well. And what '-V' means? Yury. > > [1] At least from people in the Linux kernel community. > > [2] A further suggestion was that all new arches should default to have > the same width for these types, 64 bits, and override __OFF_T_TYPE > and __INO_T_TYPE for all the existing architectures where they are > currently 32-bits. I don't know if this is desirable at this point. > > > Cheers. > -- > Manuel A. Fernandez Montecelo