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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25200 invoked from network); 20 Nov 2022 04:25:50 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Nov 2022 04:25:50 -0000 Received: (qmail 14175 invoked by uid 550); 20 Nov 2022 04:25:46 -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 14139 invoked from network); 20 Nov 2022 04:25:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gKJtE4fGNT5nTpaLsgtenzlYyhMY7CI9F39Dez5x8ZI=; b=EtMMT/VXa3p9AZQiNDSKlNGvI1UjmH5ryAs96Su+2fiHQF6qW+JtfA6BjRTejZQ0xG VCdABeAinSpGynvM6grXzpcOsItcPUEsUHBDveqjBvl4G7kXwnigVmVQP5EjaJYwLM09 zsUAgXECXheLXE+mnu8s8gelF7Xwx1cAUbjrGyuN0358Uurb57BpyNEaWJUFzVpWRVSY CRC/+zXtIijftib5kqe5sxgnnuWSptgTRe68DWyJSN4mQ1M3stqZyrd2lUL4ZvAygaK5 bxADD99B9aiiLJDSexT3eDuSYw4qo9hN+yQVn08PgxVzr8J36P5nDsBXuTrRWsSs98vd YLfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gKJtE4fGNT5nTpaLsgtenzlYyhMY7CI9F39Dez5x8ZI=; b=up9BsOJA2QK0zFmSWG0FiwceTfia8yNAQ0ahyvjGHdQPard0RJmg5Bx1qV+1PaF5/w QC6ro0IF7ZR6R1bxtg1l6wASXKt/GYcfrMwlGGddwxUpv8eSfjEiKAl0gEjUmf7+JTuy 4CymjsXZeDiPb1DnyfgK9BXvrUiK2bckpFZ1y6U/HRjp3dGPHf1K8riMWxjcjjSUsBvV LprZ/YeWxN1MQcU6MWeLkaKMCuenm2rH3PJxAl2CilpLW5rsdcw2qZXDab7RtR5owriZ ny9nu9EFK0WkGCodgsu0/3vlLSZe2pGwUVA5mzQ1qzE9FAnTH+NFkiooRv+xNM64kf5W GCeQ== X-Gm-Message-State: ANoB5plq22m1Iw7zg9/grM62wTlxC7GaKbmUSSeJryEIf2/xYXTdE5j5 P6s2IfLO2EEgoipmAEae1P390mwSiLcIbt1bX3IdIRJsU9Y= X-Google-Smtp-Source: AA0mqf5Xg3sYMvNWO3QjLCf+AWltY4jC6eY2NhwAutbiDorPsdfLohWhN0XGVhP0E2tdvju7CAxRXURCs9uj+frYXS8= X-Received: by 2002:a05:6102:2912:b0:3a6:5b26:2388 with SMTP id cz18-20020a056102291200b003a65b262388mr7625169vsb.56.1668918333451; Sat, 19 Nov 2022 20:25:33 -0800 (PST) MIME-Version: 1.0 References: <20220923162518.56284329@inria.fr> <20221119183145.GO29905@brightrain.aerifal.cx> In-Reply-To: <20221119183145.GO29905@brightrain.aerifal.cx> From: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= Date: Sun, 20 Nov 2022 12:25:21 +0800 Message-ID: To: musl@lists.openwall.com, Rich Felker Cc: Jens Gustedt , Jason Ekstrand Content-Type: multipart/alternative; boundary="0000000000006cb0ee05eddf54af" Subject: Re: [musl] C23 implications for C libraries --0000000000006cb0ee05eddf54af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 20, 2022 at 2:32 AM Rich Felker wrote: > > On Sat, Nov 19, 2022 at 04:46:22AM +0800, =E7=BD=97=E5=8B=87=E5=88=9A(Yon= ggang Luo) wrote: > > There is a concept called CLOCK_MONOTONIC_RAW (since Linux 2.6.28; > > Linux-specific), > > May C2x provide TIME_MONOTONIC_RAW in future or can we just implement > > TIME_MONOTONIC with > > CLOCK_MONOTONIC_RAW on Linux? When implement mesa vulkan driver, it's ask > > for CLOCK_MONOTONIC_RAW at > > > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe9161a= 7514173b5be24/src/vulkan/runtime/vk_device.c#L557 > > > > May intention is using C2x timespec_get to replace function > > vk_clock_gettime but it's lack of TIME_MONOTONIC_RAW, so I don't know > > what's the best way > > The code there is already doing exactly what it should do in the case > where CLOCK_MONOTONIC_RAW is not defined so I'm not sure what you're > trying to achieve. > > On a system where CLOCK_MONOTONIC_RAW is defined, the caller may have > (for likely-nonsensical reasons) chosen to pass CLOCK_MONOTONIC_RAW, > and they're handling the case where the kernel is too old to have that > extension clock by substituting CLOCK_MONOTONIC instead. That's the issue, when you access `CLOCK_MONOTONIC_RAW`, it's have to be defined, suppose we have standardized TIME_MONOTONIC_RAW, then we have no need get the time with, ``` #ifndef CLOCK_MONOTONIC_RAW // The code #endif ``` but with ``` if (timespec_get(ts, TIME_MONOTONIC_RAW) !=3D 0) { } ``` > > If CLOCK_MONOTONIC_RAW is not defined, then most certainly the caller > did not pass it (since there's no such thing) and thus there is no > need for any fallback code. > > No action is needed at all here. > > Rich -- =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo --0000000000006cb0ee05eddf54af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Nov 20, 2022 at 2:32 AM Rich Felker <dalias@libc.org> wrote:
>
= > On Sat, Nov 19, 2022 at 04:46:22AM +0800, =E7=BD=97=E5=8B=87=E5=88=9A(= Yonggang Luo) wrote:
> > There is a concept called CLOCK_MONOTONIC= _RAW =C2=A0(since Linux 2.6.28;
> > Linux-specific),
> > = May C2x provide TIME_MONOTONIC_RAW in future or can we just implement
&g= t; > =C2=A0TIME_MONOTONIC with
> > CLOCK_MONOTONIC_RAW =C2=A0on= Linux? When implement mesa vulkan driver, it's ask
> > for CL= OCK_MONOTONIC_RAW =C2=A0 at
> >
> > https://gitlab.freedesktop.org/mes= a/mesa/-/blob/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/v= k_device.c#L557
> >
> > May intention is using C2x ti= mespec_get to replace function
> > vk_clock_gettime but it's l= ack of =C2=A0TIME_MONOTONIC_RAW, so I don't know
> > what'= s the best way
>
> The code there is already doing exactly what= it should do in the case
> where CLOCK_MONOTONIC_RAW is not defined = so I'm not sure what you're
> trying to achieve.
>
&= gt; On a system where CLOCK_MONOTONIC_RAW is defined, the caller may have> (for likely-nonsensical reasons) chosen to pass CLOCK_MONOTONIC_RAW,=
> and they're handling the case where the kernel is too old to h= ave that
> extension clock by substituting CLOCK_MONOTONIC instead.
That's the issue, when you access `CLOCK_MONOTONIC_RA= W`, it's have to be defined, suppose we have
standardized TIM= E_MONOTONIC_RAW, then we have no need get the time with,
```
#ifndef CLOCK_MONOTONIC_RAW
=C2=A0// The code
#en= dif
```
but with
```
if (timespec_g= et(ts, TIME_MONOTONIC_RAW) !=3D 0) {
}
```



>
> If CLOCK_MONOTO= NIC_RAW is not defined, then most certainly the caller
> did not pass= it (since there's no such thing) and thus there is no
> need for= any fallback code.
>
> No action is needed at all here.
>= ;
> Rich



--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E6= =AD=A4=E8=87=B4
=E7=A4=BC
=E7=BD=97=E5=8B=87=E5=88=9A
Yours
=C2= =A0 =C2=A0 sincerely,
Yonggang Luo
--0000000000006cb0ee05eddf54af--