5 ms·

The lack of clear vision in Linux system call design is a source of continual frustration. I feel like any time I or anyone else proposes generic ways to solve

The lack of clear vision in Linux system call design is a source of continual frustration. I feel like any time I or anyone else proposes generic ways to solve certain longstanding problems, the response is a hostile sort of "no" based on, ostensibly, lack of demonstrated use cases for genericity, but in actuality, I think, simple change aversion. The result is an accumulation of a pile of ad-hoc kludges and crud that do one thing or not the other (e.g., the batch-but-not-async and async-but-not-batch distinction the article mentions). There needs to be more openness to providing general interfaces that solve whole classes of interface problems all at once, and without the technical conservatism that confronts people trying to contribute new interfaces.

cyphar 8y ago
I think this is based on a fear of having an API that wasn't needed and needs to be maintained forever. I bet that Linux's syscall design would be much nicer if iterating on APIs was possible (as we see in other Unix-likes). My personally least favourite syscall design misstep is how VFS flags work. AT_ flags were supposed to be generic but we now have AT_STATX_, O_ flags are overused, and some at(2) syscalls like renameat2(2) have their own brand of flags (RENAME_). Internally VFS has uniform flags for lookup and other various things, so it's a bit silly that these flags are all basically incompatible. (Also, the fact that O_RDWR != O_RDONLY|O_WRONLY is just silly. It takes up just as many bytes but makes life needlessly difficult when designing new extensions to openat(2).)
- quotemstr 8y ago
  If I had my way, the application stable ABI would be libc, not SYSENTER. Windows gets this right and is able to iterate faster on kernel interfaces as a result. A while ago, I proposed a kernel supplied libc add-on that would provide the syscall wrappers that glibc won't. Maybe we could declare that all applications must make new system calls through this interface and maintain syscall compatibility only for the current legacy set of system calls.
  - jcranmer 8y ago
    That is how it works on OS X and the BSDs as well--compatibility is maintained at the C level, not the SYSENTER level. (Although it should be noted that some of the BSDs don't guarantee forever-compatible syscall ABI in the first place).
  - asveikau 8y ago
    I don't understand how Windows "gets this right" other than by accident. In the Win32 heyday it was in their interest to have you code against kernel32, advapi, etc. so that your stuff works on 9x and NT, maybe CE. Now 9x/CE are gone and ntdll often has the "good" interfaces and the public wrapper APIs kind of lag behind. (Maybe ntdll itself having stubs and not telling the program to SYSENTER directly is the "good" design?) Meanwhile in the Linux world you have plenty of iteration on syscalls, you might say there is too much. They have to maintain cruft but OK. libc as the boundary doesn't make sense either as glibc is not the Linux kernel, by design, and there are other libcs in common production, like in a billion Android phones.
    - int_19h 8y ago
      It's not just Windows that gets it right. The situation is the same on macOS, and on all the BSDs. The notion of userspace doing syscalls directly is really pretty much unique to Linux at this point. And no, you still can't use NTDLL on Windows - not unless you're doing (OS-specific) drivers. It might work in practice, but it also breaks sometimes, because there's no API stability guarantee.
      - asveikau 8y ago
        In those projects the libc is part of the tree. In Linux it is not the case. This is logically consistent for the project at hand. You can advocate a different way and I can agree but it wouldn't be Linux. (I am no stranger to BSD either. Been using *BSDs in some form for 19 years.) By the way Windows CRT ships new versions with Visual Studio out of devdiv... So Windows doesn't even work that way if you draw the boundary at libc. This is part of my comment, I don't understand which part of it is MS doing it right? Ntdll abstracting sysenter? Kernel and advapi abstracting ntdll? I don't think the latter example is one of great technical execution, it just sort of happened to promote compatibility with 9x and they're stuck with it.
blattimwind 8y ago
> The lack of clear vision in Linux system call design is a source of continual frustration. sync_file_range and then sync_file_range2, because sync_file_range's API is literally impossible on most architectures that aren't x86.
- asveikau 8y ago
  Interesting case. However, "literally impossible" and "wastes a register padding parameters" are not the same thing.
  - blattimwind 8y ago
    Misremembered that, sorry.

cyphar 8y ago

I think this is based on a fear of having an API that wasn't needed and needs to be maintained forever. I bet that Linux's syscall design would be much nicer if iterating on APIs was possible (as we see in other Unix-likes). My personally least favourite syscall design misstep is how VFS flags work. AT_ flags were supposed to be generic but we now have AT_STATX_, O_ flags are overused, and some at(2) syscalls like renameat2(2) have their own brand of flags (RENAME_). Internally VFS has uniform flags for lookup and other various things, so it's a bit silly that these flags are all basically incompatible. (Also, the fact that O_RDWR != O_RDONLY|O_WRONLY is just silly. It takes up just as many bytes but makes life needlessly difficult when designing new extensions to openat(2).)

quotemstr 8y ago
If I had my way, the application stable ABI would be libc, not SYSENTER. Windows gets this right and is able to iterate faster on kernel interfaces as a result. A while ago, I proposed a kernel supplied libc add-on that would provide the syscall wrappers that glibc won't. Maybe we could declare that all applications must make new system calls through this interface and maintain syscall compatibility only for the current legacy set of system calls.
- jcranmer 8y ago
  That is how it works on OS X and the BSDs as well--compatibility is maintained at the C level, not the SYSENTER level. (Although it should be noted that some of the BSDs don't guarantee forever-compatible syscall ABI in the first place).
- asveikau 8y ago
  I don't understand how Windows "gets this right" other than by accident. In the Win32 heyday it was in their interest to have you code against kernel32, advapi, etc. so that your stuff works on 9x and NT, maybe CE. Now 9x/CE are gone and ntdll often has the "good" interfaces and the public wrapper APIs kind of lag behind. (Maybe ntdll itself having stubs and not telling the program to SYSENTER directly is the "good" design?) Meanwhile in the Linux world you have plenty of iteration on syscalls, you might say there is too much. They have to maintain cruft but OK. libc as the boundary doesn't make sense either as glibc is not the Linux kernel, by design, and there are other libcs in common production, like in a billion Android phones.
  - int_19h 8y ago
    It's not just Windows that gets it right. The situation is the same on macOS, and on all the BSDs. The notion of userspace doing syscalls directly is really pretty much unique to Linux at this point. And no, you still can't use NTDLL on Windows - not unless you're doing (OS-specific) drivers. It might work in practice, but it also breaks sometimes, because there's no API stability guarantee.
    - asveikau 8y ago
      In those projects the libc is part of the tree. In Linux it is not the case. This is logically consistent for the project at hand. You can advocate a different way and I can agree but it wouldn't be Linux. (I am no stranger to BSD either. Been using *BSDs in some form for 19 years.) By the way Windows CRT ships new versions with Visual Studio out of devdiv... So Windows doesn't even work that way if you draw the boundary at libc. This is part of my comment, I don't understand which part of it is MS doing it right? Ntdll abstracting sysenter? Kernel and advapi abstracting ntdll? I don't think the latter example is one of great technical execution, it just sort of happened to promote compatibility with 9x and they're stuck with it.

blattimwind 8y ago

> The lack of clear vision in Linux system call design is a source of continual frustration. sync_file_range and then sync_file_range2, because sync_file_range's API is literally impossible on most architectures that aren't x86.

asveikau 8y ago
Interesting case. However, "literally impossible" and "wastes a register padding parameters" are not the same thing.
- blattimwind 8y ago
  Misremembered that, sorry.