Re: [RFC/PATCH] ARM: VDSO support

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 7 Apr 2015, Nathan Lynch wrote:

> I referred specifically to the recent x86 VDSO work when writing this.
> Although unlike the support which was added for the 32-bit x86 VDSO,
> this code introduces a test and branch into the system call path rather
> than an unconditional dispatch through a function pointer.  This seems
> to impose the least overhead.  For example on i.MX6 (Cortex-A9), where I

That suggests making that specific point configurable by architectures 
(VSYSCALL_TEST_IN_SYSCALL_PATH or similar), with comments on the ARM 
definition explaining the reason for the choice there.

> I avoided implementing INLINE_VSYSCALL for ARM partly out of the perhaps
> mistaken belief that it would require assembly (both arm and thumb
> versions of INLINE_VSYSCALL_NCS), and partly in order to avoid using
> preprocessor-pasting which defeats grep (__vdso_##name).  But if
> INLINE_VSYSCALL is the preferred method, I can use that; I have an older
> version of the patch which has it.

I don't think you should need assembly; the x86_64 version does a normal 
function call.  Indeed, maybe something like the x86_64 definition should 
go in a new sysdeps/unix/sysv/linux/sysdep.h, with all Linux architectures 
being made to use that file (architectures with existing definitions could 
still override them if they have good reasons to do so).

In general, the preferred method is to keep architecture-specific code to 
a minimum (cf the recent removal of lots of architecture-specific assembly 
in NPTL, for example); if something can be done generically, there should 
be a good reason (such as your benchmark results showing one approach is 
more efficient than another) for adding anything architecture-specific 
beyond what's needed to cause the generic code to be used.

-- 
Joseph S. Myers
joseph@codesourcery.com