Re: [PATCH] rust: time: add Ktime

[Boqun Feng]

On Fri, Mar 22, 2024 at 08:50:18AM +0100, Alice Ryhl wrote:
> On Wed, Mar 20, 2024 at 4:30 PM Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On Wed, Mar 20, 2024 at 10:08:45AM +0000, Alice Ryhl wrote:
> > > Introduce a wrapper around `ktime_t` with a few different useful
> > > methods.
> > >
> > > Rust Binder will use these bindings to compute how many milliseconds a
> > > transaction has been active for when dumping the current state of the
> > > Binder driver. This replicates the logic in C Binder [1].
> > >
> >
> > I wonder whether Lina's previous patch also works for your case?
> >
> >         https://lore.kernel.org/rust-for-linux/20230714-rust-time-v2-1-f5aed84218c4@xxxxxxxxxxxxx/
> >
> > You don't need to implement all the `Clock`s since you only need
> > MONOTONIC time. But maybe `Duration::as_nanos` and `Duration::as_millis`
> > return `u128` is problematic?
> 
> It would work for me too, but adds more than what I need. As for
> `u128`, I don't really know what the status on that is. I need to be
> able to print it as a base-10 integer.
> 
> Adding an API with separate types that distinguish between Instant and
> Duration and different clock sources so that you don't mix them up is
> reasonable, but a bit overkill for my needs. I am spending enough API
> design cycles on my uaccess, file, and linked list patchsets. Someone

I totally understand that! But the requirement was brought up a while
ago by Thomas:

	https://lore.kernel.org/rust-for-linux/87h6vfnh0f.ffs@tglx/

> else can submit patches to add a more well-typed time API in the
> future.
> 

Would it work, if I create a new patch based on yours? The work for me
won't be too much since you, Lina and Heghedus already did the hard work
along with some feedback from Thomas.

Regards,
Boqun

> Alice