4 ms·

How exactly does a ntdll/vdso approach make it easier to preserve binary compatibility? It obviously moves the place at which binary compatibility needs to be p

How exactly does a ntdll/vdso approach make it easier to preserve binary compatibility? It obviously moves the place at which binary compatibility needs to be preserved, but I'm not seeing how that move makes maintenance easier, unless you're implying that the userspace portion would not be the responsibility of the kernel developers.

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?
      - saagarjha 7y ago
        Doing things in userspace prevents a context switch, presumably.
        wtallis 7y ago
        Not when it's just prep work before doing an unavoidable syscall.

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?
    - saagarjha 7y ago
      Doing things in userspace prevents a context switch, presumably.
      - wtallis 7y ago
        Not when it's just prep work before doing an unavoidable syscall.