3 ms·
A good example is go. On linux you can use a from scratch image fairly easily because it only uses syscalls. But for windows or mac the moving target wasn't mai
by galangalalgol 2mo ago
A good example is go. On linux you can use a from scratch image fairly easily because it only uses syscalls. But for windows or mac the moving target wasn't maintainable so they link against shared objects. Linus enforcing the don't break userspace rule is what made that possible. That definitely has tradeoffs. At some point relibc or something similar will allow the same (stably) for rust. But using posix as that compatibility boundary gets you a much larger set of OS and only occasionally has a performance penalty. Often, a posix api tuned to the kernel is more performant. Musl is an exception precisely because it makes an openbsd-esque trade of performance for simple small attack surface.
- inigyou 2mo agoThe Linux kernel defines syscalls as its stable ABI (note: there are also non-kernel ABIs on Linux, such as Wayland) while Windows defines the DLL calls as its stable ABI. One isn't better than the other. Linux's approach allows binaries to be fully statically linked, which is a more predictable environment for binaries, but Windows's approach composes better, as every process loads DLLs and this allows for things like graphics drivers and COM to work more reliably. As things stand on Linux you can't use the GPU in a portable statically linked app, because the kernel doesn't define the semantics of dynamic linking.
- fc417fc802 2mo agoTBF the GPU thing makes a fair amount of sense if you dig into it. It arguably falls entirely outside the kernel's domain of responsibility. However given how fundamental GPU acceleration is (as well as various other pieces of dedicated hardware in various scenarios) it would be nice if the kernel defined some basic portable semantics for linking with important drivers. These could exist independently of libc and the rest of userspace purely as an optional fallback. ... or we could all just include a glibc compatible dlopen routine in our statically linked binaries instead of worrying about pedantic hypotheticals.
- inigyou 2mo agoYeah we could all just use glibc. You see the problem with that though right?
- fc417fc802 2mo agoThat isn't at all what I said. I'm pointing out that in reality there aren't 20 competing libc implementations each with a unique dynamic linking scheme used by the userspace of 20 corresponding linux distributions. Instead we have ... glibc. So if the kernel actually specified a common portable linking scheme to fall back on as a means to interface with critical drivers it would presumably adopt the glibc way of doing things for that purpose. Also I did not say "just use glibc" but rather suggested to just include a secondary glibc compatible dlopen routine. Exactly as you would have to do if the kernel bothered to specify.
- inigyou 2mo agoIf the kernel wanted to force you to use glibc it would do so. We could get rid of the stupid hardcoded paths in PT_INTERP for example.
- fc417fc802 2mo agoRight. Obviously. What I'm pointing out is that if the kernel decided to include dynamically linking to certain drivers within its scope (which it does not wish to do at present as you rightly point out) then it would need to specify a scheme for doing so. At which point glibc is all but a foregone conclusion. So just pretend they did that and include a second dlopen routine and get on with life because at that point you're compatible with ~all major linux distros. Far more pressing is a blessed filesystem path for where to find the things.
- dataflow 2mo agoFYI, Windows's approach is better in some respects, like letting you avoid syscall overhead in some cases.