> On Nov 13, 2018, at 11:39 AM, Dave Martin <Dave.Martin@xxxxxxx> wrote: > > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote: > > [...] > >> We can learn something from how Windows does things. On that system, >> what we think of as "libc" is actually two parts. (More, actually, but >> I'm simplifying.) At the lowest level, you have the semi-documented >> ntdll.dll, which contains raw system call wrappers and arcane >> kernel-userland glue. On top of ntdll live the "real" libc >> (msvcrt.dll, kernel32.dll, etc.) that provide conventional >> application-level glue. The tight integration between ntdll.dll and >> the kernel allows Windows to do very impressive things. (For example, >> on x86_64, Windows has no 32-bit ABI as far as the kernel is >> concerned! You can still run 32-bit programs though, and that works >> via ntdll.dll essentially shimming every system call and switching the >> processor between long and compatibility mode as needed.) Normally, >> you'd use the higher-level capabilities, but if you need something in >> ntdll (e.g., if you're Cygwin) nothing stops your calling into the >> lower-level system facilities directly. ntdll is tightly bound to the >> kernel; the higher-level libc, not so. >> >> We should adopt a similar approach. Shipping a lower-level >> "liblinux.so" tightly bound to the kernel would not only let the >> kernel bypass glibc's "editorial discretion" in exposing new >> facilities to userspace, but would also allow for tighter user-kernel >> integration that one can achieve with a simplistic syscall(2)-style >> escape hatch. (For example, for a long time now, I've wanted to go >> beyond POSIX and improve the system's signal handling API, and this >> improvement requires userspace cooperation.) The vdso is probably too >> small and simplistic to serve in this role; I'd want a real library. > > Can you expand on your reasoning here? > > Playing devil's advocate: > > If the library is just exposing the syscall interface, I don't see > why it _couldn't_ fit into the vdso (or something vdso-like). > > If a separate library, I'd be concerned that it would accumulate > value-add bloat over time, and the kernel ABI may start to creep since > most software wouldn't invoke the kernel directly any more. Even if > it's maintained in the kernel tree, its existence as an apparently > standalone component may encourage forking, leading to a potential > compatibility mess. > > The vdso approach would mean we can guarantee that the library is > available and up to date at runtime, and may make it easier to keep > what's in it down to sane essentials. Hmm. Putting on my vDSO hat: The vDSO could provide all kinds of nifty things. Better exception handling comes to mind. But it has two major limitations that severely restrict what it can do: - It can’t allocate memory. We probably want to keep it that way. - It can’t use TLS. Solving this without genuinely awful ABI issues may be extremely hard. We *could* require callers to pass a thread pointer in, I suppose. Also, if we make the vDSO stateful, CRIU is going to have a blast. We might need to expose explicit save and restore abilities. As a straw man use case, it would be neat if DSOs (or the loader, maybe) could register a list of exception fixups per DSO. The kernel could consult these lists before delivering a signal. ISTM it wouldn’t be so crazy if the vDSO handled registration, although it could uses syscalls as well. If the vDSO did it, it would need somewhere to put the lists.
