public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, arnd@arndb.de
Subject: Re: compat syscall args
Date: Tue, 01 Jun 2004 15:07:57 +0200	[thread overview]
Message-ID: <m38yf7juj6.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <22dL7-3O8-39@gated-at.bofh.it> (David S. Miller's message of "Tue, 01 Jun 2004 11:30:21 +0200")

"David S. Miller" <davem@redhat.com> writes:

> Personally I think it makes more sense to do what sparc64 does
> which is:
>
> 1) The syscall32 entry code extends each arg in a fixed way.
>    Ie. arg0-3 are zero-extended, arg4-5 are sign-extended
>    or whatever.  I posted the choices we use on sparc64 just
>    the other day.

I don't see where you find that many arguments that need
sign extension? iirc they are quite rare.


> 2) For each syscall where this default set of extensions is
>    not correct, little assembler or C stubs are used to correct
>    the extensions made by the default code.
>
> It is the most optimal solution.  We only need 13 or so stubs
> on sparc64 with the defaults we've choosen.

It would be better to do this consistently over all architectures
and do the sign extension (which is much less common than zero
extension) always in C code. Then when someone adds a new compat
handler the chances are high that it will just work over multiple
architectures (ok minus s390) without much more changes. 

Actually if someone demonstrated that doing sign extension in assembly
helps a lot then I would not be opposed to doing it on x86-64 
too just for consistency.

I would be actually not against doing the s390 compat_uptr() changes
in C too, although it wouldn't help them with the "one handler
for everybody" goal, since it can be only tested on s390.

-Andi


       reply	other threads:[~2004-06-01 13:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <21hGW-h5-5@gated-at.bofh.it>
     [not found] ` <229Hi-B1-11@gated-at.bofh.it>
     [not found]   ` <22drH-3Bc-47@gated-at.bofh.it>
     [not found]     ` <22dL7-3O8-39@gated-at.bofh.it>
2004-06-01 13:07       ` Andi Kleen [this message]
2004-06-01 17:04         ` compat syscall args Anton Blanchard
2004-06-01 21:28           ` David S. Miller
2004-05-29 19:23 David S. Miller
2004-05-29 19:31 ` David S. Miller
2004-06-01 13:03   ` Arnd Bergmann
2004-06-01  5:06 ` Stephen Rothwell
2004-06-01  9:07   ` Arnd Bergmann
2004-06-01  9:24     ` David S. Miller

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=m38yf7juj6.fsf@averell.firstfloor.org \
    --to=ak@muc.de \
    --cc=arnd@arndb.de \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.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