C library system-call wrappers, or the lack thereof

If you are enthusiastic about replacing NSS with an IPC-based API, please, promote use of nscd by default in Debian and Fedora! IMO, that's the only realistic route to achieve the goal.

systemd depends on glibc but it's not a hard dependency, you can compile it with musl with only minor changes (like adding strndupa).

It also seems to be the perfect place for a bus1-broker.

Principally, it means that we don't need to do dlopen()s or other shared library operations when NSS ops are requested, which removes a whole pile of complexity from the dynamic linker since right now people assume that they can do name lookups in statically linked programs as well. This is slated to be removed soonish, but I do wonder how much this will break. (There are hardly any statically linked programs left, not against glibc anyway, so perhaps not much.)

This does add extra complexity of its own, notably that one has to track the lifetime of this process without disturbing the caller's waitpid()dery, signalfds or SIGCHLD dispatch, and that one must arrange to communicate with this process without the extra fds one must hold open to do so disrupting the rest of the process (which tends to assume that libc holds no fds and does nothing that might affect signals outside a single function call unless explicitly requested). Solving these problems in a backward-compatible way seems likely to be difficult, but it would benefit not only libc but every other library out there which needs to do similar things.

> What is wrong with having iconv in glibc?

For a long time it was outdated enough that anything that actually cared about localization had to use another library. This isn't true any more, though: iconv maintenance is one of many areas where the new glibc governance model has really shone.

(I agree with you that ditching symbol versioning is madness. We need much *more* of it in the Linux world, not much less.)

One problem with NSS is sandboxing, for example via seccomp.

A program could suddenly require completely different syscalls and/or access completely different files due to NSS.

This is just a bad design, it can introduce blocking in unexpected places and foul the seccomp filters and so on. Oh, and NSS is also synchronous.

It also severely limits what is available. For example, you can't easily validate password against /etc/shadow without having access to it.

Preventing static linking is just a cherry on top.

> What is wrong with having iconv in glibc?
Lots of crap with an unusable interface. It should either be removed or re-done correctly.

> Although I'm not an expert in symbol versioning at all, this statement sounds too categorical for me. What is the alternative? Sometimes you just need to adjust the behavior of a function for new code while preserving old behavior for already build programs.
Don't adjust user-visible behavior of existing functions in the freaking glibc.

It's not rocket science, it's just a freaking libc. You simply don't change its visible behavior.

> Right now? maybe musl is a good answer, I don't know – does it support pthreads, cancellation, C++-ish constructors and destructors, and all the other interesting features that complexify glibc (thread-local 'errno' et al.)?
musl supports pthreads and cancellation (which should also be removed) and all the sane features (non-TLS errno shouldn't even exist).

Yes, it supports all of those, and does so in a less bug prone manner than glibc.

Arguably the biggest functional differences between glibc and musl are in locale support (musl only supports C and UTF-8), and missing NSS and PAM functionality, though musl recently gained nscd support.

IME the biggest technical difference is that glibc heavily relies on linker and runtime hacks, which has been the source of many races in glibc's threading runtime, some still unresolved (I've confirmed and reported at least 2, IIRC.) musl libc eliminated an entire class of threading bugs by implementing pthreads entirely within libc and discarding the distinction between threaded and non-threaded runtimes, whereas glibc dedicates a tremendous amount of complexity to supporting dynamic initialization of pthreads when dlopen'ing a libpthread-dependent.

Locale, NSS, PAM, and dynamic pthread initialization are the primary sources of complexity (disregarding programming style and conventions) that make glibc source nearly impenetrable as compared to musl libc. Similarly, the implementation of those features also account for much of glibc's complex linking hacks.

I think symbol versioning is a great idea. Where it falls short is in poor integration with the toolchain, and in particular compilers, which require writing ad hoc macro and assembly code to mark versions. It would also be nice to have a tool which could scan libraries and report on symbol versioning information, including potential inconsistencies--where versioning could be used and where it's being used improperly. Symbol versioning will continue to remain niche and poorly appreciated unless and until it's better integrated with toolchains. Unfortunately, that seems increasingly less likely judging by the choices languages like Go and Rust are making, sentiments which seem to be shared by alternative toolchains like LLVM. Which is what it all really boils down to--the quality of toolchain support is often the ultimate arbiter of what people come to believe to be "proper" solutions.

That said, musl libc itself has less need for symbol versioning because it adheres tightly to POSIX and, of course, lacks glibc's legacy baggage--both self-inflicted and unavoidable. It would be nice for musl's linker to gain symbol versioning support, though.

One slightly annoying thing about musl is that it actively *prevents* leaking version information via headers. It's difficult if not impossible to support header-only feature detection with musl libc. There are few interfaces which musl lacks, though that's partly an artifact of most musl environments being reliably modern--you can get away with assuming that musl supports, e.g., dup3 simply because if you're compiling against musl at all it's invariably a very recent release matched to an equally recent kernel. OTOH, many *other* environments may lack support for a particular feature, which means that in portable code rather than asserting the use of the few libcs (including musl) that support feature X, you have to assert the non-use of all the *other* libcs. In other words, because you can't positively assert musl directly, you must assert it by negative implication, requiring enumeration of unsupported environments.[1] In effect, musl libc's policy can have the perverse (yet *known* and *intended*) effect of requiring the use of autoconf-style feature detection. I say perverse because over the past 20 years POSIX has almost completely eliminated subtle API and ABI incompatibilities, and led to a much more uniform C environment. Most extensions, such as epoll/kqueue, are easily and reliably detected via headers[2], so the use of autoconf-style feature detection has never been less necessary, musl's policy notwithstanding.

[1] That's not always a bad thing, and often the better approach. But it would be nice to have a choice. And in any event the fact remains that you can't *exclude* older musl releases, either, which will become a problem if musl begins to see wider adoption.

[2] This is why common C convention is still to use macro constants rather than enums, which will continue until we can enjoy compiler support for type detection similar to the __has_include built-in.

It will future proof your work and is often less expensive than committing resources to a soft fork.

That's why a split of the C library is needed. One part is the syscall stuff (let's call it liblinux for now) and the other part is the C library with all of its string manipulation, memory management, pam, etc, etc.

This would let kernel devs also develop the userspace counterparts of their system calls while not burdening them with all the other stuff a C library must do. liblinux could even be statically linked into glibc if you want to avoid changing all Makefiles in the world.

Another advantage is that liblinux would become the new ABI, whereas the userspace/kernelspace interface could undergo changes once in a while. And we'd have a REAL reason to increase the kernel major version ;-)