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