From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1310 invoked from network); 11 Sep 2020 00:28:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 11 Sep 2020 00:28:31 -0000 Received: (qmail 32140 invoked by uid 550); 11 Sep 2020 00:28:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19716 invoked from network); 11 Sep 2020 00:08:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=pAzc5e6mjEqhJOpVR6jdXBrb8z2jZXbC3rVX+owg1yY=; b=nqB3Isb3RAIetD9EZd6Twg3MJ6CinykEJVnSliGDqdIdMd7AQ6j1s0bi+l4U4ImE+k yJwI08r8qAb+1t3aGWFT+0GOahScwyjwZM8A2aBlcZSkGkts5QSDktt6NrMl/yfFzm+i +orTSf0QKHGF6CaxjbkZYMDVSPEvplPNYY5w/2UrXtD22Ickk+TbM7rFtzGpLl6bIqaC 2OqAq46RYcZBPoyvTZLxj98jNZHXJ9LQYV88msXbvksYeF+xp1FalRTqATbcXJGfSNLD jWFnBMX3ij6+keWdHdSLJB0tqpLMYO3sIH5XTBNzy4RdlaT8CDQ+ZQZ0W31AHMsLLFbe uEDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=pAzc5e6mjEqhJOpVR6jdXBrb8z2jZXbC3rVX+owg1yY=; b=IuYyjMNaRLVTQpMyd995lr718R3ea8QeH6L7tq1zaMVdgWARQmIgazhvYiPzWowqXQ jqMSOT4BLz1xY5ShJvQ9TqczvKSXfsoKiu16h3bXQJ14an3KW9i5WR/QhTpTz198oCS/ I7AL7a1xxIo2bwBNBUIecPgoSBreYdpvg1A4BEdnjIe8DWeTsRQ86uk2gET+j2JuR7tc asAwVnBM03p8ZbFjS7obZHHHAvF+rMOSGYyd44DhB8SVCX6z0XZQkyG7knDHMiG25dIJ yZLCWL3NK4w+i4F8AShjGDwEb/jgZlG0LOlU9toc28OHalxamuRdq1m4dxTGGT95ewDA M5Lw== X-Gm-Message-State: AOAM533+4ZH87h83X+15etYgpxzCPVwDIv3950DS4FNFLZl1/BxEtZpC 0ZXNA9zUcr6UXZc2+y2QGifZbTHVNxnTJ460 X-Google-Smtp-Source: ABdhPJzKiwv+Itauo5GZJ9tXqSYwoKv1KcWxlGz8llffY3iROEGS8dk9PtBHAeIzO1JMeqiCfX1qGg== X-Received: by 2002:a63:ff11:: with SMTP id k17mr6433214pgi.352.1599782896426; Thu, 10 Sep 2020 17:08:16 -0700 (PDT) Date: Thu, 10 Sep 2020 17:08:16 -0700 (PDT) X-Google-Original-Date: Thu, 10 Sep 2020 17:08:14 PDT (-0700) In-Reply-To: CC: Arnd Bergmann , dalias@libc.org, musl@lists.openwall.com From: Palmer Dabbelt To: vincenzo.frascino@arm.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] riscv32 v2 On Thu, 10 Sep 2020 03:01:31 PDT (-0700), vincenzo.frascino@arm.com wrote: > > > On 9/10/20 8:36 AM, Arnd Bergmann wrote: >> On Thu, Sep 10, 2020 at 1:08 AM Palmer Dabbelt wrote: >>> On Wed, 09 Sep 2020 14:36:44 PDT (-0700), dalias@libc.org wrote: >>>> On Wed, Sep 09, 2020 at 02:28:55PM -0700, Palmer Dabbelt wrote: >>>>> On Wed, 09 Sep 2020 13:28:27 PDT (-0700), dalias@libc.org wrote: >>>> Possible addition of vdso clock_gettime isn't a blocker for moving >>>> forward with the musl port, but syscall_arch.h should accurately >>>> describe what's available and should not attempt to use vdso before >>>> it's a public kernel interface (e.g. resolving the question of what >>>> the function name will be). So I think it should be removed for now. >>> >>> Sorry if that was confusing, but I definitely agree. >>> >>> I guess my point was that the lack of VDSO clock functions on rv32 was probably >>> an oversight, but one that shouldn't block the port. We definitely can't just >>> make up a kernel interface, particularly as the reason we don't have these on >>> rv32 is because the generic versions of the functions we're using don't appear >>> to run on 32-bit targets. >>> >>> That probably means there's some more subtle issue, though TBH I don't know >>> enough about the 64-bit-ification of time_t for it to just jump out at me. I >>> don't want to derail the thread too much, but I tried the obvious thing >> >> When the vdso for rv64 was added, there was no time64 support in the >> vdso code in general, as this only came with the "generic vdso" infrastructure >> that was added later on, with commit ad5d1122b82f ("riscv: use vDSO >> common flow to reduce the latency of the time-related functions") in v5.8. >> >> At that point it probably should have been added as well. >> >>> --- a/arch/riscv/kernel/vdso/Makefile >>> +++ b/arch/riscv/kernel/vdso/Makefile >>> @@ -7,9 +7,7 @@ ARCH_REL_TYPE_ABS := R_RISCV_32|R_RISCV_64|R_RISCV_JUMP_SLOT >>> include $(srctree)/lib/vdso/Makefile >>> # Symbols present in the vdso >>> vdso-syms = rt_sigreturn >>> -ifdef CONFIG_64BIT >>> vdso-syms += vgettimeofday >>> -endif >>> vdso-syms += getcpu >>> vdso-syms += flush_icache >>> >>> and it doesn't build. I've added Arnd, who might have a better idea of what's >>> going on. Whatever happens, I think the best bet is to just drop the clock >>> functions (specifically __vdso_{clock_gettime,gettimeofday,clock_getres}) from >>> the rv32 port right now. >> >> For rv32 you need clock_gettime64, not clock_gettime, which in the Linux >> ABI refers to the interface with the old timespec. There was some debate >> over whether clock_getres_time64 and gettimeofday_time64 would make >> sense to be added here, but I have so far leaned to the position that these >> are not as performance critical and not worth the effort. >> >> Vincenzo has argued that we might want to extend the generic vdso code >> to include a number of additional syscall implementations, which would >> then include gettimeofday_time64 and clock_getres_time64. >> > > I agree with Arnd, clock_getres_time64 and gettimeofday_time64 were not added in > the original port because not considered as performance critical as > clock_gettime64. We might reconsider if there is a strong use case for those. OK, seems reasonable to me. I guess we can always add things later if they end up being important, though I don't really have any feel for this sort of stuff so I don't really have an opinion either way. Thanks! > >> Arnd >>