mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: sfr@canb.auug.org.au
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, torvalds@osdl.org,
	ak@suse.de
Subject: Re: [PATCH] compat: add compat functions for *at syscalls
Date: Tue, 07 Feb 2006 00:43:01 -0800 (PST)	[thread overview]
Message-ID: <20060207.004301.35467668.davem@davemloft.net> (raw)
In-Reply-To: <20060207112713.7cd0a61c.sfr@canb.auug.org.au>

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 7 Feb 2006 11:27:13 +1100

> *If* we do get is_compat_task(), what would be you reaction to something
> like this:
...
> +	if (is_compat_task())
> +		dfd = compat_sign_extend(dfd);

A load and a test is more expensive than the assembler
stubs where we _know_ we are compat.

The alternative suggestions get less and less efficient :-) My whole
desire is to optimize this as much as possible, without the overhead
of an extra stack frame or "is_compat_task()" kinds of runtime tests.

Really, the way to do this is to have a description header file, that
does stuff like:

SIGN1(STUB_NAME, REAL_SYSCALL, ARG1_TO_EXTEND)
SIGN2(STUB_NAME, REAL_SYSCALL, ARG1_TO_EXTEND, ARG2_TO_EXTEND)

etc. etc. for each syscall that only needs sign extension compat
handling, and the platform provides definitions of these macros which
expand the above as appropriate.  Use arch/sparc64/kernel/sys32.S as a
guide.

So for sys_exit_group you'd list something like:

SIGN1(sys32_exit_group, sys_exit_group, ARG0)

"ARG0" would get defined to whatever register mnemonic the
first argument to a function gets passed into, ARG1 to the
second, etc.  So on Sparc64 that would be:

#define ARG0	%o0
#define ARG1	%o1
#define ARG2	%o2
#define ARG3	%o3
#define ARG4	%o4
#define ARG5	%o5

and you'd use "sys32_exit_group" in the compat syscall table.  The
SIGN1 definition on sparc64 would be exactly what it is right now
in that sys32.S file.

Such a header can be use to generate stubs on every platform.

  parent reply	other threads:[~2006-02-07  8:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-06 23:56 Stephen Rothwell
2006-02-07  0:01 ` David S. Miller
2006-02-07  0:27   ` Stephen Rothwell
2006-02-07  1:15     ` Linus Torvalds
2006-02-07  8:44       ` David S. Miller
2006-02-07  8:43     ` David S. Miller [this message]
2006-02-07  9:39       ` Andi Kleen
2006-02-07 10:56         ` David S. Miller
2006-02-07  6:40   ` Stephen Rothwell
2006-02-07  9:31     ` Heiko Carstens
2006-02-07 13:29       ` Heiko Carstens
2006-02-07 22:57         ` David S. Miller
2006-02-07  9:25   ` Andi Kleen

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=20060207.004301.35467668.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome