Re: [RFC PATCH 0/7] Introduce HasField infrastructure

[Boqun Feng <boqun@kernel.org>]

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
> 
[..]