Received-SPF: pass (google.com: domain of linux-kernel+bounces-111280-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Fri, 22 Mar 2024 10:18:02 +0000
In-Reply-To: <2ecf6529-5408-4621-becc-2f30e1039079@proton.me>
Precedence: bulk
Mime-Version: 1.0
References: <2ecf6529-5408-4621-becc-2f30e1039079@proton.me>
Message-ID: <20240322101803.400735-1-aliceryhl@google.com>
Subject: Re: [PATCH v2] rust: time: add Ktime
From: Alice Ryhl <aliceryhl@google.com>
To: benno.lossin@proton.me
Cc: a.hindborg@samsung.com, alex.gaynor@gmail.com, aliceryhl@google.com, 
	bjorn3_gh@protonmail.com, boqun.feng@gmail.com, gary@garyguo.net, 
	jstultz@google.com, linux-kernel@vger.kernel.org, ojeda@kernel.org, 
	rust-for-linux@vger.kernel.org, sboyd@kernel.org, tglx@linutronix.de, 
	wedsonaf@gmail.com
Content-Type: text/plain; charset="utf-8"

Benno Lossin <benno.lossin@proton.me> wrote:
> On 3/22/24 09:59, Alice Ryhl wrote:
>> +/// Returns the number of milliseconds between two ktimes.
>> +#[inline]
>> +pub fn ktime_ms_delta(later: Ktime, earlier: Ktime) -> i64 {
>> +    (later - earlier).to_ms()
>> +}
> 
> Is there a reason for this function being standalone?

I think for a Rust time API, we should make one of two choices:

* Match the C ktime_t API as closely as possible.
* Match the Rust standard library std::time API as closely as possible.

This patchset has made the former choice, and that is why I went with
this design.

In the future it could make sense to add a more "Rusty" API, but even
then I think it could make sense to have both and implement the latter
in terms of the former. That way, only the API that closely matches the
C ktime_t API needs to concern itself with unsafely calling into C.

Alice