From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755111AbbK3Vuv (ORCPT ); Mon, 30 Nov 2015 16:50:51 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:49451 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754883AbbK3Vur (ORCPT ); Mon, 30 Nov 2015 16:50:47 -0500 From: Arnd Bergmann To: Yury Norov Cc: linux-arm-kernel@lists.infradead.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, broonie@kernel.org, jan.dakinevich@gmail.com, joseph@codesourcery.com, ddaney.cavm@gmail.com, schwab@suse.de, bamvor.zhangjian@huawei.com, philipp.tomsich@theobroma-systems.com, andrey.konovalov@linaro.org, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Mon, 30 Nov 2015 22:49:43 +0100 Message-ID: <3463212.HtU7UeIULQ@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151130202141.GA23254@yury-N73SV> References: <1447795019-30176-1-git-send-email-ynorov@caviumnetworks.com> <2133692.Tueq9xZUPQ@wuerfel> <20151130202141.GA23254@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:5WhcDA5nIb13TCEyWAZpSqqjgnsohScvntbhLUX6O/hFlf2p+AS R5fvJe8pT0b98gGllMyFKByW5qXiM26W4rl09Ax3MYw9LC4doqmjRPt+NeA3ekPRZzTGrk6 sm9HCJO+S+K5l//THdzGc10hcdqCwUuDoQp/DfVhOT73faxJ0PzMOl9w7VBPA1eYCxDDPWF LypGNY7iTkBe9o1X66YqQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:mbFVlscYQJE=:5QWbsgVbWtgat26U/35941 SlOJogWr9yZC1/n3NkStDWor9n8ZNIEwpPB5+AXNAi6qjmthtljMybQSFmsOGHkZU8T4vENUN 5NGoe1N8kSmDZv1dOWEhMOOyyr+T7uB83mvAS7JbrQ2eULcDpYx8i7axOltH3FxaBj6ZHqjPq SbpAl7m9cAGoPvIBalaIU0VH4ms14rsl3OmVo3MBrqgruGexOo7T2vXT9xd5QuG3GF4V3O0jq t6mAuX+9LKqsv3oJZNW23E2Azr28yKWTs1ebyl0GV+96e/3kPr4AbzTN27y/g878frVhCWvmV kOeaSCIXcPt9/uo91dV1MNCuoq3EhGQ2XQ+OTk7heQ8ZCA9El7Dc0/WHn3rvKk+9/ZxIRdDmJ aTxya1FrHhbt0XnbHSQM9Kg9CiqYKCIMkMjMo2opJ4JkzQMCk1EqB1my3YQRAta9mIUoROvNF Vg/BOj6sXbl8ZNQRvMzECbxmy8lst9rzGs79lzgVeQ46/NC+2Tp8wsrY/xkabhKNPgujyvZTt YT9q1lmUIq42MG3xhijluodEAiaO6HvK05kIwnKYBQcwHnm1ochw2v+eq67NCXw3tC9Ct1Ux6 Tmw4aQoTsbksk1e+SjiENloAWi7xXASoGGsaZpvkfzOVBTWN65DWtbGHpEoGIbb1dyNuY0y1i 6kQkdlkNs9WmBSyUKAlDLJodTshhT+m8FzYwpC2G3J246mqKze66v2xc1AkyWmK4G6c5FE/Co xTIFbGfJ1jCkxPue Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 30 November 2015 23:21:41 Yury Norov wrote: > On Mon, Nov 30, 2015 at 04:34:22PM +0100, Arnd Bergmann wrote: > > On Tuesday 17 November 2015 22:57:52 Arnd Bergmann wrote: > > > On Wednesday 18 November 2015 00:16:54 Yury Norov wrote: > > > > From: Andrew Pinski > > > > > > > > Add a separate syscall-table for ILP32, which dispatches either to native > > > > LP64 system call implementation or to compat-syscalls, as appropriate. > > > > > > I like it much better than the previous version, thanks for the rework! > > > > Hi Yuri, > > > > you must have missed my reply below. Are you still working on ilp32 > > or did you drop this thread because you got distracted with something > > else? > > > > I didn't miss it, and I continue with ILP32. I really appreciate your > attention and time you spend on ILP32. > > There's a tricky bug with signal stack, that Andreas also discovered. > It makes almost all tests that use posix threads crash. I want to fix > it and other bugs before next submission. > > I also update glibc to follow all recommendations, and I want to > upload it together with kernel patches. Ok. As a reviewer, I find long waits between submissions a bit annoying because that means I have already forgotten everything I commented on the previous time. Could we try to get consensus on how the syscall ABI should look before you start adapting glibc to another intermediate version? I think that would also save you duplicate work, as it's always possible that we misunderstand each other in the review. Also, when someone asks you questions during a review, please reply to those questions so we can get a common understanding of the facts and document that in the mail archives. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 30 Nov 2015 22:49:43 +0100 Subject: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it In-Reply-To: <20151130202141.GA23254@yury-N73SV> References: <1447795019-30176-1-git-send-email-ynorov@caviumnetworks.com> <2133692.Tueq9xZUPQ@wuerfel> <20151130202141.GA23254@yury-N73SV> Message-ID: <3463212.HtU7UeIULQ@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday 30 November 2015 23:21:41 Yury Norov wrote: > On Mon, Nov 30, 2015 at 04:34:22PM +0100, Arnd Bergmann wrote: > > On Tuesday 17 November 2015 22:57:52 Arnd Bergmann wrote: > > > On Wednesday 18 November 2015 00:16:54 Yury Norov wrote: > > > > From: Andrew Pinski > > > > > > > > Add a separate syscall-table for ILP32, which dispatches either to native > > > > LP64 system call implementation or to compat-syscalls, as appropriate. > > > > > > I like it much better than the previous version, thanks for the rework! > > > > Hi Yuri, > > > > you must have missed my reply below. Are you still working on ilp32 > > or did you drop this thread because you got distracted with something > > else? > > > > I didn't miss it, and I continue with ILP32. I really appreciate your > attention and time you spend on ILP32. > > There's a tricky bug with signal stack, that Andreas also discovered. > It makes almost all tests that use posix threads crash. I want to fix > it and other bugs before next submission. > > I also update glibc to follow all recommendations, and I want to > upload it together with kernel patches. Ok. As a reviewer, I find long waits between submissions a bit annoying because that means I have already forgotten everything I commented on the previous time. Could we try to get consensus on how the syscall ABI should look before you start adapting glibc to another intermediate version? I think that would also save you duplicate work, as it's always possible that we misunderstand each other in the review. Also, when someone asks you questions during a review, please reply to those questions so we can get a common understanding of the facts and document that in the mail archives. Arnd