Evaluate whether or not usage of vDSOs (virtual dynamically linked shared objects; vDSO) can be useful in a GNU Hurd system.
Explanation and example for the Linux kernel: Creating a vDSO: the Colonel's Other Chicken, Matt Davis, 2012-02-06. The Resources given are also worth reading. Basically, this is useful for exporting data from the kernel (generally, or given a process context (Unix), or task/thread context, and so on).
On a GNU Hurd system, parts of the data that makes up a process context doesn't
actually live inside the kernel, but instead is directly held in glibc. For
example sysdeps/mach/hurd/getpid.c:__getpid
does a mere return _hurd_pid
.
For this reason, vDSOs might not be as useful on GNU Hurd as they are with the
Linux kernel. Or, put another way, as GNU Hurd system doesn't have many
system calls, also there aren't many that could be replaced.
Generally only real system calls should be candidates for implementation with vDSO code, because otherwise that'd break the (RPC) system's inherent virtualization capabilities.
Having vDSO code might be useful for:
mach_*_self
:mach_host_self
,mach_task_self
,mach_thread_self
?-
Every application can then use that via the regular
gettimeofday
/clock_gettime
and similar calls instead of using the special ?libshouldbeinlibc's<maptime.h>
interface.Can implement
clock gettime
stuff more easily that way, for example for nanosecond precision?Now, the ?mapped-time interface is virtualizable -- the question is whether there is a way so that we can make a compromise here?