clock_gettime(CLOCK_MONOTONIC) (e.g. for iceweasel)
It could be a mere matter of extending the
add it to
mapped_time_value_t in gnumach, handle it in
clock_gettime use it.
BTW, also make
gettimeofday() use it, since it's way more efficient and some
applications assume that it is.
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: http://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.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, 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 <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 ? <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 <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 :)