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.
>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.
> 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.
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?