Message-ID: <20121009212254.GB18315@arm.com>
Date:	Tue, 9 Oct 2012 22:22:54 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	David Howells <dhowells@...hat.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [GIT PULL] Disintegrate UAPI for arm64 [ver #2]

On Tue, Oct 09, 2012 at 08:30:59PM +0100, David Howells wrote:
> Catalin Marinas <catalin.marinas@....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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists