Message ID | 21110.1349774113@warthog.procyon.org.uk |
---|---|
State | New |
Headers | show |
On Tue, Oct 09, 2012 at 10:15:13AM +0100, David Howells wrote: > David Howells (1): > UAPI: (Scripted) Disintegrate arch/arm64/include/asm 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: > diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h > index 8f03dee..3d43b19 100644 > --- a/arch/arm64/include/asm/unistd.h > +++ b/arch/arm64/include/asm/unistd.h > @@ -13,13 +13,7 @@ > * You should have received a copy of the GNU General Public License > * along with this program. If not, see <http://www.gnu.org/licenses/>. > */ > - > -#ifndef __SYSCALL_COMPAT > -#include <asm-generic/unistd.h> > -#endif > - > -#ifdef __KERNEL__ > #ifdef CONFIG_COMPAT > #include <asm/unistd32.h> > #endif > -#endif > +#include <uapi/asm/unistd.h> the guard disappears and I get conflicting entries between unistd32.h and unistd.h. 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). But you need to re-generate the arm64 headers again. 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?
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
On Tue, Oct 09, 2012 at 08:30:59PM +0100, David Howells wrote: > 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? 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.