All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] Disintegrate UAPI for arm64 [ver #2]
Date: Tue, 9 Oct 2012 22:22:54 +0100	[thread overview]
Message-ID: <20121009212254.GB18315@arm.com> (raw)
In-Reply-To: <6973.1349811059@warthog.procyon.org.uk>

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.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: David Howells <dhowells@redhat.com>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [GIT PULL] Disintegrate UAPI for arm64 [ver #2]
Date: Tue, 9 Oct 2012 22:22:54 +0100	[thread overview]
Message-ID: <20121009212254.GB18315@arm.com> (raw)
In-Reply-To: <6973.1349811059@warthog.procyon.org.uk>

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.

-- 
Catalin


  reply	other threads:[~2012-10-09 21:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09  9:15 [GIT PULL] Disintegrate UAPI for arm64 [ver #2] David Howells
2012-10-09  9:15 ` David Howells
2012-10-09 17:25 ` Catalin Marinas
2012-10-09 17:25   ` Catalin Marinas
2012-10-09 19:30   ` David Howells
2012-10-09 19:30     ` David Howells
2012-10-09 21:22     ` Catalin Marinas [this message]
2012-10-09 21:22       ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121009212254.GB18315@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.