On Tue, Oct 09, 2012 at 08:30:59PM +0100, David Howells wrote: > Catalin Marinas <catalin.mari...@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?
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: > > __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? 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 patches). > > 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. Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/