[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach time device, or: I know why the network deadlocks!

From: Samuel Thibault
Subject: Re: Mach time device, or: I know why the network deadlocks!
Date: Sun, 7 May 2023 22:24:57 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev, le sam. 29 avril 2023 17:01:44 +0300, a ecrit:
> On Sat, Apr 29, 2023 at 7:39 AM Flávio Cruz <flaviocruz@gmail.com> wrote:
> > 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 
> > or CLOCK_MONOTONIC semantics.
> But we cannot just change the signature of maptime_read like that
> because we haven't been versioning the symbols.

>  It'd have to be a separate function,
> perhaps maptime_read_clock or maptime_clockread.

Yes. To align on posix naming that'd rather be 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?

We probably need to introduce it anyway, since that's where the precise
details can be managed.


reply via email to

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