Re: [PATCH] Unifying headers for AArch64 and ARM

[Arnd Bergmann]

On Mon, Sep 4, 2017 at 2:23 PM, Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx/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