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 9546 invoked from network); 19 Nov 2022 17:20:07 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Nov 2022 17:20:07 -0000 Received: (qmail 28212 invoked by uid 550); 19 Nov 2022 17:20:04 -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 28170 invoked from network); 19 Nov 2022 17:20:03 -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=+8TBgSqzrR/2S098efxIBAvaJbCWyo+m/CB3gh60MoI=; b=OCDaNgwpstnhphcaB0LslpyM+5Sz9qDF7lDs4VEL/ETuW2f/b6grB91bXwuYR56+TS 0yhSWGd9O/kQdIaP0GNkayZirsiZ+OgLzWUT+ww2QvTWdgmMY7m9coMKOORc2XsEz3dH VPqDzeC8DMQv49Y1cGaG2PLTF049Jyoox2cS5AvG8K3H2Sn0q8BQyqirWb4alDo1IMax tEBg+6auO6XGS00v6UUrjZO2ERaSiet2pIUvYlikaaURDB8y+JxdxQns2y1NJ8j2+owO xJnsX3xchJs8BekdCljLLujtcp4GCG0z2Qr99nYBxovmcc8W38dtBwwD29lg54krd7q2 MMWw== 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=+8TBgSqzrR/2S098efxIBAvaJbCWyo+m/CB3gh60MoI=; b=X/R9i4gtYp+P9eVurEyR05G8M89/3LM4H+iWZUjJuGvDN/uHKjgV7VW7YqerOnY6UX j7yBaWEomQ04Q7KmqSyxOk73pngAZhnczyAyIlCgHOhHn8LOiNFqosR/Kc2SrtOG+/Ka Ez0WVturXiP93CkqpGaQRN99n1q12JFnMj3B47g5o07foTClUAk0S5iGuJDW1jOQs24q Mj3dMNEZzVqgAjAEAMbKwYWje0shzJuOTtNLk/tCeTbQ5aJU59k/n+LwBYTKB0/w259+ 3Ov4Ewdlsw1IIqpVdA9OVm+6MOOaYuouYr5d6BGN2Fqz/yDFDoh1uqjrZlA+NOuJsooP TJ9w== X-Gm-Message-State: ANoB5pnAtkOjP93iOlcUWGSEi/QS2bUXKe+LVNkMQ4WPU7qNeh0VH42r rgD0mZbkP+lKNFDGMc6l+XspjFcscHoQihgVI7b7Po968uDPeg== X-Google-Smtp-Source: AA0mqf4KIx8kcTeC+RetKq1jpQjc+noATYsbvShJG8aEGMOXd42DFvef7czOmwgM5DJIRIVx+9nbe90XpLwFC12oE0Q= X-Received: by 2002:ab0:6994:0:b0:411:502d:7c67 with SMTP id t20-20020ab06994000000b00411502d7c67mr6257312uaq.29.1668878390893; Sat, 19 Nov 2022 09:19:50 -0800 (PST) MIME-Version: 1.0 References: <20220923162518.56284329@inria.fr> <20221119153350.292e390b@inria.fr> In-Reply-To: <20221119153350.292e390b@inria.fr> From: =?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1byk=?= Date: Sun, 20 Nov 2022 01:19:40 +0800 Message-ID: To: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Cc: musl@lists.openwall.com, Jason Ekstrand Content-Type: multipart/alternative; boundary="000000000000a9a14605edd607e0" Subject: Re: [musl] C23 implications for C libraries --000000000000a9a14605edd607e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 19, 2022 at 10:33 PM J=E2=82=91=E2=82=99=E2=82=9B Gustedt 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) I like this list, as It doesn't have to be implemented, have such a complete list in C2x standard is very good > > 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. > > 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/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 > > 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?) Yeap, I want to gets rid of any reference to POSIX interfaces, as I am writing code shared between windows and linux or even more platforms(with or without posix support=EF=BC=89, And I am implementing timespec_get in me= sa code base to avoid waiting c23 or future c2x to be implemented by c standard library provider, currently for mesa's special usage, We need access to CLOCK_REALTIME CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW, so the equivalent TIME_UTC, TIME_MONOTONIC, TIME_MONOTONIC_RAW in Cx standard is good. > > 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 :: > :: ::::::::::::::: gsm international : +49 15737185122 :: > :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: -- =E6=AD=A4=E8=87=B4 =E7=A4=BC =E7=BD=97=E5=8B=87=E5=88=9A Yours sincerely, Yonggang Luo --000000000000a9a14605edd607e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 19, 2022 at 10:33 PM J=E2=82=91=E2=82= =99=E2=82=9B Gustedt <jens.gust= edt@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(Yonggang Luo)
> <l= uoyonggang@gmail.com>) wrote:
>
> > There is a concep= t 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
> > =C2=A0TIME_MONOTONIC with
> > CLOC= K_MONOTONIC_RAW =C2=A0on Linux?
>
> I am not completely sure wh= at you are asking. C2x was the short name
> for C23 when we did not y= et know that it will come out in 2023.
>
> C23 indeed adds thre= e *optional* time bases `TIME_MONOTONIC`,
> `TIME_ACTIVE` and `TIME_T= HREAD_ACTIVE` which are modeled after the
> POSIX clocks `CLOCK_MONOT= ONIC`, `CLOCK_PROCESS_CPUTIME_ID` and
> `CLOCK_THREAD_CPUTIME_ID`, re= spectively. 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
> e= quivalent to all POSIX clocks that it interfaces. Currently these are
&g= t;
> #define CLOCK_REALTIME =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0
&= gt; #define CLOCK_MONOTONIC =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01
> #de= fine CLOCK_PROCESS_CPUTIME_ID 2
> #define CLOCK_THREAD_CPUTIME_ID =C2= =A03
> #define CLOCK_MONOTONIC_RAW =C2=A0 =C2=A0 =C2=A04
> #def= ine CLOCK_REALTIME_COARSE =C2=A0 =C2=A05
> #define CLOCK_MONOTONIC_CO= ARSE =C2=A0 6
> #define CLOCK_BOOTTIME =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 7
> #define CLOCK_REALTIME_ALARM =C2=A0 =C2=A0 8
> #defi= ne CLOCK_BOOTTIME_ALARM =C2=A0 =C2=A0 9
> #define CLOCK_SGI_CYCLE =C2= =A0 =C2=A0 =C2=A0 =C2=A0 10
> #define CLOCK_TAI =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
>
> 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_REALTIME+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 TI= ME_UTC_COARSE =C2=A0 =C2=A0 =C2=A0 (CLOCK_REALTIME_COARSE+1)
> #defin= e TIME_MONOTONIC_COARSE (CLOCK_MONOTONIC_COARSE+1)
> #define TIME_BOO= TTIME =C2=A0 =C2=A0 =C2=A0 =C2=A0 (CLOCK_BOOTTIME+1)
> #define TIME_U= TC_ALARM =C2=A0 =C2=A0 =C2=A0 =C2=A0(CLOCK_REALTIME_ALARM+1)
> #defin= e TIME_BOOTTIME_ALARM =C2=A0 (CLOCK_BOOTTIME_ALARM+1)
> #define TIME_= SGI_CYCLE =C2=A0 =C2=A0 =C2=A0 =C2=A0(CLOCK_SGI_CYCLE+1)
> #define TI= ME_TAI =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(CLOCK_TAI+1)
I like this list, as It doesn't have to be implemented, have such a co= mplete list in C2x standard is very good

