Ulrich Drepper wrote:
But I still don't see that the magic encoding is a valid solution, it
doesn't address the limited parameter number. Plus, using sys_indirect
could in future be used to transport entire parameters (like a sigset_t)
along with other information, thereby saving individual copy operations.
The limited number of parameters is a non-issue, we already have the
convention for that: for more than 6 parameters, pass a parameter to
arguments 6 and higher in the register normally used for parameter 6.
Now, for the specific case of x86-64 (as well as some of the RISC
architectures), this meshes poorly with the C calling convention, which
is that parameter 7+ are passed on the stack. We would obtain a more
efficient calling convention by allocating an additional register for
such an indirect pointer and/or adopt the convention that the additional
parameters are simply stored on the user stack starting at a specific
offset, presumably +8.
I would really like to see a systematic calling convention that doesn't
have limits that we have already broken several times. In particular, I
would like to see a convention that can be mapped 1:1 onto the platform
C calling convention in a syscall-independent way. We *almost* have
this today, but sys_indirect would blow that out of the water in a
particularly ugly way.(*)
I think the sys_indirect approach is the way forward. I'll submit a
last version of the patch in a bit.
I think it is a horrible kluge. It's yet another multiplexer, which we
are trying desperately to avoid in the kernel. Just to make things more
painful, it is a multiplexer which creates yet another ad hoc calling
convention, whereas we should strive to make the kernel calling
convention as uniform as possible.
If is is NOT going to be used in the common case, then it really doesn't
matter -- we can just use manually or automatically generated thunks.
It's not like we have thousands of system calls, and it's not like "a
system call" is a precious thing.
If it IS going to be used in the common case, then we should use
something more streamlined.
-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]
