| Message ID | 20250304173555.2496-4-dakr@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Initial Nova Core series | expand |
On Tue, Mar 04, 2025 at 06:34:50PM +0100, Danilo Krummrich wrote: > Analogous to the `module!` macro `module_firmware!` adds additional > firmware path strings to the .modinfo section. > > In contrast to `module!`, where path strings need to be string literals, > path strings can be composed with the `firmware::ModInfoBuilder`. > > Some drivers require a lot of firmware files (such as nova-core) and > hence benefit from more flexibility composing firmware path strings. > > Signed-off-by: Danilo Krummrich <dakr@kernel.org> > --- > rust/kernel/firmware.rs | 79 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs > index 6e6972d94597..5d1ac8287171 100644 > --- a/rust/kernel/firmware.rs > +++ b/rust/kernel/firmware.rs > @@ -116,6 +116,85 @@ unsafe impl Send for Firmware {} > // be used from any thread. > unsafe impl Sync for Firmware {} > > +/// Create firmware .modinfo entries. > +/// > +/// This macro is the counterpart of the C macro `MODULE_FIRMWARE()`, but instead of taking a > +/// simple string literals, which is already covered by the `firmware` field of > +/// [`crate::prelude::module!`], it allows the caller to pass a builder type (e.g. > +/// [`ModInfoBuilder`]) which can create the firmware modinfo strings in a more flexible way. > +/// > +/// Drivers should extend the [`ModInfoBuilder`] with their own driver specific builder type. > +/// > +/// The `builder` argument must be a type which implements the following function. > +/// > +/// `const fn create(module_name: &'static CStr) -> ModInfoBuilder` > +/// > +/// `create` should pass the `module_name` to the [`ModInfoBuilder`] and, with the help of > +/// it construct the corresponding firmware modinfo. > +/// > +/// Typically, such contracts would be enforced by a trait, however traits do not (yet) support > +/// const functions. > +/// > +/// # Example > +/// > +/// ``` > +/// # mod module_firmware_test { > +/// # use kernel::firmware; > +/// # use kernel::prelude::*; > +/// # > +/// # struct MyModule; > +/// # > +/// # impl kernel::Module for MyModule { > +/// # fn init(_module: &'static ThisModule) -> Result<Self> { > +/// # Ok(Self) > +/// # } > +/// # } > +/// # > +/// # > +/// struct Builder<const N: usize>; > +/// > +/// impl<const N: usize> Builder<N> { > +/// const fn create(module_name: &'static kernel::str::CStr) -> firmware::ModInfoBuilder<N> { > +/// firmware::ModInfoBuilder::new(module_name) > +/// .prepare() > +/// .push("vendor/foo.bin") > +/// .prepare() > +/// .push("vendor/bar.bin") > +/// } > +/// } > +/// > +/// module! { > +/// type: MyModule, > +/// name: "module_firmware_test", > +/// author: "Rust for Linux", > +/// description: "module_firmware! test module", > +/// license: "GPL", > +/// } > +/// > +/// kernel::module_firmware!(Builder); > +/// # } > +/// ``` > +#[macro_export] > +macro_rules! module_firmware { > + ($($builder:tt)*) => { > + > + #[cfg(not(MODULE))] > + const fn __module_name() -> &'static kernel::str::CStr { > + <LocalModule as kernel::ModuleMetadata>::NAME > + } > + > + #[cfg(MODULE)] > + const fn __module_name() -> &'static kernel::str::CStr { > + kernel::c_str!("") > + } > + > + #[link_section = ".modinfo"] > + #[used] > + static __MODULE_FIRMWARE: [u8; $($builder)*::create(__module_name()).build_length()] = > + $($builder)*::create(__module_name()).build(); > + }; > +} > + > /// Builder for firmware module info. > /// > /// [`ModInfoBuilder`] is a helper component to flexibly compose firmware paths strings for the > -- > 2.48.1 > > Acked-by: Jarkko Sakkinen <jarkko@kernel.org> BR, Jarkko
On Tue Mar 4, 2025 at 6:34 PM CET, Danilo Krummrich wrote: > Analogous to the `module!` macro `module_firmware!` adds additional > firmware path strings to the .modinfo section. > > In contrast to `module!`, where path strings need to be string literals, > path strings can be composed with the `firmware::ModInfoBuilder`. > > Some drivers require a lot of firmware files (such as nova-core) and > hence benefit from more flexibility composing firmware path strings. > > Signed-off-by: Danilo Krummrich <dakr@kernel.org> > --- > rust/kernel/firmware.rs | 79 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs > index 6e6972d94597..5d1ac8287171 100644 > --- a/rust/kernel/firmware.rs > +++ b/rust/kernel/firmware.rs > @@ -116,6 +116,85 @@ unsafe impl Send for Firmware {} > // be used from any thread. > unsafe impl Sync for Firmware {} > > +/// Create firmware .modinfo entries. > +/// > +/// This macro is the counterpart of the C macro `MODULE_FIRMWARE()`, but instead of taking a > +/// simple string literals, which is already covered by the `firmware` field of > +/// [`crate::prelude::module!`], it allows the caller to pass a builder type (e.g. > +/// [`ModInfoBuilder`]) which can create the firmware modinfo strings in a more flexible way. > +/// > +/// Drivers should extend the [`ModInfoBuilder`] with their own driver specific builder type. > +/// > +/// The `builder` argument must be a type which implements the following function. > +/// > +/// `const fn create(module_name: &'static CStr) -> ModInfoBuilder` > +/// > +/// `create` should pass the `module_name` to the [`ModInfoBuilder`] and, with the help of > +/// it construct the corresponding firmware modinfo. > +/// > +/// Typically, such contracts would be enforced by a trait, however traits do not (yet) support > +/// const functions. > +/// > +/// # Example > +/// > +/// ``` > +/// # mod module_firmware_test { > +/// # use kernel::firmware; > +/// # use kernel::prelude::*; > +/// # > +/// # struct MyModule; > +/// # > +/// # impl kernel::Module for MyModule { > +/// # fn init(_module: &'static ThisModule) -> Result<Self> { > +/// # Ok(Self) > +/// # } > +/// # } > +/// # > +/// # > +/// struct Builder<const N: usize>; > +/// > +/// impl<const N: usize> Builder<N> { > +/// const fn create(module_name: &'static kernel::str::CStr) -> firmware::ModInfoBuilder<N> { > +/// firmware::ModInfoBuilder::new(module_name) > +/// .prepare() > +/// .push("vendor/foo.bin") > +/// .prepare() > +/// .push("vendor/bar.bin") > +/// } > +/// } > +/// > +/// module! { > +/// type: MyModule, > +/// name: "module_firmware_test", > +/// author: "Rust for Linux", > +/// description: "module_firmware! test module", > +/// license: "GPL", > +/// } > +/// > +/// kernel::module_firmware!(Builder); > +/// # } > +/// ``` Would be nice to see a more complex example here like the one from nova you sent in the other thread. So with "dynamic" string interpolation and multiple pushes. > +#[macro_export] > +macro_rules! module_firmware { > + ($($builder:tt)*) => { This should probably be `$builder:expr` instead. > + > + #[cfg(not(MODULE))] > + const fn __module_name() -> &'static kernel::str::CStr { > + <LocalModule as kernel::ModuleMetadata>::NAME Please either use `::kernel::` or `$crate::` instead of `kernel::`. Hmm, I am not 100% comfortable with the `LocalModule` way of accessing the current module for some reason, no idea if there is a rational argument behind that, but it just doesn't sit right with me. Essentially you're doing this for convenience, right? So you don't want to have to repeat the name of the module type every time? > + } > + > + #[cfg(MODULE)] > + const fn __module_name() -> &'static kernel::str::CStr { > + kernel::c_str!("") Ditto. > + } Are these two functions used outside of the `static` below? If no, then you can just move them into the static? You can also probably use a `const` instead of a function, that way you only have 4 lines instead of 8. --- Cheers, Benno > + > + #[link_section = ".modinfo"] > + #[used] > + static __MODULE_FIRMWARE: [u8; $($builder)*::create(__module_name()).build_length()] = > + $($builder)*::create(__module_name()).build(); > + }; > +} > + > /// Builder for firmware module info. > /// > /// [`ModInfoBuilder`] is a helper component to flexibly compose firmware paths strings for the > -- > 2.48.1
On Thu, Mar 06, 2025 at 12:31:14AM +0000, Benno Lossin wrote: > On Tue Mar 4, 2025 at 6:34 PM CET, Danilo Krummrich wrote: > > > +#[macro_export] > > +macro_rules! module_firmware { > > + ($($builder:tt)*) => { > > This should probably be `$builder:expr` instead. That doesn't work, the compiler then complains, since it's not an expression: 193 | static __MODULE_FIRMWARE: [u8; $builder::create(__module_name()).build_length()] = | ^^ expected one of `.`, `?`, `]`, or an operator `ty` doesn't work either, since then the compiler expects the caller to add the const generic, which we want the macro to figure out instead. > > > + > > + #[cfg(not(MODULE))] > > + const fn __module_name() -> &'static kernel::str::CStr { > > + <LocalModule as kernel::ModuleMetadata>::NAME > > Please either use `::kernel::` or `$crate::` instead of `kernel::`. Good catch, thanks. > > Hmm, I am not 100% comfortable with the `LocalModule` way of accessing > the current module for some reason, no idea if there is a rational > argument behind that, but it just doesn't sit right with me. > > Essentially you're doing this for convenience, right? So you don't want > to have to repeat the name of the module type every time? No, it's really that I can't know the type name here, please see the previous patch commit message that introduces `LocalModule` for explanation. > > > + } > > + > > + #[cfg(MODULE)] > > + const fn __module_name() -> &'static kernel::str::CStr { > > + kernel::c_str!("") > > Ditto. > > > + } > > Are these two functions used outside of the `static` below? If no, then > you can just move them into the static? You can also probably use a > `const` instead of a function, that way you only have 4 lines instead > of 8. Is this what you're proposing? #[macro_export] macro_rules! module_firmware { ($($builder:tt)*) => { const __MODULE_FIRMWARE_PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { $crate::c_str!("") } else { <LocalModule as $crate::ModuleMetadata>::NAME }; #[link_section = ".modinfo"] #[used] static __MODULE_FIRMWARE: [u8; $($builder)*::create(__MODULE_FIRMWARE_PREFIX) .build_length()] = $($builder)*::create(__MODULE_FIRMWARE_PREFIX).build(); }; }
On Thu Mar 6, 2025 at 2:04 AM CET, Danilo Krummrich wrote: > On Thu, Mar 06, 2025 at 12:31:14AM +0000, Benno Lossin wrote: >> On Tue Mar 4, 2025 at 6:34 PM CET, Danilo Krummrich wrote: >> >> > +#[macro_export] >> > +macro_rules! module_firmware { >> > + ($($builder:tt)*) => { >> >> This should probably be `$builder:expr` instead. > > That doesn't work, the compiler then complains, since it's not an expression: > > 193 | static __MODULE_FIRMWARE: [u8; $builder::create(__module_name()).build_length()] = > | ^^ expected one of `.`, `?`, `]`, or an operator Does `<$builder>::create` work (with the `expr` fragment)? > `ty` doesn't work either, since then the compiler expects the caller to add the > const generic, which we want the macro to figure out instead. > >> >> > + >> > + #[cfg(not(MODULE))] >> > + const fn __module_name() -> &'static kernel::str::CStr { >> > + <LocalModule as kernel::ModuleMetadata>::NAME >> >> Please either use `::kernel::` or `$crate::` instead of `kernel::`. > > Good catch, thanks. > >> >> Hmm, I am not 100% comfortable with the `LocalModule` way of accessing >> the current module for some reason, no idea if there is a rational >> argument behind that, but it just doesn't sit right with me. >> >> Essentially you're doing this for convenience, right? So you don't want >> to have to repeat the name of the module type every time? > > No, it's really that I can't know the type name here, please see the previous > patch commit message that introduces `LocalModule` for explanation. Gotcha. >> > + } >> > + >> > + #[cfg(MODULE)] >> > + const fn __module_name() -> &'static kernel::str::CStr { >> > + kernel::c_str!("") >> >> Ditto. >> >> > + } >> >> Are these two functions used outside of the `static` below? If no, then >> you can just move them into the static? You can also probably use a >> `const` instead of a function, that way you only have 4 lines instead >> of 8. > > Is this what you're proposing? > > #[macro_export] > macro_rules! module_firmware { > ($($builder:tt)*) => { > const __MODULE_FIRMWARE_PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { > $crate::c_str!("") > } else { > <LocalModule as $crate::ModuleMetadata>::NAME > }; > > #[link_section = ".modinfo"] > #[used] > static __MODULE_FIRMWARE: [u8; $($builder)*::create(__MODULE_FIRMWARE_PREFIX) > .build_length()] = $($builder)*::create(__MODULE_FIRMWARE_PREFIX).build(); I meant to also move the `const` into the expression, but I guess that leads to duplication: #[link_section = ".modinfo"] #[used] static __MODULE_FIRMWARE: [u8; { const PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { $crate::c_str!("") } else { <LocalModule as $crate::ModuleMetadata>::NAME }; <$builder>::create(PREFIX).build_length() }] = { const PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { $crate::c_str!("") } else { <LocalModule as $crate::ModuleMetadata>::NAME }; <$builder>::create(PREFIX) }; But then the advantage is that only the `__MODULE_FIRMWARE` static will be in-scope. Do you think that its useful to have the static be accessible? I.e. do users need to access it (I would think they don't)? If they don't, then we could put all of those things into a `const _: () = { /* ... */ };`. But then people can invoke `module_firmware!` multiple times in the same module, is that a problem? --- Cheers, Benno > }; > }
On Thu, Mar 06, 2025 at 01:27:19AM +0000, Benno Lossin wrote: > On Thu Mar 6, 2025 at 2:04 AM CET, Danilo Krummrich wrote: > > On Thu, Mar 06, 2025 at 12:31:14AM +0000, Benno Lossin wrote: > >> On Tue Mar 4, 2025 at 6:34 PM CET, Danilo Krummrich wrote: > >> > >> > +#[macro_export] > >> > +macro_rules! module_firmware { > >> > + ($($builder:tt)*) => { > >> > >> This should probably be `$builder:expr` instead. > > > > That doesn't work, the compiler then complains, since it's not an expression: > > > > 193 | static __MODULE_FIRMWARE: [u8; $builder::create(__module_name()).build_length()] = > > | ^^ expected one of `.`, `?`, `]`, or an operator > > Does `<$builder>::create` work (with the `expr` fragment)? No, the compiler then explicitly complains that it expects a type. > > > `ty` doesn't work either, since then the compiler expects the caller to add the > > const generic, which we want the macro to figure out instead. > > > >> > >> > + > >> > + #[cfg(not(MODULE))] > >> > + const fn __module_name() -> &'static kernel::str::CStr { > >> > + <LocalModule as kernel::ModuleMetadata>::NAME > >> > >> Please either use `::kernel::` or `$crate::` instead of `kernel::`. > > > > Good catch, thanks. > > > >> > >> Hmm, I am not 100% comfortable with the `LocalModule` way of accessing > >> the current module for some reason, no idea if there is a rational > >> argument behind that, but it just doesn't sit right with me. > >> > >> Essentially you're doing this for convenience, right? So you don't want > >> to have to repeat the name of the module type every time? > > > > No, it's really that I can't know the type name here, please see the previous > > patch commit message that introduces `LocalModule` for explanation. > > Gotcha. > > >> > + } > >> > + > >> > + #[cfg(MODULE)] > >> > + const fn __module_name() -> &'static kernel::str::CStr { > >> > + kernel::c_str!("") > >> > >> Ditto. > >> > >> > + } > >> > >> Are these two functions used outside of the `static` below? If no, then > >> you can just move them into the static? You can also probably use a > >> `const` instead of a function, that way you only have 4 lines instead > >> of 8. > > > > Is this what you're proposing? > > > > #[macro_export] > > macro_rules! module_firmware { > > ($($builder:tt)*) => { > > const __MODULE_FIRMWARE_PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { > > $crate::c_str!("") > > } else { > > <LocalModule as $crate::ModuleMetadata>::NAME > > }; > > > > #[link_section = ".modinfo"] > > #[used] > > static __MODULE_FIRMWARE: [u8; $($builder)*::create(__MODULE_FIRMWARE_PREFIX) > > .build_length()] = $($builder)*::create(__MODULE_FIRMWARE_PREFIX).build(); > > I meant to also move the `const` into the expression, but I guess that > leads to duplication: > > #[link_section = ".modinfo"] > #[used] > static __MODULE_FIRMWARE: [u8; { > const PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { > $crate::c_str!("") > } else { > <LocalModule as $crate::ModuleMetadata>::NAME > }; > <$builder>::create(PREFIX).build_length() > }] = { > const PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { > $crate::c_str!("") > } else { > <LocalModule as $crate::ModuleMetadata>::NAME > }; > <$builder>::create(PREFIX) > }; > > But then the advantage is that only the `__MODULE_FIRMWARE` static will > be in-scope. > > Do you think that its useful to have the static be accessible? I.e. do > users need to access it (I would think they don't)? If they don't, then > we could put all of those things into a `const _: () = { /* ... */ };`. > But then people can invoke `module_firmware!` multiple times in the same > module, is that a problem? Didn't know that's possible (const _; () = { ... };). That's pretty nice, I will go with my above proposal wrapped into the anonymous const. Thanks.
On Thu Mar 6, 2025 at 2:38 AM CET, Danilo Krummrich wrote: > On Thu, Mar 06, 2025 at 01:27:19AM +0000, Benno Lossin wrote: >> On Thu Mar 6, 2025 at 2:04 AM CET, Danilo Krummrich wrote: >> > On Thu, Mar 06, 2025 at 12:31:14AM +0000, Benno Lossin wrote: >> >> On Tue Mar 4, 2025 at 6:34 PM CET, Danilo Krummrich wrote: >> >> >> >> > +#[macro_export] >> >> > +macro_rules! module_firmware { >> >> > + ($($builder:tt)*) => { >> >> >> >> This should probably be `$builder:expr` instead. >> > >> > That doesn't work, the compiler then complains, since it's not an expression: >> > >> > 193 | static __MODULE_FIRMWARE: [u8; $builder::create(__module_name()).build_length()] = >> > | ^^ expected one of `.`, `?`, `]`, or an operator >> >> Does `<$builder>::create` work (with the `expr` fragment)? > > No, the compiler then explicitly complains that it expects a type. Aw well, can't have em all... Probably would be useful if you add a comment saying that `expr` and `ty` can't be used. >> > `ty` doesn't work either, since then the compiler expects the caller to add the >> > const generic, which we want the macro to figure out instead. >> > >> >> >> >> > + >> >> > + #[cfg(not(MODULE))] >> >> > + const fn __module_name() -> &'static kernel::str::CStr { >> >> > + <LocalModule as kernel::ModuleMetadata>::NAME >> >> >> >> Please either use `::kernel::` or `$crate::` instead of `kernel::`. >> > >> > Good catch, thanks. >> > >> >> >> >> Hmm, I am not 100% comfortable with the `LocalModule` way of accessing >> >> the current module for some reason, no idea if there is a rational >> >> argument behind that, but it just doesn't sit right with me. >> >> >> >> Essentially you're doing this for convenience, right? So you don't want >> >> to have to repeat the name of the module type every time? >> > >> > No, it's really that I can't know the type name here, please see the previous >> > patch commit message that introduces `LocalModule` for explanation. >> >> Gotcha. >> >> >> > + } >> >> > + >> >> > + #[cfg(MODULE)] >> >> > + const fn __module_name() -> &'static kernel::str::CStr { >> >> > + kernel::c_str!("") >> >> >> >> Ditto. >> >> >> >> > + } >> >> >> >> Are these two functions used outside of the `static` below? If no, then >> >> you can just move them into the static? You can also probably use a >> >> `const` instead of a function, that way you only have 4 lines instead >> >> of 8. >> > >> > Is this what you're proposing? >> > >> > #[macro_export] >> > macro_rules! module_firmware { >> > ($($builder:tt)*) => { >> > const __MODULE_FIRMWARE_PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { >> > $crate::c_str!("") >> > } else { >> > <LocalModule as $crate::ModuleMetadata>::NAME >> > }; >> > >> > #[link_section = ".modinfo"] >> > #[used] >> > static __MODULE_FIRMWARE: [u8; $($builder)*::create(__MODULE_FIRMWARE_PREFIX) >> > .build_length()] = $($builder)*::create(__MODULE_FIRMWARE_PREFIX).build(); >> >> I meant to also move the `const` into the expression, but I guess that >> leads to duplication: >> >> #[link_section = ".modinfo"] >> #[used] >> static __MODULE_FIRMWARE: [u8; { >> const PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { >> $crate::c_str!("") >> } else { >> <LocalModule as $crate::ModuleMetadata>::NAME >> }; >> <$builder>::create(PREFIX).build_length() >> }] = { >> const PREFIX: &'static $crate::str::CStr = if cfg!(MODULE) { >> $crate::c_str!("") >> } else { >> <LocalModule as $crate::ModuleMetadata>::NAME >> }; >> <$builder>::create(PREFIX) >> }; >> >> But then the advantage is that only the `__MODULE_FIRMWARE` static will >> be in-scope. >> >> Do you think that its useful to have the static be accessible? I.e. do >> users need to access it (I would think they don't)? If they don't, then >> we could put all of those things into a `const _: () = { /* ... */ };`. >> But then people can invoke `module_firmware!` multiple times in the same >> module, is that a problem? > > Didn't know that's possible (const _; () = { ... };). That's pretty nice, I will > go with my above proposal wrapped into the anonymous const. Thanks. Sounds good. --- Cheers, Benno
diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs index 6e6972d94597..5d1ac8287171 100644 --- a/rust/kernel/firmware.rs +++ b/rust/kernel/firmware.rs @@ -116,6 +116,85 @@ unsafe impl Send for Firmware {} // be used from any thread. unsafe impl Sync for Firmware {} +/// Create firmware .modinfo entries. +/// +/// This macro is the counterpart of the C macro `MODULE_FIRMWARE()`, but instead of taking a +/// simple string literals, which is already covered by the `firmware` field of +/// [`crate::prelude::module!`], it allows the caller to pass a builder type (e.g. +/// [`ModInfoBuilder`]) which can create the firmware modinfo strings in a more flexible way. +/// +/// Drivers should extend the [`ModInfoBuilder`] with their own driver specific builder type. +/// +/// The `builder` argument must be a type which implements the following function. +/// +/// `const fn create(module_name: &'static CStr) -> ModInfoBuilder` +/// +/// `create` should pass the `module_name` to the [`ModInfoBuilder`] and, with the help of +/// it construct the corresponding firmware modinfo. +/// +/// Typically, such contracts would be enforced by a trait, however traits do not (yet) support +/// const functions. +/// +/// # Example +/// +/// ``` +/// # mod module_firmware_test { +/// # use kernel::firmware; +/// # use kernel::prelude::*; +/// # +/// # struct MyModule; +/// # +/// # impl kernel::Module for MyModule { +/// # fn init(_module: &'static ThisModule) -> Result<Self> { +/// # Ok(Self) +/// # } +/// # } +/// # +/// # +/// struct Builder<const N: usize>; +/// +/// impl<const N: usize> Builder<N> { +/// const fn create(module_name: &'static kernel::str::CStr) -> firmware::ModInfoBuilder<N> { +/// firmware::ModInfoBuilder::new(module_name) +/// .prepare() +/// .push("vendor/foo.bin") +/// .prepare() +/// .push("vendor/bar.bin") +/// } +/// } +/// +/// module! { +/// type: MyModule, +/// name: "module_firmware_test", +/// author: "Rust for Linux", +/// description: "module_firmware! test module", +/// license: "GPL", +/// } +/// +/// kernel::module_firmware!(Builder); +/// # } +/// ``` +#[macro_export] +macro_rules! module_firmware { + ($($builder:tt)*) => { + + #[cfg(not(MODULE))] + const fn __module_name() -> &'static kernel::str::CStr { + <LocalModule as kernel::ModuleMetadata>::NAME + } + + #[cfg(MODULE)] + const fn __module_name() -> &'static kernel::str::CStr { + kernel::c_str!("") + } + + #[link_section = ".modinfo"] + #[used] + static __MODULE_FIRMWARE: [u8; $($builder)*::create(__module_name()).build_length()] = + $($builder)*::create(__module_name()).build(); + }; +} + /// Builder for firmware module info. /// /// [`ModInfoBuilder`] is a helper component to flexibly compose firmware paths strings for the
Analogous to the `module!` macro `module_firmware!` adds additional firmware path strings to the .modinfo section. In contrast to `module!`, where path strings need to be string literals, path strings can be composed with the `firmware::ModInfoBuilder`. Some drivers require a lot of firmware files (such as nova-core) and hence benefit from more flexibility composing firmware path strings. Signed-off-by: Danilo Krummrich <dakr@kernel.org> --- rust/kernel/firmware.rs | 79 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+)