All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Jeff Moyer <jmoyer@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <johnstul@us.ibm.com>
Subject: Re: [PATCH v2] compat: fixes to allow working with tile arch
Date: Wed, 11 May 2011 23:08:15 +0200	[thread overview]
Message-ID: <201105112308.15779.arnd@arndb.de> (raw)
In-Reply-To: <201105091925.p49JPPvf002716@farm-0023.internal.tilera.com>

On Monday 09 May 2011, Chris Metcalf wrote:
> The existing <asm-generic/unistd.h> mechanism doesn't really provide
> enough to create the 64-bit "compat" ABI properly in a generic way,
> since the compat ABI is a mix of things were you can re-use the 64-bit
> versions of syscalls and things where you need a compat wrapper.
> 
> To provide this in the most direct way possible, I added two new macros
> to go along with the existing __SYSCALL and __SC_3264 macros: __SC_COMP
> and SC_COMP_3264.  These macros take an additional argument, typically a
> "compat_sys_xxx" function, which is passed to __SYSCALL if you define
> __SYSCALL_COMPAT when including the header, resulting in a pointer to
> the compat function being placed in the generated syscall table.
> 
> The change also adds some missing definitions to <linux/compat.h> so that
> it actually has declarations for all the compat syscalls, since the
> "[nr] = ##call" approach requires proper C declarations for all the
> functions included in the syscall table.
> 
> Finally, compat.c defines compat_sys_sigpending() and
> compat_sys_sigprocmask() even if the underlying architecture doesn't
> request it, which tries to pull in undefined compat_old_sigset_t defines.
> We need to guard those compat syscall definitions with appropriate
> __ARCH_WANT_SYS_xxx ifdefs.
> 
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> ---
> Arnd - let me know if this matches what you had in mind.  Thanks!

Looks good to me, yes. It's not exactly what I would have done, but
it absolutely makes sense and I can't see any specific disadvantage
over the other slightly different approaches.

Acked-by: Arnd Bergmann <arnd@arndb.de>

      reply	other threads:[~2011-05-11 21:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04 15:16 [PATCH] compat: fixes to allow working with tile arch Chris Metcalf
2011-05-05  7:01 ` Arnd Bergmann
2011-05-09 17:12   ` [PATCH v2] " Chris Metcalf
2011-05-11 21:08     ` Arnd Bergmann [this message]

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=201105112308.15779.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=cmetcalf@tilera.com \
    --cc=davem@davemloft.net \
    --cc=jmoyer@redhat.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.