From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948981AbcBSOHx (ORCPT ); Fri, 19 Feb 2016 09:07:53 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:61706 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1948804AbcBSOHv (ORCPT ); Fri, 19 Feb 2016 09:07:51 -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, broonie@kernel.org, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, Nathan_Lynch@mentor.com, klimov.linux@gmail.com, "Zhangjian (Bamvor)" , schwab@suse.de, schwidefsky@de.ibm.com, jan.dakinevich@gmail.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Date: Fri, 19 Feb 2016 15:06:48 +0100 Message-ID: <91909204.T63Mn1YGy7@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160219125959.GA8675@yury-N73SV> References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <208897488.c0hkBy2G1S@wuerfel> <20160219125959.GA8675@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:oEvkbjr+mS2r3AU3Z/LVLGn4/I8gRMDQiX0ILVVvqahYpg9CDZD 1okaG9Rnh+qdCS39dQBi7fDDY9A/aQyO5+3VuucRCo+AROz0yV5f8iN0R1lV+zKHf10Z6Mb eC+uT1LTLMQXE1ONMKqaxB2WoI4vGFThI+Xgf6pqWHRJom8P+ILV9Ef7QW632VkVvE9Cqmd hhVhKqhFJkgl+dvlKqsgQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ULqyW8mowzM=:I4w0DGx027tC+YrbARWTbw LUkA5zjNgu0WXdhZb+Ry867WEO3KslF0UbBPCNAht1CE7TZwy0TBZJ5BommOVIyBhDqkQtmPY XZUUp/LVFgWgHT+bNIaOvDkutXkOeu4fKgf0VYBQGUa5VuqZVrRUX0q6E7EQH2yqoUf5RdEwJ uinFLfif0Jc1FaXWSJ0lVqCm47xchcg7cQZ79wYYtaVcckdlFdyYWdiYbVbNrxR5QD9YptCZd gmy+fF7ypwdab29a/96ZvgJ50PU5xc8RkPAMLdvn6+nyeSnHa7RQJ0z1zHnOY2vLksd9HBUU9 2DIQF34+RREs04ocHQrv2wWAYNV8AMR8jlQ1CmubyW1NBZyyBRu1OHTjiqple+T4jKr2u+TOB wSEtg9YD4bKFU9FSoL3ce3z3jXBPzkXkuaD75oM21GE54Od6CTTOYVvOtottIB5U+kD9M5EQR KcK2f4svUUOSqesTjWMF5qDUu+ASHEN7EyflLnFOHzkERuGH0RBSsV116w7WIqr6hhnLGAaWc GZ7wiSVeL1HvCcTPPwOu9YBe18Y4yKlDq0YLOMwXNNKPiPv6/kBv3i71ztNh3jHyonqk4aEvn dhNXh25p8904J+lfU/QJHS7bAo7lp5TUXK5cPod2+RyJ7ixfyuZayk6j1lt5myYDlx6C4n+4L 74Z/f1TXi+thmP0Y7aoi5xW4k2FkH1pnC7iS5HVPvMjKtttD77FlAM1+RPzayMSJGLa47SVNm MyYTu2mHhfnFsajW Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 19 February 2016 15:59:59 Yury Norov wrote: > On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > 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 > > > > Almost all ports define its own struct kernel_stat / kernel_stat64. > in "kernel_header.h" See mips, spark, alpha, i386... Some also define > function xstat_conv or similar. With all that defined, it's expected > that one of generic xstat wrappers will work properly. I tried all, > and noone got working, so I wrote this hack to make it work somehow. I see. I grepped for __kernel_stat64 and couldn't find any other with that name, as the others tend to us slightly different names. I would still think there is something wrong if you need to define your own copy of xstat_conv when the kernel 'struct stat64' is meant to be usable by user space. Shouldn't this work like any other 32-bit architecture now? Arnd