Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
H. Peter Anvin wrote:
No.
I already said I'm not looking at changing the calling convention for
existing syscalls.
I did not suggest or ask for that at all.
I was asking you to consider the real implementation details for a new
syscall mechanism.
We do not want to abandon the use of syscall/sysenter and go back to int
(on x86/x86-64). This means that you have to come up with a mechanism
which hooks into the current syscall/sysenter path while preserving full
backward compatibility.
Now it's your turn. How do you do this without additional costs?
- Add sys_new_call to the syscall table
- Create a stub thunk:
asmlinkage long sys_old_call(long parm1, long parm2, long parm3)
{
return sys_new_call(parm1, parm2, parm3, 0);
}
We have 2^n examples on this in the kernel already.
Or, if the new syscall requires more than 6 parameters (with the current
convention):
asmlinkage long sys_new_call6(long parm1, long parm2, long parm3,
long parm4, long parm5,
long __user *additional)
{
long xparm[3]; /* 8 parameters, total */
if (copy_from_user(xparm, additional, sizeof xparm)
!= sizeof xparm)
return -EFAULT;
return sys_new_call(parm1, parm2, parm3, parm4, parm5,
xparm[0], xparm[1], xparm[2]);
}
This is a fixed-size copy from userspace, which obviously cannot be avoided.
The C version isn't optimal, obviously, hence my mentioning the
possibility of doing it in the arch layer.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
