[GIT PULL] Disintegrate UAPI for arm64 [ver #2]
catalin.marinas at arm.com
Tue Oct 9 17:22:54 EDT 2012
On Tue, Oct 09, 2012 at 08:30:59PM +0100, David Howells wrote:
> Catalin Marinas <catalin.marinas at 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:
> 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?
Yes, that's what I tried. But since unistd.h gets included indirectly as
well, I have to change the __NR_* definitions in unistd32.h to avoid
conflicts (once done, it's fine again).
> Is there a reason that asm/unistd32.h needs to declare __NR_ macros? Looking
> at signal32.c and sys_compat.c you only need:
> 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
I would name them __NR_compat_ rather than __ARM_NR_ as the latter
usually means architecture-specific system call.
> > 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).
I'll push a patch tomorrow so you can run your script on that branch. I
can also fix things up after merging your current branch (it breaks
bisectability but it doesn't matter much for arm64, it's only a few
> > 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.
OK, it makes sense.
More information about the linux-arm-kernel