On Fri, Oct 03, 2025 at 06:34:12PM +0200, Benno Lossin wrote:
> On Thu Oct 2, 2025 at 3:49 PM CEST, Alexandre Courbot wrote:
> > Hi Alistair, (+Benno as this concerns the `init!` macros)
> >
> > On Tue Sep 30, 2025 at 10:16 PM JST, Alistair Popple wrote:
> >> Adds bindings and an in-place initialiser for the GspSystemInfo struct.
> >>
> >> Signed-off-by: Alistair Popple <[email protected]>
> >>
> >> ---
> >>
> >> It would be good to move to using the `init!` macros at some point, but
> >> I couldn't figure out how to make that work to initialise an enum rather
> >> than a struct as is required for the transparent representation.
> >
> > Indeed we have to jump through a few (minor) hoops.
> >
> > First the `init!` macros do not seem to support tuple structs. They
> > match a `{` after the type name, which is not present in
> > `GspSystemInfo`. By turning it into a regular struct with a single
> > field, we can overcome this, and it doesn't affect the layout the
> > `#[repr(transparent)]` can still be used.
> 
> Yeah that's the correct workaround at the moment. I'm tracking support
> for tuple structs in [1]. Essentially the problem is that it requires
> lots of effort to parse tuple structs using declarative macros. We will
> get `syn` this cycle, which will enable me to support several things,
> including tuple structs.
> 
> [1]: https://github.com/Rust-for-Linux/pin-init/issues/85
> 
> > Then, due to a limitation with declarative macros, `init!` interprets
> > `::` as a separator for generic arguments, so `bindings::GspSystemInfo`
> > also doesn't parse. Here the trick is to use a local type alias.
> 
> This one will also be solved when we switch to syn.

I was planning to submit
https://github.com/AsahiLinux/linux/commit/2d95fd3b6c359634a0976f27f7a3c667826256da
https://github.com/AsahiLinux/linux/commit/515638cb47cf0ebdac378686fcbbdc6a8364096a
from the asahi downstream tree after 6.18-rc1. Does that still make
sense timing wise?

Types with type paths are used extensively in the asahi driver but I can
initially work around that.

Janne

Reply via email to