Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Nov 2022 01:19:40 +0800
From: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com, Jason Ekstrand <jason@...kstrand.net>
Subject: Re: C23 implications for C libraries

On Sat, Nov 19, 2022 at 10:33 PM Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> wrote:
>
> 罗勇刚,
>
> on Sat, 19 Nov 2022 04:46:22 +0800 you (罗勇刚(Yonggang Luo)
> <luoyonggang@...il.com>) 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/c6c5949ff70a47c47795fe9161a7514173b5be24/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), And I am implementing timespec_get in mesa 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ₑₙₛ
>
> --
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: :::::::::::::::::::::: gsm France : +33 651400183   ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.