3 ms·
User space has a lot more flexibility than the kernel when it comes to implementing ABIs. For example, Linux has to maintain a relatively large table of system
by quotemstr 7y ago
User space has a lot more flexibility than the kernel when it comes to implementing ABIs. For example, Linux has to maintain a relatively large table of system calls for legacy reasons. (Consider socketcall(2)). Legacy "system calls" provided by a VDSO or ntdll.dll-like mechanism are just tiny regular functions with no special security or performance implications.
- wtallis 7y ago>Legacy "system calls" provided by a VDSO or ntdll.dll-like mechanism are just tiny regular functions with no special security or performance implications. Are you saying that wrapper code implementing an old interface by wrapping around a new interface is easier to do correctly in userspace than in the kernel itself? I think I need you to be more concrete in pointing to a specific performance penalty or avoidable maintenance burden.
- quotemstr 7y ago> Are you saying that wrapper code implementing an old interface by wrapping around a new interface is easier to do correctly in userspace than in the kernel itself? Yes. > I think I need you to be more concrete in pointing to a specific performance penalty or avoidable maintenance burden. I already did: socketcall. And NT does all 32-bit compatibility in userspace.
- wtallis 7y ago> I already did: socketcall Got anything that applies to modern platforms or recent kernel versions? Also, does socketcall actually have higher overhead than doing a similar dispatch in userspace, or does it just mean you get a cache miss slightly later in the process? (You could try elucidating an actual argument rather than just naming a syscall and assuming that the rest of your argument is obvious.) > And NT does all 32-bit compatibility in userspace. So? Is it faster to do that in userspace than in the kernel?