|From:||"H. Peter Anvin" <hpa-AT-zytor.com>|
|To:||Ulrich Drepper <drepper-AT-redhat.com>|
|Subject:||Re: [PATCHv3 0/4] sys_indirect system call|
|Date:||Mon, 19 Nov 2007 20:27:13 -0800|
|Cc:||linux-kernel-AT-vger.kernel.org, akpm-AT-linux-foundation.org, mingo-AT-elte.hu, tglx-AT-linutronix.de, torvalds-AT-linux-foundation.org|
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
Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds