Message-ID: <aYUB4VcsSDyQxSt1@tardis.local>
Date: Thu, 5 Feb 2026 12:47:29 -0800
From: Boqun Feng <boqun@...nel.org>
To: Gary Guo <gary@...yguo.net>
Cc: Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org, rcu@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Todd Kjos <tkjos@...roid.com>,	Christian Brauner <brauner@...nel.org>,
	Carlos Llamas <cmllamas@...gle.com>,	Alice Ryhl <aliceryhl@...gle.com>,
 Miguel Ojeda <ojeda@...nel.org>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,	Danilo Krummrich <dakr@...nel.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Josh Triplett <josh@...htriplett.org>,
	Uladzislau Rezki <urezki@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,	Zqiang <qiang.zhang@...ux.dev>,
	FUJITA Tomonori <fujita.tomonori@...il.com>,
	Lyude Paul <lyude@...hat.com>, Thomas Gleixner <tglx@...nel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	John Stultz <jstultz@...gle.com>, Stephen Boyd <sboyd@...nel.org>,
	"Yury Norov (NVIDIA)" <yury.norov@...il.com>,
	Vitaly Wool <vitaly.wool@...sulko.se>,
	Tamir Duberstein <tamird@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Mitchell Levy <levymitchell0@...il.com>,	David Gow <davidgow@...gle.com>,
 Peter Novak <seimun018r@...il.com>,
	José Expósito <jose.exposito89@...il.com>
Subject: Re: [RFC PATCH 0/7] Introduce HasField infrastructure

On Wed, Feb 04, 2026 at 02:20:09PM +0000, Gary Guo wrote:
> On Wed Jan 28, 2026 at 9:53 PM GMT, Boqun Feng wrote:
> > Currently we have a few similar places where we use a `Has*` trait to
> > describe that a data structure has some types of field in it so that the
> > containing type can do something with it. There are also a `impl_has_*!`
> > macro to help implement the trait. While it's working, but it's less
> > ergonomic to me, especially considering the amount of the work we need
> > to do for something new (e.g. rcu_head).
> >
> > Therefore here is the effort to unify them into a proc-macro based
> > solution. `Field` and `HasField` traits are introduced to generify the
> > "Has A" relationship, and a derive macro `#[derive(HasField)]` is also
> > added to support automatically implementing `HasField` trait.
> >
> > This series convert a few users (Work, HrTimer) and introduce a new
> > `Field` type `RcuHead`. These improvements demonstrate how this
> > infrastructure can be used.
> >
> > Some future work is still needed: using `HasField` for `DelayedWork` and
> > `ListLink` is still missing. Also it's possible to clean up `HasWork`
> > trait as well.
> >
> > One known issue is that `#[derive(HasField)]` doesn't play alone with
> > `#[pin_data]` at the moment, for example:
> >
> >     #[derive(HasField)]
> >     #[pin_data]
> >     struct Foo { .. }
> >
> > works, but 
> >
> >     #[pin_data]
> >     #[derive(HasField)]
> >     struct Foo { .. }
> >
> > doesn't. Maybe it's by design or maybe something could be improved by
> > pin-init.
> >
> >
> > The patchset is based on today's rust/rust-next, top commit is:
> >
> > 	a7c013f77953 ('Merge patch series "refactor Rust proc macros with `syn`"')
> >
> > Regards,
> > Boqun
> 
> Hi Boqun,
> 
> Thanks for working on this.
> 
> You currently divide things into two traits, `Field<T>` which doesn't seem to be
> doing anything (actually, why does this need to exist at all?) and
> `HasField<T, F>` which defines all the field projection.
> 

Oh, you're right, I don't need `Field<T>` right now. In a certain point,
it was used to constrain all "field types" must be generic over their
container type. But it's not the case now (see RcuHead).

> For some prior art that attempts to have fields, e.g. my field-projection
> experiemnt crate
> 
>     https://docs.rs/field-projection
> 
> and Benno's work on field-representing-types in the Rust language, we opt to
> have a type to represent each field instead.
> 
> I think we should have a unified projection infrastructure in the kernel, for
> both intrusive data structure and I/O projection and others, so I think it's
> useful to have types representing fields (and projection in general, this could
> also extend to the `register!` macro). For clarity, let me refer to this as
> `field_of!(Base, foo)` and the trait is `Projection`.
> 

Yep, I actually have an example PR integrating that into workqueue:

	https://github.com/Rust-for-Linux/field-projection/pull/2

(of course `Work` in that case should be generic over the containing
type, but that's easy to fix)

I guess the next question is: will you and Benno be willing to port
field-projection into kernel source (and keep it aligned with the
language feature), so we can switch to that?

Regards,
Boqun

> With this infra, the `HasField` trait would simply looks like this:
> 
>     trait HasField<Base, FieldType> {
>         type Field: Projection<Base = Base, Type = FieldType>;
>     }
> 
> and the macro derive would generate something like
> 
>     impl HasField<MyStruct, Work<MyStruct>> {
>         type Field = field_of!(MyStruct, name_of_work_field);
>     }
> 
> Best,
> Gary
> 
[..]

Powered by blists - more mailing lists