linux-kernel - Re: [PATCH net-next v2 0/6] rust: Add IO polling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zw2KwQbAAKZ_5lPL@boqun-archlinux>
Date: Mon, 14 Oct 2024 14:18:57 -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 02:15:06PM +0900, FUJITA Tomonori wrote:
> On Sat, 12 Oct 2024 20:16:44 -0700
> Boqun Feng <boqun.feng@...il.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@...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
> 
> 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

[...]