"David S. Miller" <[email protected]> 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
> 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.
On ppc64 we now zero extend all arguments. I too would like to see the
sign extension done in the common compat code, at the moment we have to
be careful to do it before calling compat code.
Anton
On Wed, 2 Jun 2004 03:04:18 +1000
Anton Blanchard <[email protected]> wrote:
> > 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.
>
> On ppc64 we now zero extend all arguments. I too would like to see the
> sign extension done in the common compat code, at the moment we have to
> be careful to do it before calling compat code.
Ok, I'm doing some auditing of the sparc64 compat syscall table
and all the args to the syscalls. I'll take this thread further
after I'm done with that.
Sit tight.