bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]