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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21311 invoked from network); 19 Nov 2022 14:34:09 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Nov 2022 14:34:09 -0000 Received: (qmail 28310 invoked by uid 550); 19 Nov 2022 14:34: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 28278 invoked from network); 19 Nov 2022 14:34:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=NOeRSSlVowk2TembfOnRq4Gyqe1jDDh7IBs38TyOkBE=; b=DjRUZqfCjQ16olcU7w7cpCJUTAc/b8g1fEP1JOgqbNTlIupkJTsGWDHv rHIGFJZV2Z1sbGjtJ6K+rG1I+/kU5cCDt0SdpfeRIDzoN8rhk9JzZL3tL zwvOtCcGYfxS9dVVfRIeWoHzZu2LNh0PNwqWRFWBIrfv5ynAL0eqr93BT c=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="5.96,176,1665439200"; d="scan'208";a="79075513" Date: Sat, 19 Nov 2022 15:33:50 +0100 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: "=?UTF-8?B?572X5YuH5Yia?=(Yonggang Luo)" Cc: musl@lists.openwall.com, Jason Ekstrand Message-ID: <20221119153350.292e390b@inria.fr> In-Reply-To: References: <20220923162518.56284329@inria.fr> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/sUasA7oRbNQ5GMU8jzgNbNF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] C23 implications for C libraries --Sig_/sUasA7oRbNQ5GMU8jzgNbNF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =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) ) 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. 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 >=20 > https://gitlab.freedesktop.org/mesa/mesa/-/blob/c6c5949ff70a47c47795fe916= 1a7514173b5be24/src/vulkan/runtime/vk_device.c#L557 >=20 > 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 --=20 :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/sUasA7oRbNQ5GMU8jzgNbNF Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCY3jpTgAKCRAP0+hp2tU3 4noNAJ9uE3TmOu4vYhF3DROoKfqtOx3o2ACgjmeG+GfEYyfUZ60yJzEW307Ny/8= =qUGB -----END PGP SIGNATURE----- --Sig_/sUasA7oRbNQ5GMU8jzgNbNF--