Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1725014 > unrolled thread

RE: [PATCH] Unifying headers for AArch64 and ARM

Back to article view | Back to linux.kernel

Contents

  RE: [PATCH] Unifying headers for AArch64 and ARM Kaushik Phatak <Kaushik.Phatak@kpit.com> - 2017-09-01 14:30 +0200
    Re: [PATCH] Unifying headers for AArch64 and ARM Arnd Bergmann <arnd@arndb.de> - 2017-09-05 17:00 +0200

#1725014 — RE: [PATCH] Unifying headers for AArch64 and ARM

Ping for this patch:
https://lkml.org/lkml/2017/8/10/136

The patch can be viewed on the mail-archive link below,
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1465874.html

Please let me know if anyone has any feedback on this.
Thanks.

Best Regards,
Kaushik M. Phatak

-----Original Message-----
From: Kaushik Phatak
Sent: Thursday, August 10, 2017 2:12 PM
To: 'linux-kernel@vger.kernel.org' <linux-kernel@vger.kernel.org>
Subject: [PATCH] Unifying headers for AArch64 and ARM

Hi,
This patch is an attempt to unify the kernel header files for AArch64 and ARM. We have developed similar patch for glibc, which unifies the headers in sysdeps. We plan to post that separately to libc-alpha.

This developed patch is similar to something that X86 does with the macros (__x86_64__) and (__ILP32__).

We have noticed some activity in this area in recent times, Linux patches by Yury Norov:
[07/20] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 https://patchwork.kernel.org/patch/9599053/

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.

[toc] | [next] | [standalone]

#1726798

On Mon, Sep 4, 2017 at 2:23 PM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> Hi Kaushik,
>
> (CC arm and arch maintainers)
>
> On Fri, Sep 01, 2017 at 12:24:08PM +0000, Kaushik Phatak wrote:
>> Ping for this patch:
>> https://lkml.org/lkml/2017/8/10/136
>>
>> The patch can be viewed on the mail-archive link below,
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1465874.html
>>
>> Please let me know if anyone has any feedback on this.
>> Thanks.
>>
>
>> We have noticed some activity in this area in recent times, Linux patches by Yury Norov:
>> [07/20] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>> https://patchwork.kernel.org/patch/9599053/
>
> arm64/ilp32 and arm64/lp64 is the single platform, and so lp64 and
> ilp32 parts share the same installed kernel headers. That's why I had to
> introduce #ifdef magic here and in other kernel and glibc headers.
>
> Arm32 is different platform, so I don't understand what the benefit
> in joining headers. Could you explain it in details.

I think in the proposed form, the patch makes no sense. The internal
headers do not benefit from being combined at all, as you'd never
include them from user space, and the kernel only ever uses one of them.

For the uabi headers, it can be beneficial to install both versions
simultaneously, but this is generally up to the distro. On Debian
and Ubuntu, the architecture specific uapi headers get installed
into /usr/arm-linux-gnueabi/include/asm/ and /usr/aarch64-linux-gnu/include/asm/
respectively, and the compiler looks for them in the right place.

We used to have some magic in scripts/headers_install.sh that
could generate something like

#ifdef __x86_64__
#include <asm-x86_64/signal.h>
#else
#include <asm-i386/signal.h>
#endif

but that should no longer be needed these days when the toolchain
is installed properly. It may be a problem on some distros that don't
normally ship with a compiler on the target, e.g. openembedded or
LEDE, but I think we are better off fixing it in the distros.

         Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web