Re: [PATCH RFC 02/20] rust_binder: add binderfs support to Rust binder

[Boqun Feng <boqun.feng@gmail.com>]

On Fri, Nov 03, 2023 at 04:30:54PM +0000, Benno Lossin wrote:
> On 01.11.23 19:01, Alice Ryhl wrote:
> > +/// There is one context per binder file (/dev/binder, /dev/hwbinder, etc)
> > +#[pin_data]
> > +pub(crate) struct Context {
> > +    #[pin]
> > +    manager: Mutex<Manager>,
> > +    pub(crate) name: CString,
> > +    #[pin]
> > +    links: ListLinks,
> > +}
> > +
> > +kernel::list::impl_has_list_links! {
> > +    impl HasListLinks<0> for Context { self.links }
> > +}
> > +kernel::list::impl_list_arc_safe! {
> > +    impl ListArcSafe<0> for Context { untracked; }
> > +}
> > +kernel::list::impl_list_item! {
> > +    impl ListItem<0> for Context {
> > +        using ListLinks;
> > +    }
> > +}
> 
> I think at some point it would be worth introducing a derive macro that
> does this for us. So for example:

Agreed.

> 
>     #[pin_data]
>     #[derive(HasListLinks)]
>     pub(crate) struct Context {
>         #[pin]
>         manager: Mutex<Manager>,
>         pub(crate) name: CString,
>         #[pin]
>         #[links]
>         links: ListLinks,
>     }
> 
> And if you need multiple links you could do:
> 
>     #[pin_data]
>     #[derive(HasListLinks)]
>     struct Foo {
>         #[links = 0]
>         a_list: ListLinks,

we will need more discussion on how the derive syntax would look like,
but I'd expect we can reference the field with names instead of numbers
if we use derive macros. In other words type numbering to distinguish
different fields should be an implementation detail.

Regards,
Boqun

>         #[links = 1]
>         b_list: ListLinks,
>     }
> 
> Same for `ListItem` and `HasWork`. I have not yet taken a look at your
> linked list implementation, so I don't know if this is possible (since
> `ListItem` seems to have multiple "backends").
> 
> I think this improvement can wait though, just wanted to mention it.
> 
> -- 
> Cheers,
> Benno
>