From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Tue, 9 Oct 2012 22:22:54 +0100 Subject: [GIT PULL] Disintegrate UAPI for arm64 [ver #2] In-Reply-To: <6973.1349811059@warthog.procyon.org.uk> References: <20121009172559.GB13922@arm.com> <21110.1349774113@warthog.procyon.org.uk> <6973.1349811059@warthog.procyon.org.uk> Message-ID: <20121009212254.GB18315@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Oct 09, 2012 at 08:30:59PM +0100, David Howells wrote: > Catalin Marinas 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756911Ab2JIVW7 (ORCPT ); Tue, 9 Oct 2012 17:22:59 -0400 Received: from service87.mimecast.com ([91.220.42.44]:54098 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754880Ab2JIVW5 convert rfc822-to-8bit (ORCPT ); Tue, 9 Oct 2012 17:22:57 -0400 Date: Tue, 9 Oct 2012 22:22:54 +0100 From: Catalin Marinas To: David Howells Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann Subject: Re: [GIT PULL] Disintegrate UAPI for arm64 [ver #2] Message-ID: <20121009212254.GB18315@arm.com> References: <20121009172559.GB13922@arm.com> <21110.1349774113@warthog.procyon.org.uk> <6973.1349811059@warthog.procyon.org.uk> MIME-Version: 1.0 In-Reply-To: <6973.1349811059@warthog.procyon.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 09 Oct 2012 21:22:55.0583 (UTC) FILETIME=[3F7ED6F0:01CDA664] X-MC-Unique: 112100922225600201 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 09, 2012 at 08:30:59PM +0100, David Howells wrote: > Catalin Marinas 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