Tuned and applied, thanks! Zhaoming Luo, le mar. 14 janv. 2025 09:50:01 +0800, a ecrit: > The clock_gettime(CLOCK_MONOTONIC) is implemented. See > > https://sourceware.org/git?p=glibc.git;a=commit;h=3782ffaf3e6c2a071df029b96712e596b5229838 > > so this page is out of date. > > Rename the page to nanosecond-precision_clock, and remove the > information about clock_gettime(CLOCK_MONOTONIC). > --- > open_issues/clock_gettime.mdwn | 345 -------------------- > open_issues/nanosecond-precision_clock.mdwn | 56 ++++ > 2 files changed, 56 insertions(+), 345 deletions(-) > delete mode 100644 open_issues/clock_gettime.mdwn > create mode 100644 open_issues/nanosecond-precision_clock.mdwn > > diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn > deleted file mode 100644 > index 6f2ad6fd..00000000 > --- a/open_issues/clock_gettime.mdwn > +++ /dev/null > @@ -1,345 +0,0 @@ > -[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation, > -Inc."]] > - > -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable > -id="license" text="Permission is granted to copy, distribute and/or modify > this > -document under the terms of the GNU Free Documentation License, Version 1.2 > or > -any later version published by the Free Software Foundation; with no > Invariant > -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the > license > -is included in the section entitled [[GNU Free Documentation > -License|/fdl]]."]]"""]] > - > -[[!meta title="clock_gettime"]] > - > -[[!tag open_issue_glibc open_issue_gnumach]] > - > -Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) > - > -It could be a mere matter of extending the > -[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]: > -add it to > -`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, > and > -make `clock_gettime` use it. > - > -What about adding a nanosecond-precision clock, too? --[[tschwinge]] > - > - > -# IRC, freenode, #hurd, 2011-08-26 > - > - < pinotree> youpi: thing is: apparently i found a simple way to have a > - monotonic clock as mmap-able device inside gnumach > - < pinotree> currently, in kern/mach_clock.c there's a variable 'time', > - which gets increased on clock interrupt, and optionally modified by > - host_set_time > - < pinotree> () > - < pinotree> if i add a new variable next to it, only increasing it on > - interrupt but not modifying it at all otherwise, would that give me a > - monotonic clock? > - < pinotree> at least on sme basic tests i did, it seems it could work > that > - way > - < youpi> yes, it should work > - < braunr> sure > - < youpi> and that's the way I was considering implementing it > - > - > -# IRC, freenode, #hurd, 2011-09-06 > - > - <pinotree> yeah, i had a draft of improved idea for also handling > - nanoseconds > - <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well. > - <tschwinge> pinotree, youpi: This memory page is all-zero by default, > - right? > - <tschwinge> Can't we then say that its last int is a version code, and if > - it is 0 (as it is now), we only have the normal mapped time field, if > it > - is 1, we also have the monotonic cliock and ns precision on address 8 > and > - 16 (or whatever)? > - <tschwinge> In case that isn't your plan anyway. > - <youpi> it's all-zero, yes > - <tschwinge> Or, we say if a field is != 0 it is valid. > - <youpi> making the last int a version code limits the size to one page > - <youpi> I was thinking a field != 0 being valid is simpler > - <youpi> but it's probably a problem too > - <youpi> in that glibc usually caches whether interfaces are supported > - <tschwinge> Wrap-around? > - <youpi> for some clocks, it may be valid that the value is 0 > - <youpi> wrap-around is another issue too > - <tschwinge> Well, then we can do the version-field thing, but put it > right > - after the current time field (address 8, I think)? > - <youpi> yes > - <youpi> it's a bit ugly, but it's hidden behind the structure > - <tschwinge> It's not too bad, I think. > - <youpi> yes > - <tschwinge> And it will forever be a witness of the evolving of this > - map_time interface. :-) > - > - > -# IRC, freenode, #hurd, 2013-02-11 > - > -In context of [[select]]. > - > - <pinotree> braunr: would you send for review (and inclusion) your > - time_data_t addition? > - <pinotree> this way we could add nanosecs-based utime rpc (and then their > - implementation in libc) > - <braunr> pinotree: it's part of the hurd branch > - <braunr> do you want it sent separately ? > - <pinotree> yeah > - <braunr> ok > - <braunr> let me get it right first :) > - <pinotree> sure :) > - > - > -## IRC, freenode, #hurd, 2013-02-12 > - > - <braunr> pinotree: > - > https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a > - <pinotree> uh nice > - <pinotree> will need two small inline functions to convert time_data_t > <-> > - timespec, but that's it > - <braunr> hm right > - <braunr> i could have thought about it > - <braunr> but i'll leave it for another patch :p > - <pinotree> oh sure, no hurry > - > - > -## IRC, freenode, #hurd, 2013-02-19 > - > - <youpi> braunr: about time_data_t, I get it's needed that it be an array > - <youpi> so it can be passed by reference, not by value? > - <braunr> by address, yes > - <braunr> that's the difference between array and struct > - > - > -## IRC, freenode, #hurd, 2013-02-25 > - > - <youpi> braunr: why did you want to see time_data passed as pointer, not > as > - struct? > - <braunr> to microoptimize > - <braunr> the struct is 2 64-bit integers > - <youpi> well, we already pass structs along in a few cases, > - e.g. io_statbuf_t, rusage_t, etc. > - <youpi> be it written t[0].sec or t->sec, it seems odd > - <youpi> copying 2 64bit integers is not much compared to the potential > for > - bugs here > - <braunr> bugs ? > - <youpi> yes, as in trying to access t[1], passing a wrong pointer, etc. > - <youpi> or the reader frowning on "why is this case different than the > - others?" > - <braunr> well, i'm already usually frowning when i see what mig does .. > - <youpi> right > - <youpi> on the plus side, it's only the client side, i.e. mostly glibc, > - which sees the t[0] > - <braunr> and the practice established by my patch is to convert to struct > - timespec as soon as possible > - <braunr> the direct use of this type is therefore limited > - <youpi> could we define time_data_t as a struct time_data * instead of > - struct time_data[1] ? > - <youpi> (in the.h) > - <youpi> that would make more sense to define a struct time_data, and > pass a > - pointer to it > - <braunr> i'm not sure > - <braunr> the mach server writing guide was very clear about array > implying > - a C array too > - <braunr> and i remember having compilation problems before doing that > - <braunr> but i don't remember their nature exactly > - <youpi> I'm not sure to understand what you said about converting to > struct > - timespec > - <youpi> what makes it not possible now? > - <youpi> and what is the relation with being an array or a pointer? > - <braunr> concerning struct timespec, what i mean is that the functions > - called by the mig stub code directly convert time_data_t to a struct > - timespec (which is the real type used throughout the hurd code) > - <braunr> about the rest, i'm not sure, i'd have to try again > - <braunr> mig just assumes it's an array > - <youpi> and why not just using struct timespec? > - <youpi> (for the mig type too) > - <braunr> my brain can't correctly compute variable sized types in mig > - definition files > - <braunr> i wanted something that would remain correct for the 64-bit port > - > -[[64-bit_port]], [[mig_portable_rpc_declarations]]. > - > - <youpi> ah, you mean because tv_nsec is a long, which will not be the > same > - type? > - <braunr> and tv_sec being a time_t (thus a long too) > - <youpi> but we have the same issue e.g. for the rusage structure, don't > we? > - <braunr> yes > - <youpi> so we'll have to fix things for that too anyway > - <braunr> sure > - <youpi> making a special case will not necessarily help > - <braunr> but it doesn't mean new interfaces have to be buggy too > - <youpi> well, using the proper type in the server itself is nicer > - <youpi> instead of having to convert > - <braunr> yes > - <braunr> i'm not exactly sure where to declare struct timespec then > - <braunr> should it be declared in hurd_types.h, and simply reused by the > - libc headers ? > - <youpi> ? AIUI, it's the converse, hurd_types.h uses the struct timespec > - from libc headers, and defines timespec_t > - <braunr> ok > - <youpi> timespec_t being the internal type whose definition gets done > right > - for mig to do the right thing > - <braunr> yes > - <braunr> i see > - <braunr> so, you'd like a struct of integer_t instead of an array of > - signed64 > - <youpi> for our current 32bit userland yes > - <braunr> do you want to make the changes yourself or should i add a new > - branch ? > - <youpi> and we'll make that a 64bit struct when we have a64bit userland > - > - > -# IRC, freenode, #hurd, 2013-04-06 > - > - <tschwinge> pinotree: You had once been working on adding nsec-procision > - timestamps to GNU Mach's maptime interface (or what the name is). Is > - that blocked on something or just waiting to be continued? > - <pinotree> blocked on me needing to learn more the proper way to do > - "atomic" update of the struct with time :) > - > - > -# IRC, freenode, #hurd, 2013-09-04 > - > - <teythoon> do we have CLOCK_MONOTONIC ? > - <braunr> teythoon: i think we do but it's actually a simple offset from > - CLOCK_REALTIME .. :) > - <teythoon> ah never mind, I do hate this posix time interface anyways > - <braunr> really ? > - <braunr> i think librt is decent > - > - > -# Candidate for [[vDSO]] code? > - > - > -# IRC, freenode, #hurd, 2014-02-23 > - > - <desrt> GLib (gthread-posix.c): Unexpected error from C library during > - 'pthread_condattr_setclock': Invalid argument. Aborting. > - <desrt> uh oh... > - <desrt> time to go digging in glibc i guess... > - <braunr> what are you trying to run ? > - <desrt> glib > - <braunr> with what ? > - <desrt> just running glib's test suite under jhbuild > - <desrt> i maintain glib and i made some changes recently -- i wanted to > - make sure they didn't break the hurd > - <desrt> and it seems they have ;/ > - <braunr> well > - <braunr> the hurd doesn't completely comply with posix 2008 > - <desrt> long story short: we've keyed our timed waits on condition > - variables to the monotonic clock for a long time now, but we never > tested > - that it actually worked > - <desrt> so i just added an assert -- and indeed it fails on hurd > - <braunr> our glibc lies about supporting timers > - <braunr> good thinking > - <braunr> we don't support the monotonic clock > - <desrt> clock_gettime(CLOCK_MONOTONIC) seems to work > - <braunr> and you should know that, even if clock selection and timers are > - available (which posix 2008 requires), it's still optional > - <braunr> no, glibc lies > - <desrt> !! > - <braunr> our "support" is a mere hack shifting CLOCK_REALTIME > - <desrt> it should at least lie consistently :) > - <braunr> we need to implement CLOCK_MONOTONIC properly > - <desrt> ya... that would be very nice indeed > - <braunr> not that hard either > - <desrt> i agree! > - <braunr> we just have to do it right > - <desrt> fwiw, i plan to keep this assert in glib > - <braunr> yes, it's good > - <desrt> is there anywhere i can file a bug to give you guys some advance > - warning? > - <braunr> i don't think it's needed > - <braunr> we know the problem > - <desrt> k -- consider yourself warned, then :) > - <braunr> and it's been a bigger concern recently > - <desrt> awesome. glad i don't have to do anything :) > - <braunr> if it's not already done, i suggest you check for the > - CLOCK_MONOTONIC option > - <desrt> fwiw, i'm trying to get a regular debian/gnu/hurd build of > - glib/gtk/etc setup > - <braunr> regular ? > - <desrt> ya... out of git master on a daily basis > - <braunr> from sources ? > - <braunr> oh nice > - <desrt> we recently set this up for freebsd as well > - <braunr> few maintainers take the pain :) > - <desrt> our non-linux 'problem discovery' is a bit crap before now :/ > - <braunr> i guess that's pretty normal > - <braunr> i don't consider it the responsibility of the maintainers to > test > - every possible platform > - <desrt> glib is a bit unique -- portability is our business > - <braunr> taking our patches into consideration is what we ask most > - <braunr> right > - <desrt> and the "please take the patches" thing is something we want to > - stop doing > - <braunr> why ? > - <desrt> mostly because we often look at a patch that someone sent a few > - years ago and say "do we even still need this?" > - <desrt> and have no way to know > - <braunr> uh > - <desrt> you would not believe how many patches like this we've > - accumulated... > - <braunr> but if we send it now ? :) > - <desrt> braunr: new policy is roughly this: > - https://wiki.gnome.org/Projects/GLib/SupportedPlatforms > - <desrt> ie: fixes for issues that are general portability improvements > and > - POSIX compliance are welcome... > - <desrt> patches that introduce platform-specific #ifdef sections are > - rejected unless we have a regular builder to test that code > - <braunr> i see > - <braunr> again, regarding portability, don't consider CLOCK_MONOTONIC to > be > - readily available, check for it > - <braunr> an #error would be enough but it has to be checked > - <desrt> it basically comes down to: we don't want to have code in our > - version control that we have no possible way of testing > - <braunr> yes > - <desrt> braunr: we do check for it > - <braunr> ok > - <desrt> we assert() if clock_gettime(CLOCK_MONOTONIC) fails > - <braunr> no i mean > - <desrt> as POSIX said it should if CLOCK_MONOTONIC is not supported > - <desrt> if you lie to us.... well, not much we can do > - <braunr> POSIX_MONOTONIC_CLOCK > - <braunr> _POSIX_MONOTONIC_CLOCK > - <desrt> this is actually defined to 0 on most platforms... > - <desrt> which does not mean that it's unsupported -- it means that the > - runtime must be ready to deal with it not actually existing at runtime > - <braunr> really ? > - <desrt> yes > - <desrt> we used to rely on this and got a bug that we were doing it wrong > - :) > - <desrt> and indeed, even on linux, both with glibc and uclibc: > - <desrt> /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK > - 0 > - <desrt> /usr/include/uClibc/bits/posix_opt.h:#define > _POSIX_MONOTONIC_CLOCK > - 0 > - <braunr> ok it's described in 2.1.6 Options > - <braunr> so your check is appropriate > - <desrt> so does clock_gettime(MONOTONIC) on debian/hurd get me realtime? > - <braunr> either that, or a value shifted from it > - <desrt> if so, i'll just hack out the condattr_setclock() check and > proceed > - trying to build past glib... > - * desrt checks > - <desrt> as it is, even the build of glib fails since we use some tools > - linked against ourselves during the build process... > - <desrt> 1393124084790000 1393124084790000 > - <desrt> those look the same.... > - <braunr> heh > - <desrt> i also notice that your clocks are not very high precision :) > - <braunr> that's right > - <desrt> HZ = 100, i guess > - <braunr> yes > - <desrt> fair enough > - <desrt> our mainloop doesn't support better-than-millisecond accuracy yet > - anyway :) > - <desrt> (although it will soon...) > - <braunr> nice > - > - > -## IRC, freenode, #hurd, 2014-03-05 > - > - <desrt> braunr: bit of a warning: i released the glib that depends on > - working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it > - will be landing in debian within the next days > - <braunr> desrt: ok > diff --git a/open_issues/nanosecond-precision_clock.mdwn > b/open_issues/nanosecond-precision_clock.mdwn > new file mode 100644 > index 00000000..e71e1558 > --- /dev/null > +++ b/open_issues/nanosecond-precision_clock.mdwn > @@ -0,0 +1,56 @@ > +[[!meta copyright="Copyright © 2011, 2013, 2014, 2025 Free Software > Foundation, > +Inc."]] > + > +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable > +id="license" text="Permission is granted to copy, distribute and/or modify > this > +document under the terms of the GNU Free Documentation License, Version 1.2 > or > +any later version published by the Free Software Foundation; with no > Invariant > +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the > license > +is included in the section entitled [[GNU Free Documentation > +License|/fdl]]."]]"""]] > + > +[[!meta title="a nanosecond-precision clock"]] > + > +[[!tag open_issue_glibc open_issue_gnumach]] > + > +What about adding a nanosecond-precision clock, too? --[[tschwinge]] > + > +# IRC, freenode, #hurd, 2011-09-06 > + > + <pinotree> yeah, i had a draft of improved idea for also handling > + nanoseconds > + <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well. > + <tschwinge> pinotree, youpi: This memory page is all-zero by default, > + right? > + <tschwinge> Can't we then say that its last int is a version code, and if > + it is 0 (as it is now), we only have the normal mapped time field, if > it > + is 1, we also have the monotonic cliock and ns precision on address 8 > and > + 16 (or whatever)? > + <tschwinge> In case that isn't your plan anyway. > + <youpi> it's all-zero, yes > + <tschwinge> Or, we say if a field is != 0 it is valid. > + <youpi> making the last int a version code limits the size to one page > + <youpi> I was thinking a field != 0 being valid is simpler > + <youpi> but it's probably a problem too > + <youpi> in that glibc usually caches whether interfaces are supported > + <tschwinge> Wrap-around? > + <youpi> for some clocks, it may be valid that the value is 0 > + <youpi> wrap-around is another issue too > + <tschwinge> Well, then we can do the version-field thing, but put it > right > + after the current time field (address 8, I think)? > + <youpi> yes > + <youpi> it's a bit ugly, but it's hidden behind the structure > + <tschwinge> It's not too bad, I think. > + <youpi> yes > + <tschwinge> And it will forever be a witness of the evolving of this > + map_time interface. :-) > + > +# IRC, freenode, #hurd, 2013-04-06 > + > + <tschwinge> pinotree: You had once been working on adding nsec-procision > + timestamps to GNU Mach's maptime interface (or what the name is). Is > + that blocked on something or just waiting to be continued? > + <pinotree> blocked on me needing to learn more the proper way to do > + "atomic" update of the struct with time :) > + > +# Candidate for [[vDSO]] code? > -- > 2.47.1 > >
-- Samuel Battery 1: charging, 90%, charging at zero rate - will never fully charge. -+- acpi - et pourtant, ca monte -+-
