From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427281AbcBSIYi (ORCPT ); Fri, 19 Feb 2016 03:24:38 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:49489 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1427268AbcBSIYg (ORCPT ); Fri, 19 Feb 2016 03:24:36 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Yury Norov , "Zhangjian (Bamvor)" , pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, broonie@kernel.org, jan.dakinevich@gmail.com, joseph@codesourcery.com, schwab@suse.de, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, christoph.muellner@theobroma-systems.com Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Date: Fri, 19 Feb 2016 09:23:35 +0100 Message-ID: <208897488.c0hkBy2G1S@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160218223506.GA7816@yury-N73SV> References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <56AC38F1.2030608@huawei.com> <20160218223506.GA7816@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:E/opwllJurE0P7ZnPDLS3S/mzJ2HA4i8vqiw4Y1ReSvvG/WsR5Z DFxHjvlen5qDjBZlthSNuKOPBI7puoFqcgawpj2YcL0rFE1aAqklShPd1WSx+nt9c8t0PDg zhIL+kn4FtZiEsJgRW7R+2ZFc2qiVmNkPlomP1a4r+F11eLwP9hnCvIga9ZkGenSULVyTHr f10FB1OU7Yn8BOLR2c6qQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:kOFfKiQshsQ=:SNdsdP88alZG9WrDdvGnHA iDAXSgnrvvzLXU1IboH/Lw0+gj+NxX2ZXwY+LTi4XA5avwwtxIOc+u7u5yEZrnla4JpbAa1XJ q7jFHYXzhmMTgM0KHlKg3qIXVx8/V6C/QU3kVRpqw6a1hqiCD9k6Uz/q+bc+DxcFBg1ng6K6e bafcpaTGFSkpe+QRML+lNl80CNliFY7XcqQtv8iNz+iiG4iGkEhHLJqOuBJD+3G7dQ4+C+1DR JhO24cxQrsxAAnZ77zKRH6c6XdIsu0I8FMwP7R11wSW/v1Vq3TFytvh2NlpvWKWElh4Sa/gzA SpWeZnetQas1/sCbOXfZ7uhKtnpU2R7V/vn/GjPUNVSOZZIObCTKaG5htUn5hNcOt0cCC/Juy 3/6/M1DAFHFNKjP6cBgXMVJjLLrAnKKaE+8a+IXch07xSdsD1F61CMRdIhqIFloAsejlWwnch 51SxhzLRdyHPOXjophUXxbIlZODDEwbtUj7Lv7t1pROEnktnx4CZZdRBnEg1TkwbGHiAujCC9 HLByJ4eity3XVgwZvQEU5qm2TEwZAUSuv6DM5XI+d4ehchAlrV8IO8aTVd3sETx1TxWzQYKP9 3qCeMHbnwoP5yRhQ6PbEnGCzV3qoKkX86q1ZH3rDWf2yhF2MjuutIwOADK1LlXhRpS1LLfzb2 drrluECcU52i3Bi4ezoAtKtvj/+Nx10XaH1sxWyI0+KqfQDRSMwlJvRF7szZUiagjw/ujk5EA XVc9XjuMKb4f6x84 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > Hi Bamvor, everybody, > > I have new glibc that follows new ABI: > https://github.com/norov/glibc/tree/new-api Ah, very good! > It's very draft and dirty, but you can try it with RFC5. > My fail list for ltplite looks like this: > pipeio_4 FAIL 11 > abort01 FAIL 2 > clone02 FAIL 4 > kill10 FAIL 2 > kill11 FAIL 2 > lstat01A FAIL 1 > lstat02 FAIL 1 > mmap16 FAIL 6 > nanosleep03 FAIL 1 > nftw01 FAIL 1 > nftw6401 FAIL 1 > open12 FAIL 2 > pathconf01 FAIL 1 > pipe07 FAIL 2 > profil01 FAIL 11 > readdir01 FAIL 1 > readlink01A FAIL 1 > rename11 FAIL 2 > rmdir02 FAIL 2 > sigaltstack01 FAIL 1 > sigaltstack02 FAIL 1 > stat03 FAIL 1 > stat04 FAIL 1 > stat06 FAIL 1 > umount2_01 FAIL 2 > umount2_02 FAIL 2 > umount2_03 FAIL 2 > utime06 FAIL 2 > writev01 FAIL 1 > mtest06 FAIL 11 > rwtest01 FAIL 2 > rwtest02 FAIL 2 > rwtest03 FAIL 2 > rwtest04 FAIL 2 > rwtest05 FAIL 2 I have no idea whether this is good news or bad news ;-) In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc I see that you are passing __IPC_64, I thought we had already resolved that in the kernel. We might need to go back to this. In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 you are defining a struct __kernel_stat64 in the glibc. Is this the expected way to do it? I would have thought you'd get the definition from the kernel headers. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 19 Feb 2016 09:23:35 +0100 Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64 In-Reply-To: <20160218223506.GA7816@yury-N73SV> References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <56AC38F1.2030608@huawei.com> <20160218223506.GA7816@yury-N73SV> Message-ID: <208897488.c0hkBy2G1S@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > Hi Bamvor, everybody, > > I have new glibc that follows new ABI: > https://github.com/norov/glibc/tree/new-api Ah, very good! > It's very draft and dirty, but you can try it with RFC5. > My fail list for ltplite looks like this: > pipeio_4 FAIL 11 > abort01 FAIL 2 > clone02 FAIL 4 > kill10 FAIL 2 > kill11 FAIL 2 > lstat01A FAIL 1 > lstat02 FAIL 1 > mmap16 FAIL 6 > nanosleep03 FAIL 1 > nftw01 FAIL 1 > nftw6401 FAIL 1 > open12 FAIL 2 > pathconf01 FAIL 1 > pipe07 FAIL 2 > profil01 FAIL 11 > readdir01 FAIL 1 > readlink01A FAIL 1 > rename11 FAIL 2 > rmdir02 FAIL 2 > sigaltstack01 FAIL 1 > sigaltstack02 FAIL 1 > stat03 FAIL 1 > stat04 FAIL 1 > stat06 FAIL 1 > umount2_01 FAIL 2 > umount2_02 FAIL 2 > umount2_03 FAIL 2 > utime06 FAIL 2 > writev01 FAIL 1 > mtest06 FAIL 11 > rwtest01 FAIL 2 > rwtest02 FAIL 2 > rwtest03 FAIL 2 > rwtest04 FAIL 2 > rwtest05 FAIL 2 I have no idea whether this is good news or bad news ;-) In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc I see that you are passing __IPC_64, I thought we had already resolved that in the kernel. We might need to go back to this. In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 you are defining a struct __kernel_stat64 in the glibc. Is this the expected way to do it? I would have thought you'd get the definition from the kernel headers. Arnd