[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zws7nK549LWOccEj@Boquns-Mac-mini.local>
Date: Sat, 12 Oct 2024 20:16:44 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, andrew@...n.ch,
hkallweit1@...il.com, tmgross@...ch.edu, ojeda@...nel.org,
alex.gaynor@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
benno.lossin@...ton.me, a.hindborg@...sung.com,
aliceryhl@...gle.com, anna-maria@...utronix.de, frederic@...nel.org,
tglx@...utronix.de, arnd@...db.de, linux-kernel@...r.kernel.org,
jstultz@...gle.com, sboyd@...nel.org
Subject: Re: [PATCH net-next v2 0/6] rust: Add IO polling
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@...il.com> wrote:
>
> > On Sat, 12 Oct 2024 08:29:06 -0700
> > Boqun Feng <boqun.feng@...il.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@...gle.com>
> > M: Thomas Gleixner <tglx@...utronix.de>
> > R: Stephen Boyd <sboyd@...nel.org>
> >
> > HIGH-RESOLUTION TIMERS, TIMER WHEEL, CLOCKEVENTS
> > M: Anna-Maria Behnsen <anna-maria@...utronix.de>
> > M: Frederic Weisbecker <frederic@...nel.org>
> > M: Thomas Gleixner <tglx@...utronix.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
Powered by blists - more mailing lists