[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mach time device, or: I know why the network deadlocks!
From: |
Sergey Bugaev |
Subject: |
Re: Mach time device, or: I know why the network deadlocks! |
Date: |
Sat, 29 Apr 2023 17:01:44 +0300 |
On Sat, Apr 29, 2023 at 7:39 AM Flávio Cruz <flaviocruz@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