[PATCH v7 7/9] ARM: add vdso user-space code

On 06/30/2014 10:59 AM, Andy Lutomirski wrote:

On 06/28/2014 08:26 AM, Russell King - ARM Linux wrote:

quoted

On Sun, Jun 22, 2014 at 10:11:56PM -0500, Nathan Lynch wrote:

quoted

Place vdso-related user-space code in arch/arm/kernel/vdso/.

It is almost completely written in C with some assembly helpers to
load the data page address, sample the counter, and fall back to
system calls when necessary.

If CONFIG_ARM_ARCH_TIMER is not enabled, the vdso cannot service
high-resolution clocks and falls back to syscalls.  Low-resolution
clocks e.g. CLOCK_REALTIME_COARSE can be serviced regardless.

Okay, how is this used by userspace?

It seems that on ARM, we generate a dso with these symbols:

DYNAMIC SYMBOL TABLE:
000001e4 l    d  .eh_frame_hdr    00000000              .eh_frame_hdr
00000000 g    DO *ABS*    00000000  LINUX_3.17  LINUX_3.17
000003c4 g    DF .text    00000080  LINUX_3.17  __kernel_clock_getres
00000444 g    DF .text    0000002c  LINUX_3.17  __kernel_gettimeofday
00000298 g    DF .text    0000012c  LINUX_3.17  __kernel_clock_gettime

Sorry, late to the thread.

I think that, if your function signatures match, you should give them
the same names and versions as for x86 (i.e. LINUX_2.6,
__vdso_clock_gettime).  Userspace will thank you.

I don't care strongly about it, but I was following arm64's example with
the naming, and I thought the version should match the Linux version in
which the VDSO symbols were introduced.  I can see that about half the
vdso-providing architectures (e.g. arm64, powerpc, s390) follow that
version convention instead of using LINUX_2.6.  However, looking through
git history I see that when people add new symbols to their VDSOs they
don't mark them with the current Linux version -- for example, when
powerpc added getcpu -- so I'm left thinking the version is not that
meaningful.

In other words, I'm inclined to make the changes you suggest, unless
someone knows why I shouldn't.

Don't do the weak clock_gettime, etc aliases, though.  That was never a
good idea to begin with.

OK, that was my suspicion, thanks for confirming.