Earlier quoted context omitted.
Yeah. On Linux it's just an optimization. What user space really wanted was a way to memory map some kernel data into the process address space in order to avoid switching to kernel mode while accessing it. Instead Linux memory mapped an entire ELF whose only purpose is to wrap the data. Newer system calls like io_uring are doing it right.
Strongly disagree that providing the vDSO in ELF file format is somehow harmful or inefficient. You'll need a compatibility mechanism in any case since the exposed features will change over time, and doing that through normal symbol resolution avoids a whole bunch of extra effort. And after ld.so is done with relations on executable startup, it makes no difference in performance either. Look at the Linux architecture…
It's not harmful, it just requires a lot of machinery. The normal system call entry point is perfectly simple, minimal, sufficient and language agnostic.
As for inefficient, program startup speed matters. It's probably not contributing much to the overall profile but it's still parsing binary formats and looking up strings in hash tables. This is definitely stuff that could be eliminated entirely. Code could conceivably mmap a gettimeofday buffer later on when it actually needs it instead of doing it on the startup procedure of every single process. Only reason it's not done this way is history.
> You'll need a compatibility mechanism in any case since the exposed features will change over time
Not really. Existing system calls stay as is. Linux won't break them, they remain supported. New users will use the latest version of the system call.
> And after ld.so is done with relations on executable startup
Assumes that there is an ld.so. It's a completely optional component. The system should be usable without it.
> Look at the Linux architectures that have a vDSO in non-ELF format. It's seriously ugly.
We agree on this. I have no objection to the ELF format. If a vDSO must be provided, then ELF is a good a format for it.
My point is that providing the vDSO should not actually be necessary, and that no system call should be forced to go through it.
> I don't think the comparison with io_uring is valid either, very different kind of API
Why? Both involve kernel/userspace shared memory. The difference is the vDSO hides the memory behind a function call while io_uring gives you the parameters you can pass to mmap to control it yourself, no ELF needed.