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).
> 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
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.
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.
