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
|
[[!meta copyright="Copyright © 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]]."]]"""]]
The *mapped-time interface*, that is, a `mmap`able read-only memory page
containing a `struct mapped_time_value`. See the [[reference_manual]].
Typically available as `/dev/time`, [[hurd/translator/storeio]].
Using that, [[hurd/libshouldbeinlibc]]'s `<maptime.h>` provides `maptime_map`
and `maptime_read`, see the [[hurd/reference_manual]]. Candidate for
replacement with [[open_issues/vDSO]] code?
# IRC, freenode, #hurd, 2013-11-20
<teythoon> braunr: about the mach device interface, if i open a device, and
then create a memory mapping using device_map, does that increment the
open count of the device ?
<teythoon> can i call device_close w/o destroying the mapping directly
after mapping it ?
<antrik> teythoon: I have a vague recollection that the mapping (or more
precisely, the memory object) is not bound to the open once
established... but don't take my word on it -- it's been some years since
I played with that stuff :-)
<teythoon> antrik: yes, that would actually match my expectation
<braunr> hum
<braunr> normally, mapping increments the usage count of the resource
mapped, but not the open count
<braunr> i don't know if that's the case for mach devices
<braunr> teythoon: which mach device btw ?
<teythoon> time
<teythoon> libshouldbeinlibc/maptime.c line ~53
<teythoon> the device is opened but never closed
<braunr> is that a problem ?
<teythoon> not sure, but I'd think so, yes
<braunr> why ?
<teythoon> the open count is incremented each time
<braunr> at map time ?
<braunr> ah no, since that's your question
<braunr> the open count is normally decremented when the send right for the
device is destroyed, which occurs when tasks exit
<teythoon> hm
<teythoon> but wouldn't only important long running servers use the mach
device ?
<braunr> all tasks do
<braunr> a simple call to gettimeofday will use it
<teythoon> well, but only privileged processes may get teh device master
port
<braunr> the device is probably accessible through some other method
<teythoon> yes. /dev/time
<teythoon> err, have you looked at the function ? ;)
<braunr> no
<braunr> which one ?
<teythoon> maptime_map
<braunr> i did once but quickly
<teythoon> if use_mach_dev, the mach device is used, /dev/time otherwise
<braunr> gettimeofday apparently uses __host_get_time
<braunr> mhmm
<braunr> ok so i was wrong
<braunr> the time device, whether it is the mach or the hurd one, seems to
be mapped only by translators
<braunr> 14:10 < teythoon> but wouldn't only important long running servers
use the mach device ?
<braunr> so yes :)
<teythoon> so we should close the device
<braunr> why ?
<teythoon> to prevent an overflow in the open count
<braunr> when is it open multiple times ?
<teythoon> isn't it ? maybe /me lacks some context ;)
<braunr> it's called once at init time
<teythoon> well, ok then
<braunr> gettimeofday-like functions then only read the mapped memory
<braunr> at least, that's how it's done in the servers i've looked at such
as pfinet
<teythoon> makes sense, yes
<braunr> something i learnt from experience and failures: check the problem
actually exists before fixing it :p
<teythoon> well, if the memory mapping is independent of the device, then
there is a problem
<teythoon> the device is kept open for no reason
<braunr> teythoon: if you can determine that the device doesn't need to
stay open for the mapping to remain, then you can close it
<braunr> otherwise, it's such a minor leak that we don't care at all
<braunr> i wouldn't even consider it a leak more than a small static
variable used at init time only
<teythoon> looks like, yes
<teythoon> also, it's only in the rootfs translator
<braunr> ?
<teythoon> only the root filesystem uses the mach device directly
<braunr> ok
<braunr> well, /dev/time too right ?
<teythoon> yes, but that is a storeio translator that does not use this
code
<braunr> yes
<braunr> hm
<teythoon> only the root filesystem uses the mach device directly *using
this function*
|