>
> and then adapt= ing `timespec_get` a bit. This would be conforming to
> current and f= uture C, because the `TIME_` prefix is already reserved
> for that pu= rpose.
>
> Unfortunately the choice of the values is an ABI cho= ice, 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 at
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949= ff70a47c47795fe9161a7514173b5be24/src/vulkan/runtime/vk_device.c#L557> >
> > May intention is using C2x timespec_get
> &g= t; to replace function
> > vk_clock_gettime but it's lack of = =C2=A0TIME_MONOTONIC_RAW, so I don't know
> > what's the b= est way
>
> I am not sure why you'd want to do this, are yo= u trying to port that
> code such that it gets rid of any reference t= o 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?)
Yeap, I want to gets rid of any reference to POSIX interfaces, as I am wr= iting code shared between windows and linux or even more =C2=A0platforms(wi= th or without posix support=EF=BC=89, And I am implementing timespec_get in= mesa code base to avoid waiting c23 or future c2x to be implemented by c s= tandard library provider, currently for mesa's special usage, We need a= ccess to =C2=A0CLOCK_REALTIME =C2=A0CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW= , so the equivalent TIME_UTC, TIME_MONOTONIC, TIME_MONOTONIC_RAW in Cx stan= dard is good.

>
> Then to know if a fallback to `CLOCK_MONO= TONIC_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 ::
> ::= ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.= unistra.fr/index.php/Jens_Gustedt ::



--
=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
--000000000000a9a14605edd607e0--