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,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9028 invoked from network); 3 May 2023 22:58:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 22:58:54 -0000 Received: (qmail 5852 invoked by uid 550); 3 May 2023 22:58:50 -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 5819 invoked from network); 3 May 2023 22:58:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683154718; x=1685746718; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0/i2Wk+YjzNlx4q8q5azz7+0dyJcNLIq/BXC9zss3Is=; b=kPtrnWWsFH4eLPUm0Q6ZqmI75JI1qzZ09kBNTVAHWT4Jfz/uLkqfBHK1yrEUjFfb+g UgvsdbiBCk3gnTcRRmR59+VmRGnsxD02K+AWi75FzYMN9eCmNveUvy5hbNI33sKQRD/B 2VhDsDxfi5gjNKkW9mIdGnljh5/ohTxalfcx6s+k7SQ/1WIi7b6NFEt8rTwKv/dp5z88 eYrpzDAQzmL2sCe+5A9sCxRQDsqkZM2XPvcf7VQ1ObKpdAL6/F7i1ZQ9om/vrvCY4ivM qRbw34pf7VoAlxbVp+aVf3vvfEDrvGmeW7GnCYveB2+humEFDdTh8uSHIFaABQEYWU3U udlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683154718; x=1685746718; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0/i2Wk+YjzNlx4q8q5azz7+0dyJcNLIq/BXC9zss3Is=; b=RS9PziRuY5I1hSjZ2LcPkOLLAeqr+Y7cvQFvWvem0owOBe3kkX/R5qeH2i/vDUy1zb Fv6A6VAVJTC1kOyEdo1WycfDvqKJMBTP8OE7N1hfXWTXIFtTCMf3cOIpVSwrubUW1YGT 9/mAn4C8m55vDw82LijpNMcvYR4dOlupCOLLW7Hm4fTSQuSYh4jGJZQS0rWXN9Mbf/HE CSTAS6/JNKzrMnarUv7Oj9NK0laNB6LuyRYQBqVH2pUGPn1lDRG0h9+/D9IH+wlMWWlM awphUvkAD28z9yP9J+4cxpYb/xq+fSAzKYRlkTlwu8mI3q1h7iVsZ8dE+qey3lsrXym3 D+oA== X-Gm-Message-State: AC+VfDyhWPcjWeZYnUgaMWFOgaxXvNLZLcOIPCnhb9JlVYW2NB0ZXiQ0 qr70VV2dukzFEPpzh7ozInDSR9TXnAdPFmTs26juR2fUbkSswULkHPwP8A== X-Google-Smtp-Source: ACHHUZ4tsik55OCpbFy3ZabZsDXG18uyFx4JEiz23cdPvpGs0A6SEC52EiWtHH+5BCdIfyOvG2SSLYez6xATMgggELQ= X-Received: by 2002:a05:6214:f2a:b0:5e0:7ecb:8ffb with SMTP id iw10-20020a0562140f2a00b005e07ecb8ffbmr13429160qvb.8.1683154717810; Wed, 03 May 2023 15:58:37 -0700 (PDT) MIME-Version: 1.0 References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> In-Reply-To: <20221119153350.292e390b@inria.fr> From: enh Date: Wed, 3 May 2023 15:58:26 -0700 Message-ID: To: musl@lists.openwall.com Cc: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= , Jason Ekstrand Content-Type: multipart/alternative; boundary="0000000000000f15e205fad1ffe6" Subject: Re: [musl] C23 implications for C libraries --0000000000000f15e205fad1ffe6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 19, 2022 at 6:34=E2=80=AFAM J=E2=82=91=E2=82=99=E2=82=9B Gusted= t wrote: > =E7=BD=97=E5=8B=87=E5=88=9A, > > on Sat, 19 Nov 2022 04:46:22 +0800 you (=E7=BD=97=E5=8B=87=E5=88=9A(Yongg= ang 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? > > I am not completely sure what you are asking. C2x was the short name > for C23 when we did not yet know that it will come out in 2023. > > C23 indeed adds three *optional* time bases `TIME_MONOTONIC`, > `TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the > POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and > `CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other > POSIX clocks, even if these are conceptually close, is not a good > idea, I think. > > That said, having time bases for C other than `TIME_UTC` is at the > liberty of the implementation, so musl could easily provide the > equivalent to all POSIX clocks that it interfaces. Currently these are > > #define CLOCK_REALTIME 0 > #define CLOCK_MONOTONIC 1 > #define CLOCK_PROCESS_CPUTIME_ID 2 > #define CLOCK_THREAD_CPUTIME_ID 3 > #define CLOCK_MONOTONIC_RAW 4 > #define CLOCK_REALTIME_COARSE 5 > #define CLOCK_MONOTONIC_COARSE 6 > #define CLOCK_BOOTTIME 7 > #define CLOCK_REALTIME_ALARM 8 > #define CLOCK_BOOTTIME_ALARM 9 > #define CLOCK_SGI_CYCLE 10 > #define CLOCK_TAI 11 > > This could easily be done by using > > #define TIME_UTC (CLOCK_REALTIME+1) > #define TIME_MONOTONIC (CLOCK_MONOTONIC+1) > #define TIME_ATIVE (CLOCK_PROCESS_CPUTIME_I+1) > #define TIME_THREAD_ACTIVE (CLOCK_THREAD_CPUTIME_ID+1) > #define TIME_MONOTONIC_RAW (CLOCK_MONOTONIC_RAW+1) > #define TIME_UTC_COARSE (CLOCK_REALTIME_COARSE+1) > #define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1) > #define TIME_BOOTTIME (CLOCK_BOOTTIME+1) > #define TIME_UTC_ALARM (CLOCK_REALTIME_ALARM+1) > #define TIME_BOOTTIME_ALARM (CLOCK_BOOTTIME_ALARM+1) > #define TIME_SGI_CYCLE (CLOCK_SGI_CYCLE+1) > #define TIME_TAI (CLOCK_TAI+1) > > and then adapting `timespec_get` a bit. This would be conforming to > current and future C, because the `TIME_` prefix is already reserved > for that purpose. > (i share others' skepticism that timespec_get() is very useful, and especially that non-ISO bases will ever be useful to anyway, but i like the idea of allowing future additions to "just work" with an old libc enough that i've implemented bionic's timespec_get()/timespec_getres() in this style.) > Unfortunately the choice of the values is an ABI choice, so before > doing so we should be sure that other C libraries on Linux use the > same values. > > (Rich: would you accept a patch that goes in that direction?) > > > When implement mesa vulkan driver, > > it's ask for CLOCK_MONOTONIC_RAW at > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe916= 1a7514173b5be24/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 > > I am not sure why you'd want to do this, are you trying to port that > code such that it gets rid of any reference to POSIX interfaces? If > so, you'd have to wait and see if other C libraries will interface the > "new" time bases that C23 specifies. (Or does your code only run with > musl or windows?) > > Then to know if a fallback to `CLOCK_MONOTONIC_RAW` is sensible, you > would have to inspect for which clocks the current function is really > used and if fallback is even needed in real life. > > J=E2=82=91=E2=82=99=E2=82=9B > > -- > :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: > :: :::::::::::::::::::::: gsm France : +33 651400183 > <+33%206%2051%2040%2001%2083> :: > :: ::::::::::::::: gsm international : +49 15737185122 > <+49%201573%207185122> :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: > --0000000000000f15e205fad1ffe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 19, 2022 at 6:34=E2=80=AF= AM J=E2=82=91=E2=82=99=E2=82=9B Gustedt <jens.gustedt@inria.fr> wrote:
=E7=BD=97=E5=8B=87=E5=88=9A,

on Sat, 19 Nov 2022 04:46:22 +0800 you (=E7=BD=97=E5=8B=87=E5=88=9A(Yonggan= g Luo)
<luoyonggang@= gmail.com>) wrote:

> There is a concept called CLOCK_MONOTONIC_RAW=C2=A0 (since Linux 2.6.2= 8;
> Linux-specific),
> May C2x provide TIME_MONOTONIC_RAW in future or can we just implement<= br> >=C2=A0 TIME_MONOTONIC with
> CLOCK_MONOTONIC_RAW=C2=A0 on Linux?

I am not completely sure what you are asking. C2x was the short name
for C23 when we did not yet know that it will come out in 2023.

C23 indeed adds three *optional* time bases `TIME_MONOTONIC`,
`TIME_ACTIVE` and `TIME_THREAD_ACTIVE` which are modeled after the
POSIX clocks `CLOCK_MONOTONIC`, `CLOCK_PROCESS_CPUTIME_ID` and
`CLOCK_THREAD_CPUTIME_ID`, respectively. Using them to map to other
POSIX clocks, even if these are conceptually close, is not a good
idea, I think.

That said, having time bases for C other than `TIME_UTC` is at the
liberty of the implementation, so musl could easily provide the
equivalent to all POSIX clocks that it interfaces. Currently these are

#define CLOCK_REALTIME=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00
#define CLOCK_MONOTONIC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1
#define CLOCK_PROCESS_CPUTIME_ID 2
#define CLOCK_THREAD_CPUTIME_ID=C2=A0 3
#define CLOCK_MONOTONIC_RAW=C2=A0 =C2=A0 =C2=A0 4
#define CLOCK_REALTIME_COARSE=C2=A0 =C2=A0 5
#define CLOCK_MONOTONIC_COARSE=C2=A0 =C2=A06
#define CLOCK_BOOTTIME=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07
#define CLOCK_REALTIME_ALARM=C2=A0 =C2=A0 =C2=A08
#define CLOCK_BOOTTIME_ALARM=C2=A0 =C2=A0 =C2=A09
#define CLOCK_SGI_CYCLE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
#define CLOCK_TAI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011<= br>
This could easily be done by using

#define TIME_UTC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_REA= LTIME+1)
#define TIME_MONOTONIC=C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_MONOTONIC+1)
#define TIME_ATIVE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_PROCESS_= CPUTIME_I+1)
#define TIME_THREAD_ACTIVE=C2=A0 =C2=A0 (CLOCK_THREAD_CPUTIME_ID+1)
#define TIME_MONOTONIC_RAW=C2=A0 =C2=A0 (CLOCK_MONOTONIC_RAW+1)
#define TIME_UTC_COARSE=C2=A0 =C2=A0 =C2=A0 =C2=A0(CLOCK_REALTIME_COARSE+1)=
#define TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1)
#define TIME_BOOTTIME=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(CLOCK_BOOTTIME+1) #define TIME_UTC_ALARM=C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_REALTIME_ALARM+1)<= br> #define TIME_BOOTTIME_ALARM=C2=A0 =C2=A0(CLOCK_BOOTTIME_ALARM+1)
#define TIME_SGI_CYCLE=C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_SGI_CYCLE+1)
#define TIME_TAI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_TAI= +1)

and then adapting `timespec_get` a bit. This would be conforming to
current and future C, because the `TIME_` prefix is already reserved
for that purpose.

(i share others' = skepticism that timespec_get() is very useful, and especially that non-ISO = bases will ever be useful to anyway, but i like the idea of allowing future= additions to "just work" with an old libc enough that i've i= mplemented bionic's timespec_get()/timespec_getres() in this style.)
=C2=A0
Unfortunately the choice of the values is an ABI choice, so before
doing so we should be sure that other C libraries on Linux use the
same values.

(Rich: would you accept a patch that goes in that direction?)

> When implement mesa vulkan driver,
> it's ask for CLOCK_MONOTONIC_RAW=C2=A0 =C2=A0at
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blo= b/c6c5949ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L= 557
>
> May intention is using C2x timespec_get
> to replace function
> vk_clock_gettime but it's lack of=C2=A0 TIME_MONOTONIC_RAW, so I d= on't know
> what's the best way

I am not sure why you'd want to do this, are you trying to port that code such that it gets rid of any reference to POSIX interfaces? If
so, you'd have to wait and see if other C libraries will interface the<= br> "new" time bases that C23 specifies. (Or does your code only run = with
musl or windows?)

Then to know if a fallback to `CLOCK_MONOTONIC_RAW` is sensible, you
would have to inspect for which clocks the current function is really
used and if fallback is even needed in real life.

J=E2=82=91=E2=82=99=E2=82=9B

--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: :::::::::::::::::::::: gsm France : +33 651400183=C2=A0 = =C2=A0::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gu= stedt ::
--0000000000000f15e205fad1ffe6--