drivers/net/phy/qt2025.rs | 11 +++- rust/helpers/helpers.c | 2 + rust/helpers/kernel.c | 13 +++++ rust/helpers/time.c | 19 +++++++ rust/kernel/error.rs | 1 + rust/kernel/io.rs | 5 ++ rust/kernel/io/poll.rs | 70 +++++++++++++++++++++++ rust/kernel/lib.rs | 1 + rust/kernel/time.rs | 113 ++++++++++++++++++++++++++++++++++++++ 9 files changed, 234 insertions(+), 1 deletion(-) create mode 100644 rust/helpers/kernel.c create mode 100644 rust/helpers/time.c create mode 100644 rust/kernel/io.rs create mode 100644 rust/kernel/io/poll.rs
Add Rust version of read_poll_timeout (include/linux/iopoll.h), which polls periodically until a condition is met or a timeout is reached. By using the function, the 6th patch fixes QT2025 PHY driver to sleep until the hardware becomes ready. As a result of the past discussion, this introduces a new type representing a span of time instead of using core::time::Duration or time::Ktime. Unlike the old rust branch, This adds a wrapper for fsleep() instead of msleep(). fsleep() automatically chooses the best sleep method based on a duration. v2: - Introduce time::Delta instead of core::time::Duration - Add some trait to Ktime for calculating timeout - Use read_poll_timeout in QT2025 driver instead of using fsleep directly v1: https://lore.kernel.org/netdev/20241001112512.4861-1-fujita.tomonori@gmail.com/ FUJITA Tomonori (6): rust: time: Implement PartialEq and PartialOrd for Ktime rust: time: Introduce Delta type rust: time: Implement addition of Ktime and Delta rust: time: add wrapper for fsleep function rust: Add read_poll_timeout function net: phy: qt2025: wait until PHY becomes ready drivers/net/phy/qt2025.rs | 11 +++- rust/helpers/helpers.c | 2 + rust/helpers/kernel.c | 13 +++++ rust/helpers/time.c | 19 +++++++ rust/kernel/error.rs | 1 + rust/kernel/io.rs | 5 ++ rust/kernel/io/poll.rs | 70 +++++++++++++++++++++++ rust/kernel/lib.rs | 1 + rust/kernel/time.rs | 113 ++++++++++++++++++++++++++++++++++++++ 9 files changed, 234 insertions(+), 1 deletion(-) create mode 100644 rust/helpers/kernel.c create mode 100644 rust/helpers/time.c create mode 100644 rust/kernel/io.rs create mode 100644 rust/kernel/io/poll.rs base-commit: d521db38f339709ccd23c5deb7663904e626c3a6 -- 2.34.1
Hi Tomo,
On Sat, Oct 05, 2024 at 09:25:25PM +0900, FUJITA Tomonori wrote:
> Add Rust version of read_poll_timeout (include/linux/iopoll.h), which
> polls periodically until a condition is met or a timeout is reached.
> By using the function, the 6th patch fixes QT2025 PHY driver to sleep
> until the hardware becomes ready.
>
> As a result of the past discussion, this introduces a new type
> representing a span of time instead of using core::time::Duration or
> time::Ktime.
>
While, we are at it, I want to suggest that we also add
rust/kernel/time{.rs, /} into the "F:" entries of TIME subsystem like:
diff --git a/MAINTAINERS b/MAINTAINERS
index b77f4495dcf4..09e46a214333 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23376,6 +23376,8 @@ F: kernel/time/timeconv.c
F: kernel/time/timecounter.c
F: kernel/time/timekeeping*
F: kernel/time/time_test.c
+F: rust/kernel/time.rs
+F: rust/kernel/time/
F: tools/testing/selftests/timers/
TIPC NETWORK LAYER
This will help future contributers copy the correct people while
submission. Could you maybe add a patch of this in your series if this
sounds reasonable to you? Thanks!
Regards,
Boqun
> Unlike the old rust branch, This adds a wrapper for fsleep() instead
> of msleep(). fsleep() automatically chooses the best sleep method
> based on a duration.
>
> v2:
> - Introduce time::Delta instead of core::time::Duration
> - Add some trait to Ktime for calculating timeout
> - Use read_poll_timeout in QT2025 driver instead of using fsleep directly
> v1: https://lore.kernel.org/netdev/20241001112512.4861-1-fujita.tomonori@gmail.com/
>
>
> FUJITA Tomonori (6):
> rust: time: Implement PartialEq and PartialOrd for Ktime
> rust: time: Introduce Delta type
> rust: time: Implement addition of Ktime and Delta
> rust: time: add wrapper for fsleep function
> rust: Add read_poll_timeout function
> net: phy: qt2025: wait until PHY becomes ready
>
> drivers/net/phy/qt2025.rs | 11 +++-
> rust/helpers/helpers.c | 2 +
> rust/helpers/kernel.c | 13 +++++
> rust/helpers/time.c | 19 +++++++
> rust/kernel/error.rs | 1 +
> rust/kernel/io.rs | 5 ++
> rust/kernel/io/poll.rs | 70 +++++++++++++++++++++++
> rust/kernel/lib.rs | 1 +
> rust/kernel/time.rs | 113 ++++++++++++++++++++++++++++++++++++++
> 9 files changed, 234 insertions(+), 1 deletion(-)
> create mode 100644 rust/helpers/kernel.c
> create mode 100644 rust/helpers/time.c
> create mode 100644 rust/kernel/io.rs
> create mode 100644 rust/kernel/io/poll.rs
>
>
> base-commit: d521db38f339709ccd23c5deb7663904e626c3a6
> --
> 2.34.1
>
>
On Sat, 12 Oct 2024 08:29:06 -0700
Boqun Feng <boqun.feng@gmail.com> wrote:
> While, we are at it, I want to suggest that we also add
> rust/kernel/time{.rs, /} into the "F:" entries of TIME subsystem like:
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b77f4495dcf4..09e46a214333 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23376,6 +23376,8 @@ F: kernel/time/timeconv.c
> F: kernel/time/timecounter.c
> F: kernel/time/timekeeping*
> F: kernel/time/time_test.c
> +F: rust/kernel/time.rs
> +F: rust/kernel/time/
> F: tools/testing/selftests/timers/
>
> TIPC NETWORK LAYER
>
> This will help future contributers copy the correct people while
> submission. Could you maybe add a patch of this in your series if this
> sounds reasonable to you? Thanks!
Agreed that it's better to have Rust time abstractions in
MAINTAINERS. You add it into the time entry but there are two options
in the file; time and timer?
TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
M: John Stultz <jstultz@google.com>
M: Thomas Gleixner <tglx@linutronix.de>
R: Stephen Boyd <sboyd@kernel.org>
HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
M: Anna-Maria Behnsen <anna-maria@linutronix.de>
M: Frederic Weisbecker <frederic@kernel.org>
M: Thomas Gleixner <tglx@linutronix.de>
The current Rust abstractions which play mainly with ktimer.h. it's
not time, timer stuff, I think.
As planned, we'll move *.rs files from rust/kernel in the future,
how we handle time and timer abstractions?
On Sun, 13 Oct 2024 10:15:05 +0900 (JST)
FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:
> On Sat, 12 Oct 2024 08:29:06 -0700
> Boqun Feng <boqun.feng@gmail.com> wrote:
>
>> While, we are at it, I want to suggest that we also add
>> rust/kernel/time{.rs, /} into the "F:" entries of TIME subsystem like:
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b77f4495dcf4..09e46a214333 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -23376,6 +23376,8 @@ F: kernel/time/timeconv.c
>> F: kernel/time/timecounter.c
>> F: kernel/time/timekeeping*
>> F: kernel/time/time_test.c
>> +F: rust/kernel/time.rs
>> +F: rust/kernel/time/
>> F: tools/testing/selftests/timers/
>>
>> TIPC NETWORK LAYER
>>
>> This will help future contributers copy the correct people while
>> submission. Could you maybe add a patch of this in your series if this
>> sounds reasonable to you? Thanks!
>
> Agreed that it's better to have Rust time abstractions in
> MAINTAINERS. You add it into the time entry but there are two options
> in the file; time and timer?
>
> TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
> M: John Stultz <jstultz@google.com>
> M: Thomas Gleixner <tglx@linutronix.de>
> R: Stephen Boyd <sboyd@kernel.org>
>
> HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
> M: Anna-Maria Behnsen <anna-maria@linutronix.de>
> M: Frederic Weisbecker <frederic@kernel.org>
> M: Thomas Gleixner <tglx@linutronix.de>
>
> The current Rust abstractions which play mainly with ktimer.h. it's
> not time, timer stuff, I think.
Oops, s/ktimer.h/ktime.h/
No entry for ktime.h in MAINTAINERS; used by both time and timer
stuff.
> As planned, we'll move *.rs files from rust/kernel in the future,
> how we handle time and timer abstractions?
Looks like that we'll add rust/kernel/hrtimer/ soon. I feel that it's
better to decide on the layout of time and timer abstractions now
rather than later.
On Sun, Oct 13, 2024 at 11:50:33AM +0900, FUJITA Tomonori wrote:
> On Sun, 13 Oct 2024 10:15:05 +0900 (JST)
> FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:
>
> > On Sat, 12 Oct 2024 08:29:06 -0700
> > Boqun Feng <boqun.feng@gmail.com> wrote:
> >
> >> While, we are at it, I want to suggest that we also add
> >> rust/kernel/time{.rs, /} into the "F:" entries of TIME subsystem like:
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index b77f4495dcf4..09e46a214333 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -23376,6 +23376,8 @@ F: kernel/time/timeconv.c
> >> F: kernel/time/timecounter.c
> >> F: kernel/time/timekeeping*
> >> F: kernel/time/time_test.c
> >> +F: rust/kernel/time.rs
> >> +F: rust/kernel/time/
> >> F: tools/testing/selftests/timers/
> >>
> >> TIPC NETWORK LAYER
> >>
> >> This will help future contributers copy the correct people while
> >> submission. Could you maybe add a patch of this in your series if this
> >> sounds reasonable to you? Thanks!
> >
> > Agreed that it's better to have Rust time abstractions in
> > MAINTAINERS. You add it into the time entry but there are two options
> > in the file; time and timer?
> >
> > TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
> > M: John Stultz <jstultz@google.com>
> > M: Thomas Gleixner <tglx@linutronix.de>
> > R: Stephen Boyd <sboyd@kernel.org>
> >
> > HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
> > M: Anna-Maria Behnsen <anna-maria@linutronix.de>
> > M: Frederic Weisbecker <frederic@kernel.org>
> > M: Thomas Gleixner <tglx@linutronix.de>
> >
> > The current Rust abstractions which play mainly with ktimer.h. it's
> > not time, timer stuff, I think.
>
> Oops, s/ktimer.h/ktime.h/
>
> No entry for ktime.h in MAINTAINERS; used by both time and timer
> stuff.
>
I think ktime.h belongs to TIMEKEEPING, since ktime_get() is defined in
kernel/time/timekeeping.c and that's a core function for ktime_t, but
you're not wrong that there is no entry of ktime.h in MAINTAINERS, so if
you want to wait for or check with Thomas, feel free.
> > As planned, we'll move *.rs files from rust/kernel in the future,
> > how we handle time and timer abstractions?
I don't think core stuffs will be moved from rust/kernel, i.e. anything
correspond to the concepts defined in kernel/ directory probably stays
in rust/kernel, so time and timer fall into that category.
>
> Looks like that we'll add rust/kernel/hrtimer/ soon. I feel that it's
> better to decide on the layout of time and timer abstractions now
> rather than later.
I already suggested we move hrtimer.rs into rust/kernel/time to match
the hierarchy of the counterpart in C (kernel/time/hrtimer.c):
https://lore.kernel.org/rust-for-linux/ZwqTf-6xaASnIn9l@boqun-archlinux/
Regards,
Boqun
On Sat, 12 Oct 2024 20:16:44 -0700
Boqun Feng <boqun.feng@gmail.com> wrote:
> On Sun, Oct 13, 2024 at 11:50:33AM +0900, FUJITA Tomonori wrote:
>> On Sun, 13 Oct 2024 10:15:05 +0900 (JST)
>> FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:
>>
>> > On Sat, 12 Oct 2024 08:29:06 -0700
>> > Boqun Feng <boqun.feng@gmail.com> wrote:
>> >
>> >> While, we are at it, I want to suggest that we also add
>> >> rust/kernel/time{.rs, /} into the "F:" entries of TIME subsystem like:
>> >>
>> >> diff --git a/MAINTAINERS b/MAINTAINERS
>> >> index b77f4495dcf4..09e46a214333 100644
>> >> --- a/MAINTAINERS
>> >> +++ b/MAINTAINERS
>> >> @@ -23376,6 +23376,8 @@ F: kernel/time/timeconv.c
>> >> F: kernel/time/timecounter.c
>> >> F: kernel/time/timekeeping*
>> >> F: kernel/time/time_test.c
>> >> +F: rust/kernel/time.rs
>> >> +F: rust/kernel/time/
>> >> F: tools/testing/selftests/timers/
>> >>
>> >> TIPC NETWORK LAYER
>> >>
>> >> This will help future contributers copy the correct people while
>> >> submission. Could you maybe add a patch of this in your series if this
>> >> sounds reasonable to you? Thanks!
>> >
>> > Agreed that it's better to have Rust time abstractions in
>> > MAINTAINERS. You add it into the time entry but there are two options
>> > in the file; time and timer?
>> >
>> > TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
>> > M: John Stultz <jstultz@google.com>
>> > M: Thomas Gleixner <tglx@linutronix.de>
>> > R: Stephen Boyd <sboyd@kernel.org>
>> >
>> > HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
>> > M: Anna-Maria Behnsen <anna-maria@linutronix.de>
>> > M: Frederic Weisbecker <frederic@kernel.org>
>> > M: Thomas Gleixner <tglx@linutronix.de>
>> >
>> > The current Rust abstractions which play mainly with ktimer.h. it's
>> > not time, timer stuff, I think.
>>
>> Oops, s/ktimer.h/ktime.h/
>>
>> No entry for ktime.h in MAINTAINERS; used by both time and timer
>> stuff.
>>
>
> I think ktime.h belongs to TIMEKEEPING, since ktime_get() is defined in
> kernel/time/timekeeping.c and that's a core function for ktime_t, but
Sounds reasonable.
This patchset adds Delta (also belongs to time, I guess) and fsleep to
rust/kernel/time.rs. I think that fsleep belongs to timer (because
sleep functions in kernel/time/timer.c). It's better to add
rust/kerne/time/timer.rs for fsleep() rather than putting both time
and timer stuff to rust/kernel/time.rs?
> you're not wrong that there is no entry of ktime.h in MAINTAINERS, so if
> you want to wait for or check with Thomas, feel free.
>
>> > As planned, we'll move *.rs files from rust/kernel in the future,
>> > how we handle time and timer abstractions?
>
> I don't think core stuffs will be moved from rust/kernel, i.e. anything
> correspond to the concepts defined in kernel/ directory probably stays
> in rust/kernel, so time and timer fall into that category.
Seems that I misunderstood. The plan for the future layout is
documented somewhere?
>> Looks like that we'll add rust/kernel/hrtimer/ soon. I feel that it's
>> better to decide on the layout of time and timer abstractions now
>> rather than later.
>
> I already suggested we move hrtimer.rs into rust/kernel/time to match
> the hierarchy of the counterpart in C (kernel/time/hrtimer.c):
>
> https://lore.kernel.org/rust-for-linux/ZwqTf-6xaASnIn9l@boqun-archlinux/
Sounds good.
On Sun, Oct 13, 2024 at 02:15:06PM +0900, FUJITA Tomonori wrote:
> On Sat, 12 Oct 2024 20:16:44 -0700
> Boqun Feng <boqun.feng@gmail.com> wrote:
>
> > On Sun, Oct 13, 2024 at 11:50:33AM +0900, FUJITA Tomonori wrote:
> >> On Sun, 13 Oct 2024 10:15:05 +0900 (JST)
> >> FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:
> >>
> >> > On Sat, 12 Oct 2024 08:29:06 -0700
> >> > Boqun Feng <boqun.feng@gmail.com> wrote:
> >> >
> >> >> While, we are at it, I want to suggest that we also add
> >> >> rust/kernel/time{.rs, /} into the "F:" entries of TIME subsystem like:
> >> >>
> >> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> >> index b77f4495dcf4..09e46a214333 100644
> >> >> --- a/MAINTAINERS
> >> >> +++ b/MAINTAINERS
> >> >> @@ -23376,6 +23376,8 @@ F: kernel/time/timeconv.c
> >> >> F: kernel/time/timecounter.c
> >> >> F: kernel/time/timekeeping*
> >> >> F: kernel/time/time_test.c
> >> >> +F: rust/kernel/time.rs
> >> >> +F: rust/kernel/time/
> >> >> F: tools/testing/selftests/timers/
> >> >>
> >> >> TIPC NETWORK LAYER
> >> >>
> >> >> This will help future contributers copy the correct people while
> >> >> submission. Could you maybe add a patch of this in your series if this
> >> >> sounds reasonable to you? Thanks!
> >> >
> >> > Agreed that it's better to have Rust time abstractions in
> >> > MAINTAINERS. You add it into the time entry but there are two options
> >> > in the file; time and timer?
> >> >
> >> > TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
> >> > M: John Stultz <jstultz@google.com>
> >> > M: Thomas Gleixner <tglx@linutronix.de>
> >> > R: Stephen Boyd <sboyd@kernel.org>
> >> >
> >> > HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
> >> > M: Anna-Maria Behnsen <anna-maria@linutronix.de>
> >> > M: Frederic Weisbecker <frederic@kernel.org>
> >> > M: Thomas Gleixner <tglx@linutronix.de>
> >> >
> >> > The current Rust abstractions which play mainly with ktimer.h. it's
> >> > not time, timer stuff, I think.
> >>
> >> Oops, s/ktimer.h/ktime.h/
> >>
> >> No entry for ktime.h in MAINTAINERS; used by both time and timer
> >> stuff.
> >>
> >
> > I think ktime.h belongs to TIMEKEEPING, since ktime_get() is defined in
> > kernel/time/timekeeping.c and that's a core function for ktime_t, but
>
> Sounds reasonable.
>
> This patchset adds Delta (also belongs to time, I guess) and fsleep to
> rust/kernel/time.rs. I think that fsleep belongs to timer (because
> sleep functions in kernel/time/timer.c). It's better to add
> rust/kerne/time/timer.rs for fsleep() rather than putting both time
> and timer stuff to rust/kernel/time.rs?
>
Good point. So how about putting fsleep() into rusk/kernel/time/delay.rs
and add that into the "F:" entry of TIMER subsystem? Since "sleep"s are
a set of particular usage of timers which don't directly interact with a
timer or hrtimer struct, so I feel it's better to have their own
file/mod rather than sharing it with timers. Plus this results in less
potential conflicts with Andreas' hrtimer series.
Regards,
Boqun
[...]
On Mon, 14 Oct 2024 14:18:57 -0700 Boqun Feng <boqun.feng@gmail.com> wrote: >> This patchset adds Delta (also belongs to time, I guess) and fsleep to >> rust/kernel/time.rs. I think that fsleep belongs to timer (because >> sleep functions in kernel/time/timer.c). It's better to add >> rust/kerne/time/timer.rs for fsleep() rather than putting both time >> and timer stuff to rust/kernel/time.rs? >> > > Good point. So how about putting fsleep() into rusk/kernel/time/delay.rs > and add that into the "F:" entry of TIMER subsystem? Since "sleep"s are > a set of particular usage of timers which don't directly interact with a > timer or hrtimer struct, so I feel it's better to have their own > file/mod rather than sharing it with timers. Plus this results in less > potential conflicts with Andreas' hrtimer series. Sure. I'll go with rust/kernel/time/delay.rs.
On Sun, Oct 13, 2024 at 7:15 AM FUJITA Tomonori <fujita.tomonori@gmail.com> wrote: > > Seems that I misunderstood. The plan for the future layout is > documented somewhere? Not yet, but I think either would be fine. Cheers, Miguel
© 2016 - 2024 Red Hat, Inc.