| > harmful or inefficient 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. |
The vDSO linking happens once, at startup. io_uring is a continuous service.
With this fundamental of a difference in perspective between us I don't think it's useful to sink further time into this discussion thread.