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.
next prev 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