[GIT PULL] Disintegrate UAPI for arm64 [ver #2]

[dhowells@redhat.com (David Howells)]

Catalin Marinas <catalin.marinas@arm.com> wrote:

> It still fails on arm64. The reason is that I had a __SYSCALL_COMPAT
> guard to provide either the 32-bit syscalls or the 64-bit (generic) ones
> via asm/unistd.h. With this change:

Hmmm.

Why does asm/unistd.h get #included for the compat bits at all?  Looking in
arch/arm64/kernel/sys32.S could the compat syscall table be generated by a
direct #inclusion of asm/unistd32.h instead?

Is there a reason that asm/unistd32.h needs to declare __NR_ macros?  Looking
at signal32.c and sys_compat.c you only need:

	__ARM_NR_compat_cacheflush
	__ARM_NR_compat_set_tls

and:

	__NR_sigreturn
	__NR_rt_sigreturn
	__NR_restart_syscall

could you define __ARM_NR_ versions of the last three and get rid of all the
__NR_ constant definitions by putting the numbers directly into the __SYSCALL
macros?

> The solution is to either keep the __SYSCALL_COMPAT guard in place or
> rename all the __NR_* macros in unistd32.h to __NR_compat_* and include
> unistd32.h explicitly where needed (kernel-only header anyway). Since
> the arm64 kernel would not export 32-bit headers, I would go with the
> second solution (tried it already).

That sounds workable too...  Certainly easier to do with a text editor than
folding the compat __NR_ values into their __SYSCALL() macros.

Either way, you can then blithely always include unistd32.h without having to
wriggle to avoid the duplicate symbols.

> But you need to re-generate the arm64 headers again.

Regeneration is certainly quick and (usually) easy, but I need to change the
base to end up with a different result.  Do you want me to rename all the
__NR_* to __NR_compat_* before doing that (if you have a patch to do so, I can
incorporate that on the arm64 branch prior to doing the disintegration).

> BTW, I see the script generated some pretty much empty
> uapi/asm/unistd.h. Is it possible to using something like Kbuild and
> just add "generic-y += ..." to just point it to the
> include/uapi/asm-generic header?

Yes.  Note that I was asked not to lose copyright notices if they were
present, which is why you've ended up with that.

At this point, I'd rather not adjust the disintegration script, so fixing it
up after would be simplest.

David