Add new sections for DELAY/SLEEP and TIMEKEEPING abstractions
respectively. It was possible to include both abstractions in a single
section, but following precedent, two sections were created to
correspond with the entries for the C language APIs.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
MAINTAINERS | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c8d9e8187eb0..775ea845f011 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10355,6 +10355,13 @@ F: kernel/time/timer_list.c
F: kernel/time/timer_migration.*
F: tools/testing/selftests/timers/
+DELAY AND SLEEP API [RUST]
+M: FUJITA Tomonori <fujita.tomonori@gmail.com>
+L: rust-for-linux@vger.kernel.org
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: rust/kernel/time/delay.rs
+
HIGH-SPEED SCC DRIVER FOR AX.25
L: linux-hams@vger.kernel.org
S: Orphan
@@ -23854,6 +23861,13 @@ F: kernel/time/timekeeping*
F: kernel/time/time_test.c
F: tools/testing/selftests/timers/
+TIMEKEEPING API [RUST]
+M: FUJITA Tomonori <fujita.tomonori@gmail.com>
+L: rust-for-linux@vger.kernel.org
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: rust/kernel/time.rs
+
TIPC NETWORK LAYER
M: Jon Maloy <jmaloy@redhat.com>
L: netdev@vger.kernel.org (core kernel code)
--
2.43.0Hi Tomo, On Thu, Feb 20, 2025 at 04:06:08PM +0900, FUJITA Tomonori wrote: > Add new sections for DELAY/SLEEP and TIMEKEEPING abstractions > respectively. It was possible to include both abstractions in a single > section, but following precedent, two sections were created to > correspond with the entries for the C language APIs. > Could you add me as a reviewer in these entries? Thanks! Regards, Boqun > Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> > --- > MAINTAINERS | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c8d9e8187eb0..775ea845f011 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10355,6 +10355,13 @@ F: kernel/time/timer_list.c > F: kernel/time/timer_migration.* > F: tools/testing/selftests/timers/ > > +DELAY AND SLEEP API [RUST] > +M: FUJITA Tomonori <fujita.tomonori@gmail.com> +R:Boqun Feng <boqun.feng@gmail.com> > +L: rust-for-linux@vger.kernel.org > +L: linux-kernel@vger.kernel.org > +S: Maintained > +F: rust/kernel/time/delay.rs > + > HIGH-SPEED SCC DRIVER FOR AX.25 > L: linux-hams@vger.kernel.org > S: Orphan > @@ -23854,6 +23861,13 @@ F: kernel/time/timekeeping* > F: kernel/time/time_test.c > F: tools/testing/selftests/timers/ > > +TIMEKEEPING API [RUST] > +M: FUJITA Tomonori <fujita.tomonori@gmail.com> +R:Boqun Feng <boqun.feng@gmail.com> > +L: rust-for-linux@vger.kernel.org > +L: linux-kernel@vger.kernel.org > +S: Maintained > +F: rust/kernel/time.rs > + > TIPC NETWORK LAYER > M: Jon Maloy <jmaloy@redhat.com> > L: netdev@vger.kernel.org (core kernel code) > -- > 2.43.0 > >
Boqun Feng <boqun.feng@gmail.com> writes: > Hi Tomo, > > On Thu, Feb 20, 2025 at 04:06:08PM +0900, FUJITA Tomonori wrote: >> Add new sections for DELAY/SLEEP and TIMEKEEPING abstractions >> respectively. It was possible to include both abstractions in a single >> section, but following precedent, two sections were created to >> correspond with the entries for the C language APIs. >> > > Could you add me as a reviewer in these entries? > I would like to be added as well. Best regards, Andreas Hindborg
On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote:
>> Could you add me as a reviewer in these entries?
>>
>
> I would like to be added as well.
Please add the relevant core code maintainers (Anna-Maria, Frederic,
John Stultz and myself) as well to the reviewers list, so that this does
not end up with changes going in opposite directions.
Thanks,
tglx
On Fri, Mar 21, 2025 at 09:38:46PM +0100, Thomas Gleixner wrote: > On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote: > >> Could you add me as a reviewer in these entries? > >> > > > > I would like to be added as well. > > Please add the relevant core code maintainers (Anna-Maria, Frederic, > John Stultz and myself) as well to the reviewers list, so that this does > not end up with changes going in opposite directions. > Make sense, I assume you want this to go via rust then (althought we would like it to go via your tree if possible ;-))? Regards, Boqun > Thanks, > > tglx
Thank you all! On Fri, 21 Mar 2025 14:00:52 -0700 Boqun Feng <boqun.feng@gmail.com> wrote: > On Fri, Mar 21, 2025 at 09:38:46PM +0100, Thomas Gleixner wrote: >> On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote: >> >> Could you add me as a reviewer in these entries? >> >> >> > >> > I would like to be added as well. >> >> Please add the relevant core code maintainers (Anna-Maria, Frederic, >> John Stultz and myself) as well to the reviewers list, so that this does >> not end up with changes going in opposite directions. >> > > Make sense, I assume you want this to go via rust then (althought we > would like it to go via your tree if possible ;-))? Once the following review regarding fsleep() is complete, I will submit patches #2 through #6 as v12 for rust-next: https://lore.kernel.org/linux-kernel/20250322.102449.895174336060649075.fujita.tomonori@gmail.com/ The updated MAINTAINERS file will look like the following. diff --git a/MAINTAINERS b/MAINTAINERS index cbf84690c495..858e0b34422f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10370,6 +10370,18 @@ F: kernel/time/timer_list.c F: kernel/time/timer_migration.* F: tools/testing/selftests/timers/ +DELAY AND SLEEP API [RUST] +M: FUJITA Tomonori <fujita.tomonori@gmail.com> +R: Boqun Feng <boqun.feng@gmail.com> +R: Andreas Hindborg <a.hindborg@kernel.org> +R: Anna-Maria Behnsen <anna-maria@linutronix.de> +R: Frederic Weisbecker <frederic@kernel.org> +R: Thomas Gleixner <tglx@linutronix.de> +L: rust-for-linux@vger.kernel.org +L: linux-kernel@vger.kernel.org +S: Maintained +F: rust/kernel/time/delay.rs + HIGH-SPEED SCC DRIVER FOR AX.25 L: linux-hams@vger.kernel.org S: Orphan @@ -23944,6 +23956,17 @@ F: kernel/time/timekeeping* F: kernel/time/time_test.c F: tools/testing/selftests/timers/ +TIMEKEEPING API [RUST] +M: FUJITA Tomonori <fujita.tomonori@gmail.com> +R: Boqun Feng <boqun.feng@gmail.com> +R: Andreas Hindborg <a.hindborg@kernel.org> +R: John Stultz <jstultz@google.com> +R: Thomas Gleixner <tglx@linutronix.de> +L: rust-for-linux@vger.kernel.org +L: linux-kernel@vger.kernel.org +S: Maintained +F: rust/kernel/time.rs + TIPC NETWORK LAYER M: Jon Maloy <jmaloy@redhat.com> L: netdev@vger.kernel.org (core kernel code)
On Sat, Mar 22, 2025 at 11:07:03AM +0900, FUJITA Tomonori wrote: > Thank you all! > > On Fri, 21 Mar 2025 14:00:52 -0700 > Boqun Feng <boqun.feng@gmail.com> wrote: > > > On Fri, Mar 21, 2025 at 09:38:46PM +0100, Thomas Gleixner wrote: > >> On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote: > >> >> Could you add me as a reviewer in these entries? > >> >> > >> > > >> > I would like to be added as well. > >> > >> Please add the relevant core code maintainers (Anna-Maria, Frederic, > >> John Stultz and myself) as well to the reviewers list, so that this does > >> not end up with changes going in opposite directions. > >> > > > > Make sense, I assume you want this to go via rust then (althought we > > would like it to go via your tree if possible ;-))? > Given Andreas is already preparing the pull request of the hrtimer abstraction to Miguel, and delay, timekeeping and hrtimer are related, these timekeeping/delay patches should go via Andreas (i.e. rust/hrtimer-next into rust/rust-next) if Thomas and Miguel are OK with it. Works for you, Andreas? If so... > Once the following review regarding fsleep() is complete, I will submit > patches #2 through #6 as v12 for rust-next: > > https://lore.kernel.org/linux-kernel/20250322.102449.895174336060649075.fujita.tomonori@gmail.com/ > > The updated MAINTAINERS file will look like the following. > > diff --git a/MAINTAINERS b/MAINTAINERS > index cbf84690c495..858e0b34422f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10370,6 +10370,18 @@ F: kernel/time/timer_list.c > F: kernel/time/timer_migration.* > F: tools/testing/selftests/timers/ > > +DELAY AND SLEEP API [RUST] > +M: FUJITA Tomonori <fujita.tomonori@gmail.com> > +R: Boqun Feng <boqun.feng@gmail.com> > +R: Andreas Hindborg <a.hindborg@kernel.org> ... this "R:" entry would be "M:", > +R: Anna-Maria Behnsen <anna-maria@linutronix.de> > +R: Frederic Weisbecker <frederic@kernel.org> > +R: Thomas Gleixner <tglx@linutronix.de> > +L: rust-for-linux@vger.kernel.org > +L: linux-kernel@vger.kernel.org +T: git https://github.com/Rust-for-Linux/linux.git hrtimer-next > +S: Maintained I will let Andreas decide whether this is a "Supported" entry ;-) > +F: rust/kernel/time/delay.rs > + > HIGH-SPEED SCC DRIVER FOR AX.25 > L: linux-hams@vger.kernel.org > S: Orphan > @@ -23944,6 +23956,17 @@ F: kernel/time/timekeeping* > F: kernel/time/time_test.c > F: tools/testing/selftests/timers/ > > +TIMEKEEPING API [RUST] and similar things for this entry as well. > +M: FUJITA Tomonori <fujita.tomonori@gmail.com> > +R: Boqun Feng <boqun.feng@gmail.com> > +R: Andreas Hindborg <a.hindborg@kernel.org> > +R: John Stultz <jstultz@google.com> > +R: Thomas Gleixner <tglx@linutronix.de> +R: Stephen Boyd <sboyd@kernel.org> ? > +L: rust-for-linux@vger.kernel.org > +L: linux-kernel@vger.kernel.org > +S: Maintained > +F: rust/kernel/time.rs > + Tomo, let's wait for Andreas' rely and decide how to change these entries. Thanks! Regards, Boqun > TIPC NETWORK LAYER > M: Jon Maloy <jmaloy@redhat.com> > L: netdev@vger.kernel.org (core kernel code)
Hi All, "Boqun Feng" <boqun.feng@gmail.com> writes: > On Sat, Mar 22, 2025 at 11:07:03AM +0900, FUJITA Tomonori wrote: >> Thank you all! >> >> On Fri, 21 Mar 2025 14:00:52 -0700 >> Boqun Feng <boqun.feng@gmail.com> wrote: >> >> > On Fri, Mar 21, 2025 at 09:38:46PM +0100, Thomas Gleixner wrote: >> >> On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote: >> >> >> Could you add me as a reviewer in these entries? >> >> >> >> >> > >> >> > I would like to be added as well. >> >> >> >> Please add the relevant core code maintainers (Anna-Maria, Frederic, >> >> John Stultz and myself) as well to the reviewers list, so that this does >> >> not end up with changes going in opposite directions. >> >> >> > >> > Make sense, I assume you want this to go via rust then (althought we >> > would like it to go via your tree if possible ;-))? >> > > Given Andreas is already preparing the pull request of the hrtimer > abstraction to Miguel, and delay, timekeeping and hrtimer are related, > these timekeeping/delay patches should go via Andreas (i.e. > rust/hrtimer-next into rust/rust-next) if Thomas and Miguel are OK with > it. Works for you, Andreas? If so... > >> Once the following review regarding fsleep() is complete, I will submit >> patches #2 through #6 as v12 for rust-next: >> >> https://lore.kernel.org/linux-kernel/20250322.102449.895174336060649075.fujita.tomonori@gmail.com/ >> >> The updated MAINTAINERS file will look like the following. >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index cbf84690c495..858e0b34422f 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -10370,6 +10370,18 @@ F: kernel/time/timer_list.c >> F: kernel/time/timer_migration.* >> F: tools/testing/selftests/timers/ >> >> +DELAY AND SLEEP API [RUST] >> +M: FUJITA Tomonori <fujita.tomonori@gmail.com> >> +R: Boqun Feng <boqun.feng@gmail.com> >> +R: Andreas Hindborg <a.hindborg@kernel.org> > > ... this "R:" entry would be "M:", > >> +R: Anna-Maria Behnsen <anna-maria@linutronix.de> >> +R: Frederic Weisbecker <frederic@kernel.org> >> +R: Thomas Gleixner <tglx@linutronix.de> >> +L: rust-for-linux@vger.kernel.org >> +L: linux-kernel@vger.kernel.org > > +T: git https://github.com/Rust-for-Linux/linux.git hrtimer-next > >> +S: Maintained > > I will let Andreas decide whether this is a "Supported" entry ;-) > >> +F: rust/kernel/time/delay.rs >> + >> HIGH-SPEED SCC DRIVER FOR AX.25 >> L: linux-hams@vger.kernel.org >> S: Orphan >> @@ -23944,6 +23956,17 @@ F: kernel/time/timekeeping* >> F: kernel/time/time_test.c >> F: tools/testing/selftests/timers/ >> >> +TIMEKEEPING API [RUST] > > and similar things for this entry as well. > >> +M: FUJITA Tomonori <fujita.tomonori@gmail.com> >> +R: Boqun Feng <boqun.feng@gmail.com> >> +R: Andreas Hindborg <a.hindborg@kernel.org> >> +R: John Stultz <jstultz@google.com> >> +R: Thomas Gleixner <tglx@linutronix.de> > > +R: Stephen Boyd <sboyd@kernel.org> > > ? > >> +L: rust-for-linux@vger.kernel.org >> +L: linux-kernel@vger.kernel.org >> +S: Maintained >> +F: rust/kernel/time.rs >> + > > Tomo, let's wait for Andreas' rely and decide how to change these > entries. Thanks! My recommendation would be to take all of `rust/kernel/time` under one entry for now. I suggest the following, folding in the hrtimer entry as well: DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] M: Andreas Hindborg <a.hindborg@kernel.org> R: Boqun Feng <boqun.feng@gmail.com> R: FUJITA Tomonori <fujita.tomonori@gmail.com> R: Lyude Paul <lyude@redhat.com> R: Frederic Weisbecker <frederic@kernel.org> R: Thomas Gleixner <tglx@linutronix.de> R: Anna-Maria Behnsen <anna-maria@linutronix.de> R: John Stultz <jstultz@google.com> L: rust-for-linux@vger.kernel.org S: Supported W: https://rust-for-linux.com B: https://github.com/Rust-for-Linux/linux/issues T: git https://github.com/Rust-for-Linux/linux.git rust-timekeeping-next F: rust/kernel/time.rs F: rust/kernel/time/ If that is acceptable to everyone, it is very likely that I can pick 2-6 for v6.16. I assume patch 1 will go through the sched/core tree, and then Miguel can pick 7. Best regards, Andreas Hindborg
On Sat, Mar 22, 2025 at 11:40:21PM +0100, Andreas Hindborg wrote: > Hi All, > > "Boqun Feng" <boqun.feng@gmail.com> writes: > > > On Sat, Mar 22, 2025 at 11:07:03AM +0900, FUJITA Tomonori wrote: > >> Thank you all! > >> > >> On Fri, 21 Mar 2025 14:00:52 -0700 > >> Boqun Feng <boqun.feng@gmail.com> wrote: > >> > >> > On Fri, Mar 21, 2025 at 09:38:46PM +0100, Thomas Gleixner wrote: > >> >> On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote: > >> >> >> Could you add me as a reviewer in these entries? > >> >> >> > >> >> > > >> >> > I would like to be added as well. > >> >> > >> >> Please add the relevant core code maintainers (Anna-Maria, Frederic, > >> >> John Stultz and myself) as well to the reviewers list, so that this does > >> >> not end up with changes going in opposite directions. > >> >> > >> > > >> > Make sense, I assume you want this to go via rust then (althought we > >> > would like it to go via your tree if possible ;-))? > >> > > > > Given Andreas is already preparing the pull request of the hrtimer > > abstraction to Miguel, and delay, timekeeping and hrtimer are related, > > these timekeeping/delay patches should go via Andreas (i.e. > > rust/hrtimer-next into rust/rust-next) if Thomas and Miguel are OK with > > it. Works for you, Andreas? If so... > > > >> Once the following review regarding fsleep() is complete, I will submit > >> patches #2 through #6 as v12 for rust-next: > >> > >> https://lore.kernel.org/linux-kernel/20250322.102449.895174336060649075.fujita.tomonori@gmail.com/ > >> > >> The updated MAINTAINERS file will look like the following. > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index cbf84690c495..858e0b34422f 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -10370,6 +10370,18 @@ F: kernel/time/timer_list.c > >> F: kernel/time/timer_migration.* > >> F: tools/testing/selftests/timers/ > >> > >> +DELAY AND SLEEP API [RUST] > >> +M: FUJITA Tomonori <fujita.tomonori@gmail.com> > >> +R: Boqun Feng <boqun.feng@gmail.com> > >> +R: Andreas Hindborg <a.hindborg@kernel.org> > > > > ... this "R:" entry would be "M:", > > > >> +R: Anna-Maria Behnsen <anna-maria@linutronix.de> > >> +R: Frederic Weisbecker <frederic@kernel.org> > >> +R: Thomas Gleixner <tglx@linutronix.de> > >> +L: rust-for-linux@vger.kernel.org > >> +L: linux-kernel@vger.kernel.org > > > > +T: git https://github.com/Rust-for-Linux/linux.git hrtimer-next > > > >> +S: Maintained > > > > I will let Andreas decide whether this is a "Supported" entry ;-) > > > >> +F: rust/kernel/time/delay.rs > >> + > >> HIGH-SPEED SCC DRIVER FOR AX.25 > >> L: linux-hams@vger.kernel.org > >> S: Orphan > >> @@ -23944,6 +23956,17 @@ F: kernel/time/timekeeping* > >> F: kernel/time/time_test.c > >> F: tools/testing/selftests/timers/ > >> > >> +TIMEKEEPING API [RUST] > > > > and similar things for this entry as well. > > > >> +M: FUJITA Tomonori <fujita.tomonori@gmail.com> > >> +R: Boqun Feng <boqun.feng@gmail.com> > >> +R: Andreas Hindborg <a.hindborg@kernel.org> > >> +R: John Stultz <jstultz@google.com> > >> +R: Thomas Gleixner <tglx@linutronix.de> > > > > +R: Stephen Boyd <sboyd@kernel.org> > > > > ? > > > >> +L: rust-for-linux@vger.kernel.org > >> +L: linux-kernel@vger.kernel.org > >> +S: Maintained > >> +F: rust/kernel/time.rs > >> + > > > > Tomo, let's wait for Andreas' rely and decide how to change these > > entries. Thanks! > > My recommendation would be to take all of `rust/kernel/time` under one > entry for now. I suggest the following, folding in the hrtimer entry as > well: > > DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] > M: Andreas Hindborg <a.hindborg@kernel.org> Given you're the one who would handle the patches, I think this make more sense. > R: Boqun Feng <boqun.feng@gmail.com> > R: FUJITA Tomonori <fujita.tomonori@gmail.com> Tomo, does this look good to you? > R: Lyude Paul <lyude@redhat.com> > R: Frederic Weisbecker <frederic@kernel.org> > R: Thomas Gleixner <tglx@linutronix.de> > R: Anna-Maria Behnsen <anna-maria@linutronix.de> > R: John Stultz <jstultz@google.com> We should add: R: Stephen Boyd <sboyd@kernel.org> If Stephen is not against it. > L: rust-for-linux@vger.kernel.org > S: Supported > W: https://rust-for-linux.com > B: https://github.com/Rust-for-Linux/linux/issues > T: git https://github.com/Rust-for-Linux/linux.git rust-timekeeping-next > F: rust/kernel/time.rs > F: rust/kernel/time/ > > If that is acceptable to everyone, it is very likely that I can pick 2-6 > for v6.16. > You will need to fix something because patch 2-6 removes `Ktime` ;-) > I assume patch 1 will go through the sched/core tree, and then Miguel > can pick 7. > Patch 1 & 7 probably should go together, but we can decide it later. Regards, Boqun > Best regards, > Andreas Hindborg > > >
On Mon, 31 Mar 2025 07:03:15 -0700 Boqun Feng <boqun.feng@gmail.com> wrote: >> My recommendation would be to take all of `rust/kernel/time` under one >> entry for now. I suggest the following, folding in the hrtimer entry as >> well: >> >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] >> M: Andreas Hindborg <a.hindborg@kernel.org> > > Given you're the one who would handle the patches, I think this make > more sense. > >> R: Boqun Feng <boqun.feng@gmail.com> >> R: FUJITA Tomonori <fujita.tomonori@gmail.com> > > Tomo, does this look good to you? Fine by me. So a single entry for all the Rust time stuff, which isn't aligned with C's MAINTAINERS entries. It's just for now? >> R: Lyude Paul <lyude@redhat.com> >> R: Frederic Weisbecker <frederic@kernel.org> >> R: Thomas Gleixner <tglx@linutronix.de> >> R: Anna-Maria Behnsen <anna-maria@linutronix.de> >> R: John Stultz <jstultz@google.com> > > We should add: > > R: Stephen Boyd <sboyd@kernel.org> > > If Stephen is not against it. > >> L: rust-for-linux@vger.kernel.org >> S: Supported >> W: https://rust-for-linux.com >> B: https://github.com/Rust-for-Linux/linux/issues >> T: git https://github.com/Rust-for-Linux/linux.git rust-timekeeping-next >> F: rust/kernel/time.rs >> F: rust/kernel/time/ >> >> If that is acceptable to everyone, it is very likely that I can pick 2-6 >> for v6.16. >> > > You will need to fix something because patch 2-6 removes `Ktime` ;-) I'll take care of it in the next version. >> I assume patch 1 will go through the sched/core tree, and then Miguel >> can pick 7. >> > > Patch 1 & 7 probably should go together, but we can decide it later. Since nothing has moved forward for quite a while, maybe it's time to drop patch 1.
On Wed, Apr 02, 2025 at 11:16:27PM +0900, FUJITA Tomonori wrote: > On Mon, 31 Mar 2025 07:03:15 -0700 > Boqun Feng <boqun.feng@gmail.com> wrote: > > >> My recommendation would be to take all of `rust/kernel/time` under one > >> entry for now. I suggest the following, folding in the hrtimer entry as > >> well: > >> > >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] > >> M: Andreas Hindborg <a.hindborg@kernel.org> > > > > Given you're the one who would handle the patches, I think this make > > more sense. > > > >> R: Boqun Feng <boqun.feng@gmail.com> > >> R: FUJITA Tomonori <fujita.tomonori@gmail.com> > > > > Tomo, does this look good to you? > > Fine by me. > > So a single entry for all the Rust time stuff, which isn't aligned > with C's MAINTAINERS entries. It's just for now? > Given Andreas is the one who's going to handle the PRs, and he will put all the things in one branch. I think it's fine even for long term, and we got all relevant reviewers covered. If the Rust timekeeping + hrtimer community expands in the future, we can also add more entries. We don't necessarily need to copy all maintainer structures from C ;-) > > >> R: Lyude Paul <lyude@redhat.com> > >> R: Frederic Weisbecker <frederic@kernel.org> > >> R: Thomas Gleixner <tglx@linutronix.de> > >> R: Anna-Maria Behnsen <anna-maria@linutronix.de> > >> R: John Stultz <jstultz@google.com> > > > > We should add: > > > > R: Stephen Boyd <sboyd@kernel.org> > > > > If Stephen is not against it. > > > >> L: rust-for-linux@vger.kernel.org > >> S: Supported > >> W: https://rust-for-linux.com > >> B: https://github.com/Rust-for-Linux/linux/issues > >> T: git https://github.com/Rust-for-Linux/linux.git rust-timekeeping-next > >> F: rust/kernel/time.rs > >> F: rust/kernel/time/ > >> > >> If that is acceptable to everyone, it is very likely that I can pick 2-6 > >> for v6.16. > >> > > > > You will need to fix something because patch 2-6 removes `Ktime` ;-) > > I'll take care of it in the next version. > Thanks! > >> I assume patch 1 will go through the sched/core tree, and then Miguel > >> can pick 7. > >> > > > > Patch 1 & 7 probably should go together, but we can decide it later. > > Since nothing has moved forward for quite a while, maybe it's time to > drop patch 1. No, I think we should keep it. Because otherwise we will use a macro version of read_poll_timeout(), which is strictly worse. I'm happy to collect patch #1 and the cpu_relax() patch of patch #7, and send an PR to tip. Could you split them a bit: * Move the Rust might_sleep() in patch #7 to patch #1 and put it at kernel::task, also if we EXPORT_SYMBOL(__might_sleep_precision), we don't need the rust_helper for it. * Have a separate containing the cpu_relax() bit. * Also you may want to put #[inline] at cpu_relax() and might_resched(). and we can start from there. Sounds good? Regards, Boqun
On Wed, 2 Apr 2025 09:29:18 -0700 Boqun Feng <boqun.feng@gmail.com> wrote: > On Wed, Apr 02, 2025 at 11:16:27PM +0900, FUJITA Tomonori wrote: >> On Mon, 31 Mar 2025 07:03:15 -0700 >> Boqun Feng <boqun.feng@gmail.com> wrote: >> >> >> My recommendation would be to take all of `rust/kernel/time` under one >> >> entry for now. I suggest the following, folding in the hrtimer entry as >> >> well: >> >> >> >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] >> >> M: Andreas Hindborg <a.hindborg@kernel.org> >> > >> > Given you're the one who would handle the patches, I think this make >> > more sense. >> > >> >> R: Boqun Feng <boqun.feng@gmail.com> >> >> R: FUJITA Tomonori <fujita.tomonori@gmail.com> >> > >> > Tomo, does this look good to you? >> >> Fine by me. >> >> So a single entry for all the Rust time stuff, which isn't aligned >> with C's MAINTAINERS entries. It's just for now? >> > > Given Andreas is the one who's going to handle the PRs, and he will put > all the things in one branch. I think it's fine even for long term, and > we got all relevant reviewers covered. If the Rust timekeeping + hrtimer > community expands in the future, we can also add more entries. We don't > necessarily need to copy all maintainer structures from C ;-) It seems I was mistaken. I had thought that the ideal goal was for the same team to maintain both the C code and the corresponding Rust code. >> >> I assume patch 1 will go through the sched/core tree, and then Miguel >> >> can pick 7. >> >> >> > >> > Patch 1 & 7 probably should go together, but we can decide it later. >> >> Since nothing has moved forward for quite a while, maybe it's time to >> drop patch 1. > > No, I think we should keep it. Because otherwise we will use a macro Yeah, I know. the first version of this uses a macro. > version of read_poll_timeout(), which is strictly worse. I'm happy to > collect patch #1 and the cpu_relax() patch of patch #7, and send an PR > to tip. Could you split them a bit: > > * Move the Rust might_sleep() in patch #7 to patch #1 and put it at > kernel::task, also if we EXPORT_SYMBOL(__might_sleep_precision), we > don't need the rust_helper for it. > > * Have a separate containing the cpu_relax() bit. > > * Also you may want to put #[inline] at cpu_relax() and might_resched(). > > and we can start from there. Sounds good? I can do whatever but I don't think these matters. The problem is that we haven't received a response from the scheduler maintainers for a long time. We don't even know if the implementation is actually an issue.
On Thu, Apr 03, 2025 at 08:03:34AM +0900, FUJITA Tomonori wrote: > On Wed, 2 Apr 2025 09:29:18 -0700 > Boqun Feng <boqun.feng@gmail.com> wrote: > > > On Wed, Apr 02, 2025 at 11:16:27PM +0900, FUJITA Tomonori wrote: > >> On Mon, 31 Mar 2025 07:03:15 -0700 > >> Boqun Feng <boqun.feng@gmail.com> wrote: > >> > >> >> My recommendation would be to take all of `rust/kernel/time` under one > >> >> entry for now. I suggest the following, folding in the hrtimer entry as > >> >> well: > >> >> > >> >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] > >> >> M: Andreas Hindborg <a.hindborg@kernel.org> > >> > > >> > Given you're the one who would handle the patches, I think this make > >> > more sense. > >> > > >> >> R: Boqun Feng <boqun.feng@gmail.com> > >> >> R: FUJITA Tomonori <fujita.tomonori@gmail.com> > >> > > >> > Tomo, does this look good to you? > >> > >> Fine by me. > >> > >> So a single entry for all the Rust time stuff, which isn't aligned > >> with C's MAINTAINERS entries. It's just for now? > >> > > > > Given Andreas is the one who's going to handle the PRs, and he will put > > all the things in one branch. I think it's fine even for long term, and > > we got all relevant reviewers covered. If the Rust timekeeping + hrtimer > > community expands in the future, we can also add more entries. We don't > > necessarily need to copy all maintainer structures from C ;-) > > It seems I was mistaken. I had thought that the ideal goal was for the > same team to maintain both the C code and the corresponding Rust code. > Yeah, that was the ideal goal, but Frederic said in the hrtimer series: https://lore.kernel.org/rust-for-linux/Z8iLIyofy6KGOsq5@localhost.localdomain/ , to me it's clear that hrtimer maintainers want hrtimer Rust patches to go to rust tree via Andreas, and given timekeeping maintainers are basically the same group of people, and Thomas explicitly asked to be added as reviewers: https://lore.kernel.org/rust-for-linux/87o6xu15m1.ffs@tglx/ It's a clear signal that timekeeping and hrtimer Rust patches are preferred to go to rust tree, and Andreas had nicely accepted to handle timekeeping and sleep/delay patches, so it makes sense to use one entry if he prefers. Hope this clarifies things. > > >> >> I assume patch 1 will go through the sched/core tree, and then Miguel > >> >> can pick 7. > >> >> > >> > > >> > Patch 1 & 7 probably should go together, but we can decide it later. > >> > >> Since nothing has moved forward for quite a while, maybe it's time to > >> drop patch 1. > > > > No, I think we should keep it. Because otherwise we will use a macro > > Yeah, I know. the first version of this uses a macro. > > > > version of read_poll_timeout(), which is strictly worse. I'm happy to > > collect patch #1 and the cpu_relax() patch of patch #7, and send an PR > > to tip. Could you split them a bit: > > > > * Move the Rust might_sleep() in patch #7 to patch #1 and put it at > > kernel::task, also if we EXPORT_SYMBOL(__might_sleep_precision), we > > don't need the rust_helper for it. > > > > * Have a separate containing the cpu_relax() bit. > > > > * Also you may want to put #[inline] at cpu_relax() and might_resched(). > > > > and we can start from there. Sounds good? > > I can do whatever but I don't think these matters. The problem is that Confused. I said I would do a PR, that means if no objection, the patches will get merged. Isn't this a way to move forward? Or you're against that I'm doing a PR? > we haven't received a response from the scheduler maintainers for a > long time. We don't even know if the implementation is actually an > issue. > If there's an issue, I can fix it. After all, printk confirmed that ".*s" format works for this case: https://lore.kernel.org/rust-for-linux/ZyyAsjsz05AlkOBd@pathway.suse.cz/ and Peter sort of confirmed he's not against the idea: https://lore.kernel.org/rust-for-linux/20250201121613.GC8256@noisy.programming.kicks-ass.net/ I don't see any major issue blocking this. But of course, I'm happy to resolve if there is one. Regards, Boqun > >
On Wed, 2 Apr 2025 17:51:41 -0700 Boqun Feng <boqun.feng@gmail.com> wrote: > On Thu, Apr 03, 2025 at 08:03:34AM +0900, FUJITA Tomonori wrote: >> On Wed, 2 Apr 2025 09:29:18 -0700 >> Boqun Feng <boqun.feng@gmail.com> wrote: >> >> > On Wed, Apr 02, 2025 at 11:16:27PM +0900, FUJITA Tomonori wrote: >> >> On Mon, 31 Mar 2025 07:03:15 -0700 >> >> Boqun Feng <boqun.feng@gmail.com> wrote: >> >> >> >> >> My recommendation would be to take all of `rust/kernel/time` under one >> >> >> entry for now. I suggest the following, folding in the hrtimer entry as >> >> >> well: >> >> >> >> >> >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] >> >> >> M: Andreas Hindborg <a.hindborg@kernel.org> >> >> > >> >> > Given you're the one who would handle the patches, I think this make >> >> > more sense. >> >> > >> >> >> R: Boqun Feng <boqun.feng@gmail.com> >> >> >> R: FUJITA Tomonori <fujita.tomonori@gmail.com> >> >> > >> >> > Tomo, does this look good to you? >> >> >> >> Fine by me. >> >> >> >> So a single entry for all the Rust time stuff, which isn't aligned >> >> with C's MAINTAINERS entries. It's just for now? >> >> >> > >> > Given Andreas is the one who's going to handle the PRs, and he will put >> > all the things in one branch. I think it's fine even for long term, and >> > we got all relevant reviewers covered. If the Rust timekeeping + hrtimer >> > community expands in the future, we can also add more entries. We don't >> > necessarily need to copy all maintainer structures from C ;-) >> >> It seems I was mistaken. I had thought that the ideal goal was for the >> same team to maintain both the C code and the corresponding Rust code. >> > > Yeah, that was the ideal goal, but Frederic said in the hrtimer series: > > https://lore.kernel.org/rust-for-linux/Z8iLIyofy6KGOsq5@localhost.localdomain/ > > , to me it's clear that hrtimer maintainers want hrtimer Rust patches to > go to rust tree via Andreas, and given timekeeping maintainers are > basically the same group of people, and Thomas explicitly asked to be > added as reviewers: > > https://lore.kernel.org/rust-for-linux/87o6xu15m1.ffs@tglx/ > > It's a clear signal that timekeeping and hrtimer Rust patches are > preferred to go to rust tree, and Andreas had nicely accepted to handle > timekeeping and sleep/delay patches, so it makes sense to use one entry > if he prefers. Hope this clarifies things. Yeah, I see your point. >> >> >> I assume patch 1 will go through the sched/core tree, and then Miguel >> >> >> can pick 7. >> >> >> >> >> > >> >> > Patch 1 & 7 probably should go together, but we can decide it later. >> >> >> >> Since nothing has moved forward for quite a while, maybe it's time to >> >> drop patch 1. >> > >> > No, I think we should keep it. Because otherwise we will use a macro >> >> Yeah, I know. the first version of this uses a macro. >> >> >> > version of read_poll_timeout(), which is strictly worse. I'm happy to >> > collect patch #1 and the cpu_relax() patch of patch #7, and send an PR >> > to tip. Could you split them a bit: >> > >> > * Move the Rust might_sleep() in patch #7 to patch #1 and put it at >> > kernel::task, also if we EXPORT_SYMBOL(__might_sleep_precision), we >> > don't need the rust_helper for it. >> > >> > * Have a separate containing the cpu_relax() bit. >> > >> > * Also you may want to put #[inline] at cpu_relax() and might_resched(). >> > >> > and we can start from there. Sounds good? >> >> I can do whatever but I don't think these matters. The problem is that > > Confused. I said I would do a PR, that means if no objection, the > patches will get merged. Isn't this a way to move forward? Or you're > against that I'm doing a PR? I don't object to you doing a PR. I meant that it's unclear whether we can move forward with the approach, as we haven't received much response from the maintainers and we don't know what the blockers are. >> we haven't received a response from the scheduler maintainers for a >> long time. We don't even know if the implementation is actually an >> issue. >> > > If there's an issue, I can fix it. After all, printk confirmed that > ".*s" format works for this case: > > https://lore.kernel.org/rust-for-linux/ZyyAsjsz05AlkOBd@pathway.suse.cz/ > > and Peter sort of confirmed he's not against the idea: > > https://lore.kernel.org/rust-for-linux/20250201121613.GC8256@noisy.programming.kicks-ass.net/ > > I don't see any major issue blocking this. But of course, I'm happy to > resolve if there is one. I know but this patch adds a workaround to the C code for Rust’s sake, I would understand if the maintainers reject it and prefer having Rust work around the issue instead. Anyway, let's try one more time. I'll modify the patch #1 as you suggested and send a new patchset. Thanks!
On Thu, Apr 03, 2025 at 12:02:00PM +0900, FUJITA Tomonori wrote: [...] > >> > version of read_poll_timeout(), which is strictly worse. I'm happy to > >> > collect patch #1 and the cpu_relax() patch of patch #7, and send an PR > >> > to tip. Could you split them a bit: > >> > > >> > * Move the Rust might_sleep() in patch #7 to patch #1 and put it at > >> > kernel::task, also if we EXPORT_SYMBOL(__might_sleep_precision), we > >> > don't need the rust_helper for it. > >> > > >> > * Have a separate containing the cpu_relax() bit. > >> > > >> > * Also you may want to put #[inline] at cpu_relax() and might_resched(). > >> > > >> > and we can start from there. Sounds good? > >> > >> I can do whatever but I don't think these matters. The problem is that > > > > Confused. I said I would do a PR, that means if no objection, the > > patches will get merged. Isn't this a way to move forward? Or you're > > against that I'm doing a PR? > > I don't object to you doing a PR. > > I meant that it's unclear whether we can move forward with the > approach, as we haven't received much response from the maintainers > and we don't know what the blockers are. > > >> we haven't received a response from the scheduler maintainers for a > >> long time. We don't even know if the implementation is actually an > >> issue. > >> > > > > If there's an issue, I can fix it. After all, printk confirmed that > > ".*s" format works for this case: > > > > https://lore.kernel.org/rust-for-linux/ZyyAsjsz05AlkOBd@pathway.suse.cz/ > > > > and Peter sort of confirmed he's not against the idea: > > > > https://lore.kernel.org/rust-for-linux/20250201121613.GC8256@noisy.programming.kicks-ass.net/ > > > > I don't see any major issue blocking this. But of course, I'm happy to > > resolve if there is one. > > I know but this patch adds a workaround to the C code for Rust´s sake, The workaround at C is a helper function and the original C API still works as it should be. > I would understand if the maintainers reject it and prefer having Rust > work around the issue instead. > The workaround at Rust means we could have a function interface but we use a macro interface. I say we pick the C workaround, because read_poll_timeout() is a public API, it's worth the effect making it better. > Anyway, let's try one more time. I'll modify the patch #1 as you > suggested and send a new patchset. > Thanks! Regards, Boqun > > Thanks!
"Boqun Feng" <boqun.feng@gmail.com> writes: > On Sat, Mar 22, 2025 at 11:40:21PM +0100, Andreas Hindborg wrote: >> Hi All, >> >> "Boqun Feng" <boqun.feng@gmail.com> writes: >> >> > On Sat, Mar 22, 2025 at 11:07:03AM +0900, FUJITA Tomonori wrote: >> >> Thank you all! >> >> >> >> On Fri, 21 Mar 2025 14:00:52 -0700 >> >> Boqun Feng <boqun.feng@gmail.com> wrote: >> >> >> >> > On Fri, Mar 21, 2025 at 09:38:46PM +0100, Thomas Gleixner wrote: >> >> >> On Fri, Mar 21 2025 at 20:18, Andreas Hindborg wrote: >> >> >> >> Could you add me as a reviewer in these entries? >> >> >> >> >> >> >> > >> >> >> > I would like to be added as well. >> >> >> >> >> >> Please add the relevant core code maintainers (Anna-Maria, Frederic, >> >> >> John Stultz and myself) as well to the reviewers list, so that this does >> >> >> not end up with changes going in opposite directions. >> >> >> >> >> > >> >> > Make sense, I assume you want this to go via rust then (althought we >> >> > would like it to go via your tree if possible ;-))? >> >> >> > >> > Given Andreas is already preparing the pull request of the hrtimer >> > abstraction to Miguel, and delay, timekeeping and hrtimer are related, >> > these timekeeping/delay patches should go via Andreas (i.e. >> > rust/hrtimer-next into rust/rust-next) if Thomas and Miguel are OK with >> > it. Works for you, Andreas? If so... >> > >> >> Once the following review regarding fsleep() is complete, I will submit >> >> patches #2 through #6 as v12 for rust-next: >> >> >> >> https://lore.kernel.org/linux-kernel/20250322.102449.895174336060649075.fujita.tomonori@gmail.com/ >> >> >> >> The updated MAINTAINERS file will look like the following. >> >> >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> >> index cbf84690c495..858e0b34422f 100644 >> >> --- a/MAINTAINERS >> >> +++ b/MAINTAINERS >> >> @@ -10370,6 +10370,18 @@ F: kernel/time/timer_list.c >> >> F: kernel/time/timer_migration.* >> >> F: tools/testing/selftests/timers/ >> >> >> >> +DELAY AND SLEEP API [RUST] >> >> +M: FUJITA Tomonori <fujita.tomonori@gmail.com> >> >> +R: Boqun Feng <boqun.feng@gmail.com> >> >> +R: Andreas Hindborg <a.hindborg@kernel.org> >> > >> > ... this "R:" entry would be "M:", >> > >> >> +R: Anna-Maria Behnsen <anna-maria@linutronix.de> >> >> +R: Frederic Weisbecker <frederic@kernel.org> >> >> +R: Thomas Gleixner <tglx@linutronix.de> >> >> +L: rust-for-linux@vger.kernel.org >> >> +L: linux-kernel@vger.kernel.org >> > >> > +T: git https://github.com/Rust-for-Linux/linux.git hrtimer-next >> > >> >> +S: Maintained >> > >> > I will let Andreas decide whether this is a "Supported" entry ;-) >> > >> >> +F: rust/kernel/time/delay.rs >> >> + >> >> HIGH-SPEED SCC DRIVER FOR AX.25 >> >> L: linux-hams@vger.kernel.org >> >> S: Orphan >> >> @@ -23944,6 +23956,17 @@ F: kernel/time/timekeeping* >> >> F: kernel/time/time_test.c >> >> F: tools/testing/selftests/timers/ >> >> >> >> +TIMEKEEPING API [RUST] >> > >> > and similar things for this entry as well. >> > >> >> +M: FUJITA Tomonori <fujita.tomonori@gmail.com> >> >> +R: Boqun Feng <boqun.feng@gmail.com> >> >> +R: Andreas Hindborg <a.hindborg@kernel.org> >> >> +R: John Stultz <jstultz@google.com> >> >> +R: Thomas Gleixner <tglx@linutronix.de> >> > >> > +R: Stephen Boyd <sboyd@kernel.org> >> > >> > ? >> > >> >> +L: rust-for-linux@vger.kernel.org >> >> +L: linux-kernel@vger.kernel.org >> >> +S: Maintained >> >> +F: rust/kernel/time.rs >> >> + >> > >> > Tomo, let's wait for Andreas' rely and decide how to change these >> > entries. Thanks! >> >> My recommendation would be to take all of `rust/kernel/time` under one >> entry for now. I suggest the following, folding in the hrtimer entry as >> well: >> >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST] >> M: Andreas Hindborg <a.hindborg@kernel.org> > > Given you're the one who would handle the patches, I think this make > more sense. > >> R: Boqun Feng <boqun.feng@gmail.com> >> R: FUJITA Tomonori <fujita.tomonori@gmail.com> > > Tomo, does this look good to you? > >> R: Lyude Paul <lyude@redhat.com> >> R: Frederic Weisbecker <frederic@kernel.org> >> R: Thomas Gleixner <tglx@linutronix.de> >> R: Anna-Maria Behnsen <anna-maria@linutronix.de> >> R: John Stultz <jstultz@google.com> > > We should add: > > R: Stephen Boyd <sboyd@kernel.org> > > If Stephen is not against it. Yes 👍 > >> L: rust-for-linux@vger.kernel.org >> S: Supported >> W: https://rust-for-linux.com >> B: https://github.com/Rust-for-Linux/linux/issues >> T: git https://github.com/Rust-for-Linux/linux.git rust-timekeeping-next >> F: rust/kernel/time.rs >> F: rust/kernel/time/ >> >> If that is acceptable to everyone, it is very likely that I can pick 2-6 >> for v6.16. >> > > You will need to fix something because patch 2-6 removes `Ktime` ;-) Yea, but `Instant` is almost a direct substitution, right? Anyway, Tomo can send a new spin and change all the uses of Ktime, or I can do it. It should be straight forward. Either way is fine with me. Best regards, Andreas Hindborg
On Mon, 31 Mar 2025 21:43:50 +0200 Andreas Hindborg <a.hindborg@kernel.org> wrote: >>> If that is acceptable to everyone, it is very likely that I can pick 2-6 >>> for v6.16. >>> >> >> You will need to fix something because patch 2-6 removes `Ktime` ;-) > > Yea, but `Instant` is almost a direct substitution, right? Anyway, Tomo > can send a new spin and change all the uses of Ktime, or I can do it. It > should be straight forward. Either way is fine with me. `Delta`? Not `Instant`. All Ktime in hrtimer are passed to hrtimer_start_range_ns(), right? I'll send a new version shortly.
"FUJITA Tomonori" <fujita.tomonori@gmail.com> writes: > On Mon, 31 Mar 2025 21:43:50 +0200 > Andreas Hindborg <a.hindborg@kernel.org> wrote: > >>>> If that is acceptable to everyone, it is very likely that I can pick 2-6 >>>> for v6.16. >>>> >>> >>> You will need to fix something because patch 2-6 removes `Ktime` ;-) >> >> Yea, but `Instant` is almost a direct substitution, right? Anyway, Tomo >> can send a new spin and change all the uses of Ktime, or I can do it. It >> should be straight forward. Either way is fine with me. > > `Delta`? Not `Instant`. It depends. Current hrtimer takes `Ktime` and supports `HrTimerMode::Absolute` and `HrTimerMode::Relative`. With `Delta` and `Instant` we should take `Instant` for `HrTimerMode::Absolute` and `Delta` for `HrTimerMode::Relative`. The API needs to be modified a bit to make that work though. Probably we need to make the start function generic over the expiration type or something. If you want to, you can fix that. If not, you can use `Instant` for the relative case as well, and we shall interpret it as duration. Then I will fix it up later. Your decision. > All Ktime in hrtimer are passed to hrtimer_start_range_ns(), right? Yes, that is where they end up. > I'll send a new version shortly. Great :) Best regards, Andreas Hindborg
On Thu, 03 Apr 2025 12:54:40 +0200 Andreas Hindborg <a.hindborg@kernel.org> wrote: >>>> You will need to fix something because patch 2-6 removes `Ktime` ;-) >>> >>> Yea, but `Instant` is almost a direct substitution, right? Anyway, Tomo >>> can send a new spin and change all the uses of Ktime, or I can do it. It >>> should be straight forward. Either way is fine with me. >> >> `Delta`? Not `Instant`. > > It depends. Current hrtimer takes `Ktime` and supports > `HrTimerMode::Absolute` and `HrTimerMode::Relative`. With `Delta` and > `Instant` we should take `Instant` for `HrTimerMode::Absolute` and > `Delta` for `HrTimerMode::Relative`. The API needs to be modified a bit > to make that work though. Probably we need to make the start function > generic over the expiration type or something. > > If you want to, you can fix that. If not, you can use `Instant` for the > relative case as well, and we shall interpret it as duration. Then I > will fix it up later. Your decision. > >> All Ktime in hrtimer are passed to hrtimer_start_range_ns(), right? > > Yes, that is where they end up. Ah, I found that __hrtimer_start_range_ns() handles ktime_t differently in HRTIMER_MODE_REL mode. As you said, looks like the API needs to be updated and I think that it's best to leave that to you. I'll just use `Instant` for all cases.
On Thu, Apr 03, 2025 at 09:57:45PM +0900, FUJITA Tomonori wrote:
> On Thu, 03 Apr 2025 12:54:40 +0200
> Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> >>>> You will need to fix something because patch 2-6 removes `Ktime` ;-)
> >>>
> >>> Yea, but `Instant` is almost a direct substitution, right? Anyway, Tomo
> >>> can send a new spin and change all the uses of Ktime, or I can do it. It
> >>> should be straight forward. Either way is fine with me.
> >>
> >> `Delta`? Not `Instant`.
> >
> > It depends. Current hrtimer takes `Ktime` and supports
> > `HrTimerMode::Absolute` and `HrTimerMode::Relative`. With `Delta` and
> > `Instant` we should take `Instant` for `HrTimerMode::Absolute` and
> > `Delta` for `HrTimerMode::Relative`. The API needs to be modified a bit
> > to make that work though. Probably we need to make the start function
> > generic over the expiration type or something.
> >
If we make `HrTimerMode` a trait:
pub trait HrTimerMode {
type Expires; /* either Delta or Instant */
}
and `HrTimerPointer` generic over `HrTimerMode`:
pub trait HrTimerPointer<Mode: HrTimerMode> {
fn start(self, expires: Mode::Expires) -> HrTimerHandler<Mode>
}
then we can disallow that a Relative timer accidentally uses an Instant
or an Absolute timer accidentally uses an Delta. Of course a few other
places need to be generic, but the end result looks pretty good to me.
Regards,
Boqun
> > If you want to, you can fix that. If not, you can use `Instant` for the
> > relative case as well, and we shall interpret it as duration. Then I
> > will fix it up later. Your decision.
> >
> >> All Ktime in hrtimer are passed to hrtimer_start_range_ns(), right?
> >
> > Yes, that is where they end up.
>
> Ah, I found that __hrtimer_start_range_ns() handles ktime_t
> differently in HRTIMER_MODE_REL mode.
>
> As you said, looks like the API needs to be updated and I think that
> it's best to leave that to you. I'll just use `Instant` for all cases.
>
>
© 2016 - 2025 Red Hat, Inc.