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
sysdeps/mach/hurd/getpid.c:__getpid does a mere
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.
Having vDSO code might be useful for:
Every application can then use that via the regular
clock_gettimeand similar calls instead of using the special 's
clock gettimestuff more easily that way, for example for nanosecond precision?
Now, theis virtualizable -- the question is whether there is a way so that we can make a compromise here?