On Sat, Apr 29, 2023 at 7:39 AM Flávio Cruz <flavioc...@gmail.com> wrote: > This never happened to me. Probably because I don't have NTP installed > in my Hurd box?
That might explain it :) But I can't be the only one who wants their Hurd VM to have a sane notion of the current time across suspend-wake cycles of the host machine , can I? >> Since we have already broken ABI compatibility with the time device on >> other Mach versions (if it ever existed) by adding the *64 variants to >> the struct mapped_time_value, maybe we could just place the >> clock_boottime_offset into the same struct? Then the userspace would >> be able to pick it up and use it to calculate the boottime-relative >> time. > > User land can still use the old time structures but can now be updated to > read the > *64 variants. Yes; what I mean is that they can't use the new data unconditionally, since they could be running on older GNU Mach, or theoretically on some non-GNU Mach (although that would not work anymore for many other reasons). > I think the approach makes sense to me. We can update the > clock_boottime_offset > in the structure whenever it is updated by the kernel and then provide a > maptime_read(clockid_t clock, struct mapped_time_value *mtime, struct timeval > *tv) > routine to read from the mapped memory and return either a time using > CLOCK_REALTIME > or CLOCK_MONOTONIC semantics. But we cannot just change the signature of maptime_read like that because we haven't been versioning the symbols. (Which we should really start doing: as the old saying goes, the best time to start versioning your symbols was when you first wrote your shared library; the second best time is now.) It'd have to be a separate function, perhaps maptime_read_clock or maptime_clockread. > We could also have an RPC host_get_time that is parameterized by clockid_t to > have some > symmetry with the routine above. Do we really have a concept of clockid in the kernel? Sergey
