4 ms·

Is an OS-specific `syscall` at all useful if your OS isn't called "Linux"?

steveklabnik 6y ago
Depends on the OS. We also do include some specific things, see https://doc.rust-lang.org/stable/std/os/index.html https://doc.rust-lang.org/stable/std/os/index.html and https://doc.rust-lang.org/stable/core/arch/index.html https://doc.rust-lang.org/stable/core/arch/index.html
- ChrisSD 6y ago
  Sure platform specific things can be useful. But that's exactly what `syscall()` is. As far as I'm aware, other platforms don't have any real equivalent. On other platforms syscalls must be made via libraries (as Go rather famously found out the hard way).
  - steveklabnik 6y ago
    Yes, you're right that most platforms don't have something stable here. I was thinking of the problem more abstractly.
    - yxhuvud 6y ago
      Doesn't most platforms have a reasonably stable interface for functions that are supposed to be reached from userspace? When does it actually matter if that border coincide with where execution privileges are raised?
      - steveklabnik 6y ago
        They do: the interface is (usually) libc (or some equivalent), not the actual details of how libc makes said call. For an example of how this can play out, the parent is referring to things like https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
lionkor 6y ago
well i feel like one should focus on the more stable POSIX stuff and then also implement a wrapper for windows. That will work for most OS's out there, and windows
- steveklabnik 6y ago
  It's Linux specific, not POSIX-specific.
moonchild 6y ago
On windows, it can talk to ntdll (which is the blessed interface to the kernel from userspace code). Ditto libsystem on macos. Freebsd also provides a stable syscall interface, like linux.
- ChrisSD 6y ago
  `syscall()` is a very thin wrapper around calling the kernel directly by number. ntdll and libsystem aren't equivalent, they are more similar to `libc`. Neither Windows nor MacOS have a stable system call interface so you have to dynamically link to the library and call through the stable library interface instead. I can't find anything that guarantees FreeBSD's system call ABI. Do you have a source? It would be very interesting if, for example, FreeBSD 10 applications that use syscalls can run on modern FreeBSD without a compatibility layer. However, if the FreeBSD project does not provide guarantees it would be folly to rely on this behaviour in the future. If it does provide such a guarantee then I stand corrected. EDIT: After some more research it seems the FreeBSD kernel needs the `COMPAT_FREEBSD10` option enabled for my hypothetical example to work. The default options for amd64 include compatibility options back to FreeBSD 4. Defaults for other platforms seems to differ (perhaps depending on when the platform was first supported). I can't find good documentation on if these provide full compatibility or if any `COMPAT_` options could be dropped in future versions.
  - moonchild 6y ago
    > ntdll and libsystem aren't equivalent, they are more similar to `libc` I disagree. System calls on linux comprise the interface provided to applications to talk to the kernel. On windows, ntdll serves the same function--it is itself a 'very thin wrapper around calling the kernel directly by number'. (Especially important since a libc may be hard to come by on windows.) (Libsystem it seems I was mistaken about; it looks like that's just a bundle of libc, libm, libpthread, etc. Though possibly libsystem_kernel is nearer the mark? Difficult to find information on the subject, and I don't have a mac.)

Depends on the OS. We also do include some specific things, see https://doc.rust-lang.org/stable/std/os/index.html https://doc.rust-lang.org/stable/std/os/index.html and https://doc.rust-lang.org/stable/core/arch/index.html https://doc.rust-lang.org/stable/core/arch/index.html

ChrisSD 6y ago
Sure platform specific things can be useful. But that's exactly what `syscall()` is. As far as I'm aware, other platforms don't have any real equivalent. On other platforms syscalls must be made via libraries (as Go rather famously found out the hard way).
- steveklabnik 6y ago
  Yes, you're right that most platforms don't have something stable here. I was thinking of the problem more abstractly.
  - yxhuvud 6y ago
    Doesn't most platforms have a reasonably stable interface for functions that are supposed to be reached from userspace? When does it actually matter if that border coincide with where execution privileges are raised?
    - steveklabnik 6y ago
      They do: the interface is (usually) libc (or some equivalent), not the actual details of how libc makes said call. For an example of how this can play out, the parent is referring to things like https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

lionkor 6y ago

well i feel like one should focus on the more stable POSIX stuff and then also implement a wrapper for windows. That will work for most OS's out there, and windows

steveklabnik 6y ago
It's Linux specific, not POSIX-specific.

moonchild 6y ago

On windows, it can talk to ntdll (which is the blessed interface to the kernel from userspace code). Ditto libsystem on macos. Freebsd also provides a stable syscall interface, like linux.

ChrisSD 6y ago
`syscall()` is a very thin wrapper around calling the kernel directly by number. ntdll and libsystem aren't equivalent, they are more similar to `libc`. Neither Windows nor MacOS have a stable system call interface so you have to dynamically link to the library and call through the stable library interface instead. I can't find anything that guarantees FreeBSD's system call ABI. Do you have a source? It would be very interesting if, for example, FreeBSD 10 applications that use syscalls can run on modern FreeBSD without a compatibility layer. However, if the FreeBSD project does not provide guarantees it would be folly to rely on this behaviour in the future. If it does provide such a guarantee then I stand corrected. EDIT: After some more research it seems the FreeBSD kernel needs the `COMPAT_FREEBSD10` option enabled for my hypothetical example to work. The default options for amd64 include compatibility options back to FreeBSD 4. Defaults for other platforms seems to differ (perhaps depending on when the platform was first supported). I can't find good documentation on if these provide full compatibility or if any `COMPAT_` options could be dropped in future versions.
- moonchild 6y ago
  > ntdll and libsystem aren't equivalent, they are more similar to `libc` I disagree. System calls on linux comprise the interface provided to applications to talk to the kernel. On windows, ntdll serves the same function--it is itself a 'very thin wrapper around calling the kernel directly by number'. (Especially important since a libc may be hard to come by on windows.) (Libsystem it seems I was mistaken about; it looks like that's just a bundle of libc, libm, libpthread, etc. Though possibly libsystem_kernel is nearer the mark? Difficult to find information on the subject, and I don't have a mac.)