[PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Alice Ryhl]

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>

[PATCH 1/4] rust: ffi: reexport Zeroable and related items

[Alice Ryhl]

To implement FromBytes/AsBytes for bindings types, we need to move these
traits to the ffi crate. For consistency, this means that Zeroable
should also be available from the ffi crate. Thus, add the appropriate
re-exports.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/Makefile | 9 ++++++---
 rust/ffi.rs   | 7 +++++++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/rust/Makefile b/rust/Makefile
index 5d357dce1704d15e43effc528be8f5a4d74d3d8d..701d64c2310858aca8f7f76d698549fa014f62bf 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -207,7 +207,8 @@ rustdoc-compiler_builtins: $(src)/compiler_builtins.rs rustdoc-core FORCE
 	+$(call if_changed,rustdoc)
 
 rustdoc-ffi: private is-kernel-object := y
-rustdoc-ffi: $(src)/ffi.rs rustdoc-core FORCE
+rustdoc-ffi: private rustc_target_flags = --extern pin_init
+rustdoc-ffi: $(src)/ffi.rs rustdoc-pin_init rustdoc-core FORCE
 	+$(call if_changed,rustdoc)
 
 rustdoc-pin_init_internal: private rustdoc_host = yes
@@ -249,7 +250,8 @@ quiet_cmd_rustc_test_library = $(RUSTC_OR_CLIPPY_QUIET) TL $<
 rusttestlib-build_error: $(src)/build_error.rs FORCE
 	+$(call if_changed,rustc_test_library)
 
-rusttestlib-ffi: $(src)/ffi.rs FORCE
+rusttestlib-ffi: private rustc_target_flags = --extern pin_init
+rusttestlib-ffi: $(src)/ffi.rs rusttestlib-pin_init FORCE
 	+$(call if_changed,rustc_test_library)
 
 rusttestlib-proc_macro2: private rustc_target_flags = $(proc_macro2-flags)
@@ -657,7 +659,8 @@ $(obj)/build_error.o: $(src)/build_error.rs $(obj)/compiler_builtins.o FORCE
 	+$(call if_changed_rule,rustc_library)
 
 $(obj)/ffi.o: private skip_gendwarfksyms = 1
-$(obj)/ffi.o: $(src)/ffi.rs $(obj)/compiler_builtins.o FORCE
+$(obj)/ffi.o: private rustc_target_flags = --extern pin_init
+$(obj)/ffi.o: $(src)/ffi.rs $(obj)/compiler_builtins.o $(obj)/pin_init.o FORCE
 	+$(call if_changed_rule,rustc_library)
 
 $(obj)/bindings.o: private rustc_target_flags = --extern ffi --extern pin_init
