Re: [RFC PATCH v3 08/12] lib: vdso: allow arches to provide vdso data pointer
From: Christophe Leroy
Date: Thu Jan 16 2020 - 04:16:25 EST
Thomas, Andy,
Le 15/01/2020 Ã 07:15, Christophe Leroy a ÃcritÂ:
Le 15/01/2020 Ã 00:06, Thomas Gleixner a ÃcritÂ:
Christophe Leroy <christophe.leroy@xxxxxx> writes:
 static __maybe_unused int
+#ifdef VDSO_GETS_VD_PTR_FROM_ARCH
+__cvdso_clock_gettime_common(const struct vdso_data *vd, clockid_t
clock,
+ÂÂÂÂÂÂÂÂÂÂÂÂÂ struct __kernel_timespec *ts)
+{
+#else
 __cvdso_clock_gettime_common(clockid_t clock, struct
__kernel_timespec *ts)
 {
ÂÂÂÂÂ const struct vdso_data *vd = __arch_get_vdso_data();
+#endif
ÂÂÂÂÂ u32 msk;
If we do that, then there is no point in propagating this to the inner
functions. It's perfectly fine to have this distinction at the outermost
level.
In v2, I did it at the arch level (see
https://patchwork.ozlabs.org/patch/1214983/). Andy was concerned about
it being suboptimal for arches which (unlike powerpc) have PC related
data addressing mode.
Wouldn't it be the same issue if doing it at the outermost level of
generic VDSO ?
Any opinion on this ?
From your point of view, what should I do:
A/ __arch_get_vdso_data() handled entirely at arch level and arches
handing over the vdso data pointer to generic C VDSO functions all the
time (as in my v2 series) ?
B/ Data pointer being handed over all the way up for arches wanting to
do so, no changes at all for others (as in my v3 series) ?
C/ __arch_get_vdso_data() being called at the outermost generic level
for arches not interested in handling data pointer from the caller (as
suggested by Thomas) ?
Andy, with A/ you were concerned about arches being able to do PC
related accesses. Would it be an issue for C/ as well ? If not, I guess
C/ would be cleaner than B/ allthought not as clean as A which doesn't
add any #ifdefery at all.
Thanks
Christophe