3 ms·

It's relevant because if your program is statically linked then it doesn't matter whether or not future changes at the kernel boundary are made backwards-compat

by caf 7y ago

It's relevant because if your program is statically linked then it doesn't matter whether or not future changes at the kernel boundary are made backwards-compatible by compensating changes in libc (as is possible if you release them together), because your statically-linked binary can't pick up those libc changes.

masklinn 7y ago
So it's relevant because it avoids breaking your stupidity? The entire objection is that it's a self-inflicted wound, if you don't statically link everything it's not an issue. And non-linux systems will just forbid statically linking libc (e.g. can't statically link libc / libSystem on OSX).
- caf 7y ago
  What? That makes no sense. The question here was why static linking is relevant to the point about whether or not having libc release together with the kernel means you could move the compatibility line to the libc interface, and I was answering that question. Forbidding static linking libc is fine if you do that from the beginning. Linux didn't, so - whether or not you approve - there's statically linked binaries out there that must be supported. It's not about calling users stupid, or a discussion about what users should or shouldn't do - it's a discussion about what the kernel can do, today, given the backwards compatibility constraint and the reality on the ground. (Personally I am completely in favour of dynamic linking, but that's not the point).
  - masklinn 7y ago
    > What? That makes no sense. The question here was why static linking is relevant No it is not. 1. ninkendo asked how syscalls worked 2. detaro replies that NT software uses ntdll and never do raw syscalls 3. alxlaz non-sequiturs that "the kernel community is big on interface stability and compatibility" 4. quotemstr points out that backwards compatibility does not in any way, shape or form require a stable kernel ABI, that's just a weird linuxism (because it ships as a kernel alone rather than a system) 5. you apparently decide to bring the entire thing on an irrelevant tangent completely missing the point
    - caf 7y ago
      I wasn't responding to ninkendo, detaro or alxlaz. I was responding precisely to quotemstr's: The real reason Linux's ABI boundary is the kernel is just that the kernel and glibc are sperate [projects] ...by pointing out the very real issue that even if they were the same project today, they'd still have to maintain compatibility at the system call layer, because that ship has sailed.
      - quotemstr 7y ago
        To be more precise, then, the Linux kernel is the ABI boundary because during Linux's fluid and formative period, the kernel and libc were separate projects. I agree that it's mostly epoxied in place now, modulo my lkml libsyscall proposal from a while ago.

by caf 7y ago

masklinn 7y ago

So it's relevant because it avoids breaking your stupidity? The entire objection is that it's a self-inflicted wound, if you don't statically link everything it's not an issue. And non-linux systems will just forbid statically linking libc (e.g. can't statically link libc / libSystem on OSX).

caf 7y ago
What? That makes no sense. The question here was why static linking is relevant to the point about whether or not having libc release together with the kernel means you could move the compatibility line to the libc interface, and I was answering that question. Forbidding static linking libc is fine if you do that from the beginning. Linux didn't, so - whether or not you approve - there's statically linked binaries out there that must be supported. It's not about calling users stupid, or a discussion about what users should or shouldn't do - it's a discussion about what the kernel can do, today, given the backwards compatibility constraint and the reality on the ground. (Personally I am completely in favour of dynamic linking, but that's not the point).
- masklinn 7y ago
  > What? That makes no sense. The question here was why static linking is relevant No it is not. 1. ninkendo asked how syscalls worked 2. detaro replies that NT software uses ntdll and never do raw syscalls 3. alxlaz non-sequiturs that "the kernel community is big on interface stability and compatibility" 4. quotemstr points out that backwards compatibility does not in any way, shape or form require a stable kernel ABI, that's just a weird linuxism (because it ships as a kernel alone rather than a system) 5. you apparently decide to bring the entire thing on an irrelevant tangent completely missing the point
  - caf 7y ago
    I wasn't responding to ninkendo, detaro or alxlaz. I was responding precisely to quotemstr's: The real reason Linux's ABI boundary is the kernel is just that the kernel and glibc are sperate [projects] ...by pointing out the very real issue that even if they were the same project today, they'd still have to maintain compatibility at the system call layer, because that ship has sailed.
    - quotemstr 7y ago
      To be more precise, then, the Linux kernel is the ABI boundary because during Linux's fluid and formative period, the kernel and libc were separate projects. I agree that it's mostly epoxied in place now, modulo my lkml libsyscall proposal from a while ago.