rust/Makefile | 9 ++++++--- rust/ffi.rs | 7 +++++++ rust/kernel/acpi.rs | 2 +- rust/kernel/cpufreq.rs | 2 +- rust/kernel/i2c.rs | 4 ++-- 5 files changed, 17 insertions(+), 7 deletions(-)
Currently, the Zeroable trait is defined by pin-init because pin-init
happens to use the trait. However, zeroed types are useful for many
purposes other than pin-init. Also, we wish to implement Zeroable for
types generated by bindgen. For both of these reasons, re-export
Zeroable from the ffi crate, which is a already dependency of the crates
with bindgen output.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Alice Ryhl (4):
rust: ffi: reexport Zeroable and related items
rust: cpufreq: import pin_init::zeroed() from ffi
rust: i2c: import pin_init::zeroed() from ffi
rust: acpi: import pin_init::zeroed() from ffi
rust/Makefile | 9 ++++++---
rust/ffi.rs | 7 +++++++
rust/kernel/acpi.rs | 2 +-
rust/kernel/cpufreq.rs | 2 +-
rust/kernel/i2c.rs | 4 ++--
5 files changed, 17 insertions(+), 7 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251202-zeroable-ffi-2beb542376c3
Best regards,
--
Alice Ryhl <aliceryhl@google.com>
On Mon Jan 26, 2026 at 1:05 PM GMT, Alice Ryhl wrote: > Currently, the Zeroable trait is defined by pin-init because pin-init > happens to use the trait. However, zeroed types are useful for many > purposes other than pin-init. Also, we wish to implement Zeroable for > types generated by bindgen. For both of these reasons, re-export > Zeroable from the ffi crate, which is a already dependency of the crates > with bindgen output. I don't see a benefit of re-exporting these from the `ffi` crate? Especially that we re-export `ffi` crate from kernel crate anyway, and `Zeroable` is already in the kernel prelude. We already derive `Zeroable` for bindgen via `MaybeZeroable` derive in rust/bindgen_parameters. Best, Gary > > Signed-off-by: Alice Ryhl <aliceryhl@google.com> > --- > Alice Ryhl (4): > rust: ffi: reexport Zeroable and related items > rust: cpufreq: import pin_init::zeroed() from ffi > rust: i2c: import pin_init::zeroed() from ffi > rust: acpi: import pin_init::zeroed() from ffi > > rust/Makefile | 9 ++++++--- > rust/ffi.rs | 7 +++++++ > rust/kernel/acpi.rs | 2 +- > rust/kernel/cpufreq.rs | 2 +- > rust/kernel/i2c.rs | 4 ++-- > 5 files changed, 17 insertions(+), 7 deletions(-) > --- > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 > change-id: 20251202-zeroable-ffi-2beb542376c3 > > Best regards,
On Mon, Jan 26, 2026 at 01:15:53PM +0000, Gary Guo wrote: > On Mon Jan 26, 2026 at 1:05 PM GMT, Alice Ryhl wrote: > > Currently, the Zeroable trait is defined by pin-init because pin-init > > happens to use the trait. However, zeroed types are useful for many > > purposes other than pin-init. Also, we wish to implement Zeroable for > > types generated by bindgen. For both of these reasons, re-export > > Zeroable from the ffi crate, which is a already dependency of the crates > > with bindgen output. > > I don't see a benefit of re-exporting these from the `ffi` crate? Especially > that we re-export `ffi` crate from kernel crate anyway, and `Zeroable` is > already in the kernel prelude. > > We already derive `Zeroable` for bindgen via `MaybeZeroable` derive in > rust/bindgen_parameters. I can't find the convo now, but this change is on my list from when we discussed also implementing FromBytes / IntoBytes for the bindings types. To do that, we need to move our FromBytes / IntoBytes traits somewhere that bindings/uapi can access, and we agreed that the ffi crate was a good place for it. And then for consistency, also reexport Zeroable from the same location. Alice
On Mon Jan 26, 2026 at 2:25 PM CET, Alice Ryhl wrote: > On Mon, Jan 26, 2026 at 01:15:53PM +0000, Gary Guo wrote: >> On Mon Jan 26, 2026 at 1:05 PM GMT, Alice Ryhl wrote: >> > Currently, the Zeroable trait is defined by pin-init because pin-init >> > happens to use the trait. However, zeroed types are useful for many >> > purposes other than pin-init. Also, we wish to implement Zeroable for >> > types generated by bindgen. For both of these reasons, re-export >> > Zeroable from the ffi crate, which is a already dependency of the crates >> > with bindgen output. >> >> I don't see a benefit of re-exporting these from the `ffi` crate? Especially >> that we re-export `ffi` crate from kernel crate anyway, and `Zeroable` is >> already in the kernel prelude. >> >> We already derive `Zeroable` for bindgen via `MaybeZeroable` derive in >> rust/bindgen_parameters. > > I can't find the convo now, but this change is on my list from when we > discussed also implementing FromBytes / IntoBytes for the bindings > types. To do that, we need to move our FromBytes / IntoBytes traits > somewhere that bindings/uapi can access, and we agreed that the ffi > crate was a good place for it. > > And then for consistency, also reexport Zeroable from the same location. I think you also mentioned at some point that using `pin_init` from `bindings` seemed strange and also using the `pin_init::zeroed()` function also doesn't fit, since it doesn't have to do with pinned initialization. Cheers, Benno
On Mon Jan 26, 2026 at 4:08 PM GMT, Benno Lossin wrote: > On Mon Jan 26, 2026 at 2:25 PM CET, Alice Ryhl wrote: >> On Mon, Jan 26, 2026 at 01:15:53PM +0000, Gary Guo wrote: >>> On Mon Jan 26, 2026 at 1:05 PM GMT, Alice Ryhl wrote: >>> > Currently, the Zeroable trait is defined by pin-init because pin-init >>> > happens to use the trait. However, zeroed types are useful for many >>> > purposes other than pin-init. Also, we wish to implement Zeroable for >>> > types generated by bindgen. For both of these reasons, re-export >>> > Zeroable from the ffi crate, which is a already dependency of the crates >>> > with bindgen output. >>> >>> I don't see a benefit of re-exporting these from the `ffi` crate? Especially >>> that we re-export `ffi` crate from kernel crate anyway, and `Zeroable` is >>> already in the kernel prelude. >>> >>> We already derive `Zeroable` for bindgen via `MaybeZeroable` derive in >>> rust/bindgen_parameters. >> >> I can't find the convo now, but this change is on my list from when we >> discussed also implementing FromBytes / IntoBytes for the bindings >> types. To do that, we need to move our FromBytes / IntoBytes traits >> somewhere that bindings/uapi can access, and we agreed that the ffi >> crate was a good place for it. >> >> And then for consistency, also reexport Zeroable from the same location. > > I think you also mentioned at some point that using `pin_init` from > `bindings` seemed strange and also using the `pin_init::zeroed()` > function also doesn't fit, since it doesn't have to do with pinned > initialization. Shouldn't it be that a crate that implements Zeroable / FromBytes / IntoBytes and then pin_init becoming an user of that crate, then? Best, Gary
On Mon, Jan 26, 2026 at 5:11 PM Gary Guo <gary@garyguo.net> wrote: > > On Mon Jan 26, 2026 at 4:08 PM GMT, Benno Lossin wrote: > > On Mon Jan 26, 2026 at 2:25 PM CET, Alice Ryhl wrote: > >> On Mon, Jan 26, 2026 at 01:15:53PM +0000, Gary Guo wrote: > >>> On Mon Jan 26, 2026 at 1:05 PM GMT, Alice Ryhl wrote: > >>> > Currently, the Zeroable trait is defined by pin-init because pin-init > >>> > happens to use the trait. However, zeroed types are useful for many > >>> > purposes other than pin-init. Also, we wish to implement Zeroable for > >>> > types generated by bindgen. For both of these reasons, re-export > >>> > Zeroable from the ffi crate, which is a already dependency of the crates > >>> > with bindgen output. > >>> > >>> I don't see a benefit of re-exporting these from the `ffi` crate? Especially > >>> that we re-export `ffi` crate from kernel crate anyway, and `Zeroable` is > >>> already in the kernel prelude. > >>> > >>> We already derive `Zeroable` for bindgen via `MaybeZeroable` derive in > >>> rust/bindgen_parameters. > >> > >> I can't find the convo now, but this change is on my list from when we > >> discussed also implementing FromBytes / IntoBytes for the bindings > >> types. To do that, we need to move our FromBytes / IntoBytes traits > >> somewhere that bindings/uapi can access, and we agreed that the ffi > >> crate was a good place for it. > >> > >> And then for consistency, also reexport Zeroable from the same location. > > > > I think you also mentioned at some point that using `pin_init` from > > `bindings` seemed strange and also using the `pin_init::zeroed()` > > function also doesn't fit, since it doesn't have to do with pinned > > initialization. > > Shouldn't it be that a crate that implements Zeroable / FromBytes / IntoBytes > and then pin_init becoming an user of that crate, then? The Zeroable trait has to be in pin-init because it's also outside the kernel. You *could* add yet another crate just for this and let pin-init depend on it, but just putting it in the existing ffi seems reasonable to me, and ffi is not a bad name for the owner of those traits anyway. Though I guess if we add zerocopy, that concern goes away. Alice
On Mon Jan 26, 2026 at 5:14 PM CET, Alice Ryhl wrote: > On Mon, Jan 26, 2026 at 5:11 PM Gary Guo <gary@garyguo.net> wrote: >> >> On Mon Jan 26, 2026 at 4:08 PM GMT, Benno Lossin wrote: >> > On Mon Jan 26, 2026 at 2:25 PM CET, Alice Ryhl wrote: >> >> On Mon, Jan 26, 2026 at 01:15:53PM +0000, Gary Guo wrote: >> >>> On Mon Jan 26, 2026 at 1:05 PM GMT, Alice Ryhl wrote: >> >>> > Currently, the Zeroable trait is defined by pin-init because pin-init >> >>> > happens to use the trait. However, zeroed types are useful for many >> >>> > purposes other than pin-init. Also, we wish to implement Zeroable for >> >>> > types generated by bindgen. For both of these reasons, re-export >> >>> > Zeroable from the ffi crate, which is a already dependency of the crates >> >>> > with bindgen output. >> >>> >> >>> I don't see a benefit of re-exporting these from the `ffi` crate? Especially >> >>> that we re-export `ffi` crate from kernel crate anyway, and `Zeroable` is >> >>> already in the kernel prelude. >> >>> >> >>> We already derive `Zeroable` for bindgen via `MaybeZeroable` derive in >> >>> rust/bindgen_parameters. >> >> >> >> I can't find the convo now, but this change is on my list from when we >> >> discussed also implementing FromBytes / IntoBytes for the bindings >> >> types. To do that, we need to move our FromBytes / IntoBytes traits >> >> somewhere that bindings/uapi can access, and we agreed that the ffi >> >> crate was a good place for it. >> >> >> >> And then for consistency, also reexport Zeroable from the same location. >> > >> > I think you also mentioned at some point that using `pin_init` from >> > `bindings` seemed strange and also using the `pin_init::zeroed()` >> > function also doesn't fit, since it doesn't have to do with pinned >> > initialization. >> >> Shouldn't it be that a crate that implements Zeroable / FromBytes / IntoBytes >> and then pin_init becoming an user of that crate, then? I think that's a little bit too much effort just for "nice naming". > The Zeroable trait has to be in pin-init because it's also outside the > kernel. You *could* add yet another crate just for this and let > pin-init depend on it, but just putting it in the existing ffi seems > reasonable to me, and ffi is not a bad name for the owner of those > traits anyway. > > Though I guess if we add zerocopy, that concern goes away. Indeed, I would just move pin-init to that. Cheers, Benno
© 2016 - 2026 Red Hat, Inc.