public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Benno Lossin" <lossin@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 00/15] `syn` rewrite of pin-init
Date: Wed, 14 Jan 2026 16:48:20 +0100	[thread overview]
Message-ID: <87o6mwfb5n.fsf@kernel.org> (raw)
In-Reply-To: <20260111122554.2662175-1-lossin@kernel.org>

"Benno Lossin" <lossin@kernel.org> writes:

> Rewrite the proc-macros of pin-init by using the `syn` crate for Rust
> syntax parsing. This series has been a long way coming. At the very
> start of pin-init, I initially implemented everything using syn, since
> parsing is so much easier with it. Now after several years it is finally
> time to remove the dreaded 1600 lines of declarative macros required to
> parse and expand the initializer syntax.
>
> The move to syn is not only a blessing for the maintenance work, but
> also improves the implementation of new features. This series includes
> many such improvements.
>
> * Patch 1, 2, 3 and 4 prepare for the rewrite. The first removes the
>   superfluous `try_` variants of the initializer macros from pin-init.
>   Note that the kernel defines its own, so no code changes in the kernel
>   are required. The second patch allows using `::pin_init` in the
>   pin-init crate. The third adds the syn dependency and cleans up some
>   old workarounds and new clippy warnings. The fourth adds better error
>   handling on top of `syn`.
> * Patch 5, 6, 7, and 9 rewrite the derive macros for Zeroable,
>   `#[pinned_drop]` attribute macro, `#[pin_data]` attribute macro, and
>   the initializer macros respectively using `syn`.
> * Patch 8 ensures soundness in the future by fixing generic bounds in
>   generated code by `#[pin_data]`.
> * Patch 10 adds the `#[default_error(type)]` attribute to initializer
>   macros allowing them to specify a default error that is used when no
>   error is manually specified.
> * Patch 11 uses `#[default_error(type)]` in the definition of the
>   kernel's `try_` variants of the initializer macros (which defaults to
>   the kernel's `Error` type).
> * Patch 12 allows putting attributes on fields in initializer macros
>   (for example `cfg` attributes).
> * Patch 13 adds `#[disable_initialized_field_access]` to support packed
>   structs.
> * Patch 14 simplifies the code generated by the initializer macros.
> * Patch 15 adds Gary as a maintainer.
>
> In addition to the new features, using syn results in much cleaner error
> messages and more accurate span information. The code is much easier to
> read as well and hopefully easier to understand as well.
>
> As always, tests that ensure the correctness of the macro output are
> included and updated in the upstream pin-init repository. Take a look at
> the pull request on GitHub for the diff in the test output:
>
>     https://github.com/Rust-for-Linux/pin-init/pull/89
>
> I would greatly appreciate Tested-by's from people actively using
> pin-init weather in the kernel or outside.
>
> One thing I forgot to mention last time: the commit adding syn support
> to pin-init is also used by Gary's series to rewrite the `macros` crate
> using `syn`:
>
>     https://lore.kernel.org/all/20260107161729.3855851-1-gary@kernel.org
>
> My series can be found at:
>
>     https://github.com/BennoLossin/linux/commits/pin-init/sync
>
> The rust-dev branch in the RfL repository will be updated to contain
> both patch series for ease of use & testing.
>
> Link to v1:
>
>     https://lore.kernel.org/all/20260108135127.3153925-1-lossin@kernel.org
>
> Cheers,
> Benno

Tested with downstream rust null block driver on v6.19-rc5 [1]. No issues encountered, and
conditional fields now work, yay!

    #[pin_data]
    struct NullBlkDevice {
        ...
        #[cfg(CONFIG_BLK_DEV_ZONED)]
        #[pin]
        zoned: zoned::ZoneOptions,
    }

    try_pin_init!(Self {
        ...
        #[cfg(CONFIG_BLK_DEV_ZONED)]
        zoned <- zoned::ZoneOptions::new(
            zoned,
            device_capacity_mib,
            *block_size_bytes,
            zone_size_mib,
            zone_capacity_mib,
            zone_nr_conv,
            zone_max_open,
            zone_max_active,
            zone_append_max_sectors,
        )?,
    }),


Tested-by: Andreas Hindborg <a.hindborg@kernel.org>


Best regards,
Andreas Hindborg


[1] https://github.com/metaspace/linux/tree/rnull-v6.19-rc5


      parent reply	other threads:[~2026-01-14 15:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0_JVrevJeDexgBCPJKUDqVKcopDMZyU-kLN9o-1502Av94rIL4O1fyItT1kC8-P0J9FbvciiNqZWf9lzMq6fUg==@protonmail.internalid>
2026-01-11 12:24 ` [PATCH v2 00/15] `syn` rewrite of pin-init Benno Lossin
2026-01-11 12:24   ` [PATCH v2 01/15] rust: pin-init: remove `try_` versions of the initializer macros Benno Lossin
2026-01-12 12:57     ` Gary Guo
2026-01-11 12:25   ` [PATCH v2 02/15] rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests Benno Lossin
2026-01-12 15:55     ` Gary Guo
2026-01-11 12:25   ` [PATCH v2 03/15] rust: pin-init: add `syn` dependency and remove `proc-macro[2]` and `quote` workarounds Benno Lossin
2026-01-11 12:25   ` [PATCH v2 04/15] rust: pin-init: internal: add utility API for syn error handling Benno Lossin
2026-01-12 16:14     ` Gary Guo
2026-01-13  8:17       ` Benno Lossin
2026-01-11 12:25   ` [PATCH v2 05/15] rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn` Benno Lossin
2026-01-11 12:25   ` [PATCH v2 06/15] rust: pin-init: rewrite the `#[pinned_drop]` attribute macro " Benno Lossin
2026-01-11 12:25   ` [PATCH v2 07/15] rust: pin-init: rewrite `#[pin_data]` " Benno Lossin
2026-01-11 12:25   ` [PATCH v2 08/15] rust: pin-init: add `?Sized` bounds to traits in `#[pin_data]` macro Benno Lossin
2026-01-11 12:25   ` [PATCH v2 09/15] rust: pin-init: rewrite the initializer macros using `syn` Benno Lossin
2026-01-11 12:25   ` [PATCH v2 10/15] rust: pin-init: add `#[default_error(<type>)]` attribute to initializer macros Benno Lossin
2026-01-11 12:25   ` [PATCH v2 11/15] rust: init: use `#[default_error(err)]` for the " Benno Lossin
2026-01-12 19:14     ` Gary Guo
2026-01-11 12:25   ` [PATCH v2 12/15] rust: pin-init: internal: init: add support for attributes on initializer fields Benno Lossin
2026-01-11 12:25   ` [PATCH v2 13/15] rust: pin-init: internal: init: add escape hatch for referencing initialized fields Benno Lossin
2026-01-11 12:25   ` [PATCH v2 14/15] rust: pin-init: internal: init: simplify Zeroable safety check Benno Lossin
2026-01-12 19:13     ` Gary Guo
2026-01-11 12:25   ` [PATCH v2 15/15] MAINTAINERS: add Gary Guo to pin-init Benno Lossin
2026-01-14 15:48   ` Andreas Hindborg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o6mwfb5n.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox