On Wed, Nov 8, 2017 at 9:00 PM, Deepa Dinamani <deepa.kernel@xxxxxxxxx> wrote:
> On Wed, Nov 8, 2017 at 1:37 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@xxxxxxxxx> wrote:
>>
>>
>> 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?
>
> Other architectures also have a similar way of defining these as u32
> (eg: x86) I think for performance reasons on 32 bit systems.
> u32 still works until 2106 as the timekeeping structures are s64. I
> was planning to leave it that way for x86.
Right, good point.
> If this architecture can live with u64, then it will be better to use it here.
As long as we don't need a division, using u64 is probably cheap enough,
we already need the retry loop.
>> 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).
>
> But, I don't think this vdso can return 64 bit times without syscalls
> for the architecture also supporting that. The problem is that all
> fallback paths depend on syscalls directly.
> Also I couldn't find any arch specific handling of vdso interfaces in
> glibc. I think they expect the vdso wrappers in the kernel to handle
> this part.
Do applications call into the vdso directly and expect to get a timespec
out? If they always go through the C library as an intermediate, then
the glibc clock_gettime() could do the conversion.
Arnd
