From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751779AbdKHJh6 (ORCPT ); Wed, 8 Nov 2017 04:37:58 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:54794 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750817AbdKHJhx (ORCPT ); Wed, 8 Nov 2017 04:37:53 -0500 X-Google-Smtp-Source: ABhQp+Tjy4zmBvr6FoiKvDjexypi9lzgFuDUtcdOuZT11XmO3T0jgQ/NoisNsDYm4VxjEPdFD2KnFVHLDfgOMTwwXX4= MIME-Version: 1.0 In-Reply-To: <0911917e908c7648d25b33663afc88f5aca6bb4d.1510118606.git.green.hu@gmail.com> References: <0911917e908c7648d25b33663afc88f5aca6bb4d.1510118606.git.green.hu@gmail.com> From: Arnd Bergmann Date: Wed, 8 Nov 2017 10:37:52 +0100 X-Google-Sender-Auth: lX-OW500cMa8-c2x3YICycLQDcs Message-ID: Subject: Re: [PATCH 16/31] nds32: VDSO support To: Greentime Hu Cc: greentime@andestech.com, Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , Palmer Dabbelt , Deepa Dinamani Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu wrote: > --- /dev/null > +++ b/arch/nds32/include/asm/vdso_datapage.h > @@ -0,0 +1,51 @@ > +#ifndef __ASM_VDSO_DATAPAGE_H > +#define __ASM_VDSO_DATAPAGE_H > + > +#ifdef __KERNEL__ > + > +#ifndef __ASSEMBLY__ > + > +struct vdso_data { > + bool cycle_count_down; /* timer cyclye counter is decrease with time */ > + u32 cycle_count_offset; /* offset of timer cycle counter register */ > + u32 seq_count; /* sequence count - odd during updates */ > + u32 xtime_coarse_sec; /* coarse time */ > + u32 xtime_coarse_nsec; > + > + u32 wtm_clock_sec; /* wall to monotonic offset */ > + u32 wtm_clock_nsec; > + u32 xtime_clock_sec; /* CLOCK_REALTIME - seconds */ > + u32 cs_mult; /* clocksource multiplier */ > + u32 cs_shift; /* Cycle to nanosecond divisor (power of two) */ > + > + u64 cs_cycle_last; /* last cycle value */ > + u64 cs_mask; /* clocksource mask */ > + > + u64 xtime_clock_nsec; /* CLOCK_REALTIME sub-ns base */ > + u32 tz_minuteswest; /* timezone info for gettimeofday(2) */ > + u32 tz_dsttime; > +}; I need some insight from Deepa and Palmer here: to prepare for 64-bit time_t in the future, would it make sense to define the vdso to use 64-bit seconds numbers consistently, and provide vdso symbols that return 64-bit times, having the glibc convert that to normal timespec values, or should we leave it for now? For the normal syscalls I think we are better off keeping things consistent between architectures, but the vdso is architecture specific by definition, so we may as well use 64-bit times there now (same for risc-v, which still has time to modify this before the 4.15 release and glibc merge). > +/* > + * This controls what symbols we export from the DSO. > + */ > +VERSION > +{ > + LINUX_2.6 { > + global: > + __kernel_rt_sigreturn; > + __vdso_gettimeofday; > + __vdso_clock_getres; > + __vdso_clock_gettime; > + local: *; > + }; > +} I still struggle to understand how symbol versioning is supposed to work in a vdso (as opposed to a library you compile against), but I think this should use the version from the kernel that you plan to merge into, i.e. LINUX_4 or LINUX_4_16. Arnd