[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250403.080334.1462587538453396496.fujita.tomonori@gmail.com>
Date: Thu, 03 Apr 2025 08:03:34 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: boqun.feng@...il.com
Cc: fujita.tomonori@...il.com, a.hindborg@...nel.org, tglx@...utronix.de,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
netdev@...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, arnd@...db.de, jstultz@...gle.com, sboyd@...nel.org,
mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com, rostedt@...dmis.org,
bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com,
tgunders@...hat.com, me@...enk.dev, david.laight.linux@...il.com
Subject: Re: [PATCH v11 6/8] MAINTAINERS: rust: Add new sections for
DELAY/SLEEP and TIMEKEEPING API
On Wed, 2 Apr 2025 09:29:18 -0700
Boqun Feng <boqun.feng@...il.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@...il.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@...nel.org>
>> >
>> > Given you're the one who would handle the patches, I think this make
>> > more sense.
>> >
>> >> R: Boqun Feng <boqun.feng@...il.com>
>> >> R: FUJITA Tomonori <fujita.tomonori@...il.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.
Powered by blists - more mailing lists