Message-Id: <DG68S0UN78BE.QUG4A0Y08XKN@garyguo.net>
Date: Wed, 04 Feb 2026 14:20:09 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Boqun Feng" <boqun.feng@...il.com>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <rcu@...r.kernel.org>
Cc: "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>, "Gary Guo" <gary@...yguo.net>,
 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 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.

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`.

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







>
> Boqun Feng (7):
>   rust: types: Introduce HasField trait and derive macro
>   rust: time: hrtimer: Make `HasField` a super-trait of `HasHrTimer`
>   rust: workqueue: Add HasField support for Work
>   drivers: android: binder: Replace `impl_has_work!` with
>     `#[derive(HasField)]`
>   rust: sync: Completion: Replace `impl_has_work!` with
>     `#[derive(HasField)]`
>   rust: work: Remove `impl_has_work!`
>   rust: sync: rcu: Introduce RcuHead
>
>  drivers/android/binder/process.rs |   6 +-
>  rust/kernel/field.rs              |  73 ++++++++++++++++++++
>  rust/kernel/lib.rs                |   1 +
>  rust/kernel/prelude.rs            |   4 +-
>  rust/kernel/sync/completion.rs    |   8 +--
>  rust/kernel/sync/rcu.rs           |  69 ++++++++++++++++++-
>  rust/kernel/time/hrtimer.rs       |  70 ++++---------------
>  rust/kernel/workqueue.rs          | 109 +++++++++++-------------------
>  rust/macros/field.rs              |  85 +++++++++++++++++++++++
>  rust/macros/lib.rs                |  11 +++
>  10 files changed, 299 insertions(+), 137 deletions(-)
>  create mode 100644 rust/kernel/field.rs
>  create mode 100644 rust/macros/field.rs

Powered by blists - more mailing lists