On Wed, Nov 14, 2018 at 12:40:44PM +0100, Florian Weimer wrote: > * Dave Martin: > > > Fair points, though this is rather what I meant by "sane essentials". > > Because there are strict limits on what can be done in the vDSO, it may > > be more bloat-resistant and more conservatively maintained. > > > > This might provide a way to push some dumb compatibility kludge code > > that receives little ongoing maintenance outside the privilege wall, > > whereas it has to sit in the kernel proper today. > > > > In theory we could opt to advertise new syscalls only via vDSO entry > > points, and not maintain __NR_xxx values for them (which may or may > > not upset ptrace users.) Anyway, I digress... > > Is the vDSO available across all architectures? (I don't think we use > it on all architectures in glibc.) It's probably not available on all arches. > If not, a vDSO-based approach would merely lead to even more variance > between architectures, which can't be a good thing. That's a fair concern. Channeling syscalls through the vDSO could allow for a uniform syscall interface at the ELF linkage level, but only those arches that have a vDSO. There may be other issues too. Also, I don't say that we should definitely do this, just that it's a possibility. Cheers ---Dave