diff --git a/rust/ffi.rs b/rust/ffi.rs
index f961e9728f590fd2c52d4c03a1f715d654051d04..7218d4c535cbd7163d9aca52b0525c588a394d1b 100644
--- a/rust/ffi.rs
+++ b/rust/ffi.rs
@@ -48,3 +48,10 @@ macro_rules! alias {
 pub use core::ffi::c_void;
 
 pub use core::ffi::CStr;
+
+pub use pin_init::{
+    zeroed,
+    MaybeZeroable,
+    Zeroable,
+    ZeroableOption, //
+};

-- 
2.52.0.457.g6b5491de43-goog

[PATCH 2/4] rust: cpufreq: import pin_init::zeroed() from ffi

[Alice Ryhl]

The zeroed() helper was re-exported from the ffi crate. As this usage of
zeroed() has nothing to do with pin-init, use the new re-export.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/cpufreq.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
index f968fbd22890546db1758d921e3374359ef9d00b..fadba8e669be33911a30be0254d3d4dcba9f4226 100644
--- a/rust/kernel/cpufreq.rs
+++ b/rust/kernel/cpufreq.rs
@@ -1012,7 +1012,7 @@ impl<T: Driver> Registration<T> {
         } else {
             None
         },
-        ..pin_init::zeroed()
+        ..ffi::zeroed()
     };
 
     const fn copy_name(name: &'static CStr) -> [c_char; CPUFREQ_NAME_LEN] {

-- 
2.52.0.457.g6b5491de43-goog

[PATCH 3/4] rust: i2c: import pin_init::zeroed() from ffi

[Alice Ryhl]

The zeroed() helper was re-exported from the ffi crate. As this usage of
zeroed() has nothing to do with pin-init, use the new re-export.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/i2c.rs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs
index 491e6cc25cf42619ebfd88af731db47efb8db93c..731bacff0990c8b9b2fe8601f07470b68032f3e8 100644
--- a/rust/kernel/i2c.rs
+++ b/rust/kernel/i2c.rs
@@ -46,7 +46,7 @@ impl DeviceId {
     pub const fn new(id: &'static CStr) -> Self {
         let src = id.to_bytes_with_nul();
         build_assert!(src.len() <= Self::I2C_NAME_SIZE, "ID exceeds 20 bytes");
-        let mut i2c: bindings::i2c_device_id = pin_init::zeroed();
+        let mut i2c: bindings::i2c_device_id = ffi::zeroed();
         let mut i = 0;
         while i < src.len() {
             i2c.name[i] = src[i];
@@ -433,7 +433,7 @@ impl I2cBoardInfo {
     pub const fn new(type_: &'static CStr, addr: u16) -> Self {
         let src = type_.to_bytes_with_nul();
         build_assert!(src.len() <= Self::I2C_TYPE_SIZE, "Type exceeds 20 bytes");
-        let mut i2c_board_info: bindings::i2c_board_info = pin_init::zeroed();
+        let mut i2c_board_info: bindings::i2c_board_info = ffi::zeroed();
         let mut i: usize = 0;
         while i < src.len() {
             i2c_board_info.type_[i] = src[i];

-- 
2.52.0.457.g6b5491de43-goog

[PATCH 4/4] rust: acpi: import pin_init::zeroed() from ffi

[Alice Ryhl]

The zeroed() helper was re-exported from the ffi crate. As this usage of
zeroed() has nothing to do with pin-init, use the new re-export.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/acpi.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/acpi.rs b/rust/kernel/acpi.rs
index 9b8efa623130c1f4256e36cc350caf5cef46d132..9ae0eca82c658a591b407c4f4549eda00b8d293c 100644
--- a/rust/kernel/acpi.rs
+++ b/rust/kernel/acpi.rs
@@ -39,7 +39,7 @@ impl DeviceId {
     pub const fn new(id: &'static CStr) -> Self {
         let src = id.to_bytes_with_nul();
         build_assert!(src.len() <= Self::ACPI_ID_LEN, "ID exceeds 16 bytes");
-        let mut acpi: bindings::acpi_device_id = pin_init::zeroed();
+        let mut acpi: bindings::acpi_device_id = ffi::zeroed();
         let mut i = 0;
         while i < src.len() {
             acpi.id[i] = src[i];

-- 
2.52.0.457.g6b5491de43-goog

Re: [PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Gary Guo]

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,

Re: [PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Alice Ryhl]

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

Re: [PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Benno Lossin]

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

Re: [PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Gary Guo]

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

Re: [PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Alice Ryhl]

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

Re: [PATCH 2/4] rust: cpufreq: import pin_init::zeroed() from ffi

[Viresh Kumar]

On 26-01-26, 13:05, Alice Ryhl wrote:
> The zeroed() helper was re-exported from the ffi crate. As this usage of
> zeroed() has nothing to do with pin-init, use the new re-export.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  rust/kernel/cpufreq.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
> index f968fbd22890546db1758d921e3374359ef9d00b..fadba8e669be33911a30be0254d3d4dcba9f4226 100644
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -1012,7 +1012,7 @@ impl<T: Driver> Registration<T> {
>          } else {
>              None
>          },
> -        ..pin_init::zeroed()
> +        ..ffi::zeroed()
>      };
>  
>      const fn copy_name(name: &'static CStr) -> [c_char; CPUFREQ_NAME_LEN] {

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

Re: [PATCH 0/4] Re-export Zeroable and zeroed() from ffi module

[Benno Lossin]

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