Hacker News new | past | comments | ask | show | jobs | submit login

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.


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


Doing things in userspace prevents a context switch, presumably.


Not when it's just prep work before doing an unavoidable syscall.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: