1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
[[!meta copyright="Copyright © 2011, 2013 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.
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[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
<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 :)
# Candidate for [[vDSO]] code?
|
