The mapped-time interface, that is, a mmapable read-only memory page containing a struct mapped_time_value. See the reference manual.

Typically available as /dev/time, storeio.

Using that, ?libshouldbeinlibc's <maptime.h> provides maptime_map and maptime_read, see the reference manual. Candidate for replacement with 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*