aboutsummaryrefslogtreecommitdiffstats
path: root/rust/macros/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* rust: add `kunit_tests` to the preludeMiguel Ojeda2025-05-271-1/+1
| | | | | | | | | | | | | | It is convenient to have certain things in the `kernel` prelude, and means kernel developers will find it even easier to start writing tests. And, anyway, nobody should need to use this identifier for anything else. Thus add it to the prelude. Reviewed-by: David Gow <[email protected]> Acked-by: Danilo Krummrich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: kunit: support KUnit-mapped `assert!` macros in `#[test]`sMiguel Ojeda2025-05-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The KUnit `#[test]` support that landed recently is very basic and does not map the `assert*!` macros into KUnit like the doctests do, so they panic at the moment. Thus implement the custom mapping in a similar way to doctests, reusing the infrastructure there. In Rust 1.88.0, the `file()` method in `Span` may be stable [1]. However, it was changed recently (from `SourceFile`), so we need to do something different in previous versions. Thus create a helper for it and use it to get the path. With this, a failing test suite like: #[kunit_tests(my_test_suite)] mod tests { use super::*; #[test] fn my_first_test() { assert_eq!(42, 43); } #[test] fn my_second_test() { assert!(42 >= 43); } } will properly map back to KUnit, printing something like: [ 1.924325] KTAP version 1 [ 1.924421] # Subtest: my_test_suite [ 1.924506] # speed: normal [ 1.924525] 1..2 [ 1.926385] # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251 [ 1.926385] Expected 42 == 43 to be true, but is false [ 1.928026] # my_first_test.speed: normal [ 1.928075] not ok 1 my_first_test [ 1.928723] # my_second_test: ASSERTION FAILED at rust/kernel/lib.rs:256 [ 1.928723] Expected 42 >= 43 to be true, but is false [ 1.929834] # my_second_test.speed: normal [ 1.929868] not ok 2 my_second_test [ 1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2 [ 1.930153] # Totals: pass:0 fail:2 skip:0 total Link: https://github.com/rust-lang/rust/pull/140514 [1] Reviewed-by: David Gow <[email protected]> Acked-by: Danilo Krummrich <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Required `KUNIT=y` like for doctests. Used the `cfg_attr` from the TODO comment and clarified its comment now that the stabilization is in beta and thus quite likely stable in Rust 1.88.0. Simplified the `new_body` code by introducing a new variable. Added `#[allow(clippy::incompatible_msrv)]`. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: make section names pluralPatrick Miller2025-05-261-1/+1
| | | | | | | | | | | | Clean Rust documentation section headers to use plural names. Suggested-by: Miguel Ojeda <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/1110 Signed-off-by: Patrick Miller <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Removed the `init` one that doesn't apply anymore and reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: use absolute paths in macros referencing core and kernelIgor Korotin2025-05-221-3/+3
| | | | | | | | | | | | | | | | | | | Macros and auto-generated code should use absolute paths, `::core::...` and `::kernel::...`, for core and kernel references. This prevents issues where user-defined modules named `core` or `kernel` could be picked up instead of the `core` or `kernel` crates. Thus clean some references up. Suggested-by: Benno Lossin <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/1150 Signed-off-by: Igor Korotin <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Applied `rustfmt`. Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: add macro to easily run KUnit testsJosé Expósito2025-03-201-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new procedural macro (`#[kunit_tests(kunit_test_suit_name)]`) to run KUnit tests using a user-space like syntax. The macro, that should be used on modules, transforms every `#[test]` in a `kunit_case!` and adds a `kunit_unsafe_test_suite!` registering all of them. The only difference with user-space tests is that instead of using `#[cfg(test)]`, `#[kunit_tests(kunit_test_suit_name)]` is used. Note that `#[cfg(CONFIG_KUNIT)]` is added so the test module is not compiled when `CONFIG_KUNIT` is set to `n`. Reviewed-by: David Gow <[email protected]> Signed-off-by: José Expósito <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]> Reviewed-by: Tamir Duberstein <[email protected]> Signed-off-by: David Gow <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Removed spurious (in rendered form) newline in docs. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: make pin-init its own crateBenno Lossin2025-03-161-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | Rename relative paths inside of the crate to still refer to the same items, also rename paths inside of the kernel crate and adjust the build system to build the crate. [ Remove the `expect` (and thus the `lint_reasons` feature) since the tree now uses `quote!` from `rust/macros/export.rs`. Remove the `TokenStream` import removal, since it is now used as well. In addition, temporarily (i.e. just for this commit) use an `--extern force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc` target. For context, please see a similar case in: https://lore.kernel.org/lkml/[email protected]/ And adjusted the message above. - Miguel ] Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Fiona Behrens <[email protected]> Tested-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: move pin-init API into its own directoryBenno Lossin2025-03-161-120/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation of splitting off the pin-init crate from the kernel crate, move all pin-init API code (including proc-macros) into `rust/pin-init`. Moved modules have their import path adjusted via the `#[path = "..."]` attribute. This allows the files to still be imported in the kernel crate even though the files are in different directories. Code that is moved out of files (but the file itself stays where it is) is imported via the `include!` macro. This also allows the code to be moved while still being part of the kernel crate. Note that this commit moves the generics parsing code out of the GPL-2.0 file `rust/macros/helpers.rs` into the Apache-2.0 OR MIT file `rust/pin_init/internal/src/helpers.rs`. I am the sole author of that code and it already is available with that license at [1]. The same is true for the entry-points of the proc-macros `pin_data`, `pinned_drop` and `derive_zeroable` in `rust/macros/lib.rs` that are moved to `rust/pin_data/internal/src/lib.rs`. Although there are some smaller patches that fix the doctests. Link: https://github.com/Rust-for-Linux/pinned-init [1] Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Reviewed-by: Fiona Behrens <[email protected]> Tested-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: init: disable doctestsBenno Lossin2025-03-161-4/+4
| | | | | | | | | | | | | | | | | The build system cannot handle doctests in the kernel crate in files outside of `rust/kernel/`. Subsequent commits will move files out of that directory, but will still compile them as part of the kernel crate. Thus ignore all doctests in the to-be-moved files. Leave tests disabled until they are separated into their own crate and they stop causing breakage. Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Fiona Behrens <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Tested-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: module: introduce `authors` keyGuilherme Giacomo Simoes2025-03-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the `module!` macro, the `author` field is currently of type `String`. Since modules can have multiple authors, this limitation prevents specifying more than one. Add an `authors` field as `Option<Vec<String>>` to allow creating modules with multiple authors, and change the documentation and all current users to use it. Eventually, the single `author` field may be removed. [ The `modinfo` key needs to still be `author`; otherwise, tooling may not work properly, e.g.: $ modinfo --author samples/rust/rust_print.ko Rust for Linux Contributors I have also kept the original `author` field (undocumented), so that we can drop it more easily in a kernel cycle or two. - Miguel ] Suggested-by: Miguel Ojeda <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/244 Reviewed-by: Charalampos Mitrodimas <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Signed-off-by: Guilherme Giacomo Simoes <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Fixed `modinfo` key. Kept `author` field. Reworded message accordingly. Updated my email. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: add #[export] macroAlice Ryhl2025-03-091-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rust has two different tools for generating function declarations to call across the FFI boundary: * bindgen. Generates Rust declarations from a C header. * cbindgen. Generates C headers from Rust declarations. However, we only use bindgen in the kernel. This means that when C code calls a Rust function by name, its signature must be duplicated in both Rust code and a C header, and the signature needs to be kept in sync manually. Introducing cbindgen as a mandatory dependency to build the kernel would be a rather complex and large change, so we do not consider that at this time. Instead, to eliminate this manual checking, introduce a new macro that verifies at compile time that the two function declarations use the same signature. The idea is to run the C declaration through bindgen, and then have rustc verify that the function pointers have the same type. The signature must still be written twice, but at least you can no longer get it wrong. If the signatures don't match, you will get errors that look like this: error[E0308]: `if` and `else` have incompatible types --> <linux>/rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` It is unfortunate that the error message starts out by saying "`if` and `else` have incompatible types", but I believe the rest of the error message is reasonably clear and not too confusing. Reviewed-by: Tamir Duberstein <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: add `build_error!` to the preludeMiguel Ojeda2025-01-091-4/+4
| | | | | | | | | | | | | | The sibling `build_assert!` is already in the prelude, it makes sense that a "core"/"language" facility like this is part of the prelude and users should not be defining their own one (thus there should be no risk of future name collisions and we would want to be aware of them anyway). Thus add `build_error!` into the prelude. Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Applied the change to the new miscdevice cases. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: use the `build_error!` macro, not the hidden functionMiguel Ojeda2025-01-091-4/+4
| | | | | | | | | | | | Code and some examples were using the function, rather than the macro. The macro is what is documented. Thus move users to the macro. Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Applied the change to the new miscdevice cases. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: enable the rest of the testsEthan D. Twardy2024-11-011-9/+50
| | | | | | | | | | | | | | | Now that the rusttest target for the macros crate is compiled with the kernel crate as a dependency, the rest of the rustdoc tests can be enabled. Signed-off-by: Ethan D. Twardy <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/[email protected] [ Rebased (use `K{Box,Vec}` instead, enable `lint_reasons` feature). Remove unneeded `rust` as language in examples, as well as `#[macro_use]` `extern`s. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: enable paste! use from macro_rules!Ethan D. Twardy2024-11-011-8/+34
| | | | | | | | | | | | | | | | | | | According to the rustdoc for the proc_macro crate[1], tokens captured from a "macro variable" (e.g. from within macro_rules!) may be delimited by invisible tokens and be contained within a proc_macro::Group. Previously, this scenario was not handled by macros::paste, which caused a proc-macro panic when the corresponding tests are enabled. Enable the tests, and handle this case by making macros::paste::concat recursive. Link: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html [1] Signed-off-by: Ethan D. Twardy <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/[email protected] [ Rebased (one fix was already applied) and reworded. Remove unneeded `rust` as language in examples. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: enable macros::module! testsEthan D. Twardy2024-11-011-15/+10
| | | | | | | | | | | | | | | | | Previously, these tests were ignored due to a missing necessary dependency on the `kernel` crate. Enable the tests, and update them: for both, add the parameter to `init()`; for the first one, remove the use of a kernel parameter mechanism that was never merged. Signed-off-by: Ethan D. Twardy <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/[email protected] [ Rebased (moved the `export` to the `rustdoc_test` rule, enable the firmware example too). Removed `export` for `RUST_MODFILE`. Removed unneeded `rust` language in examples, as well as `#[macro_use]` `extern`s. Reworded accordingly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: kbuild: expand rusttest target for macrosEthan D. Twardy2024-11-011-1/+1
| | | | | | | | | | | | | | | | | Previously, the rusttest target for the macros crate did not specify the dependencies necessary to run the rustdoc tests. These tests rely on the kernel crate, so add the dependencies. Signed-off-by: Ethan D. Twardy <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/[email protected] [ Rebased (`alloc` is gone nowadays, sysroot handling is simpler) and simplified (reused `rustdoc_test` rule instead of adding a new one, no need for `rustdoc-compiler_builtins`, removed unneeded `macros` explicit path). Made `vtable` example fail (avoiding to increase the complexity in the `rusttest` target). Removed unstable `-Zproc-macro-backtrace` option. Reworded accordingly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: fix documentation of the paste! macroPaolo Bonzini2024-10-211-1/+1
| | | | | | | | | | | One of the example in this section uses a curious mix of the constant and function declaration syntaxes; fix it. Signed-off-by: Paolo Bonzini <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Fixes: 823d4737d4c2 ("rust: macros: add `paste!` proc macro") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: treewide: switch to the kernel `Vec` typeDanilo Krummrich2024-10-151-3/+3
| | | | | | | | | | | | | Now that we got the kernel `Vec` in place, convert all existing `Vec` users to make use of it. Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Gary Guo <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Converted `kasan_test_rust.rs` too, as discussed. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: treewide: switch to our kernel `Box` typeDanilo Krummrich2024-10-151-3/+3
| | | | | | | | | | | | Now that we got the kernel `Box` type in place, convert all existing `Box` users to make use of it. Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Gary Guo <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* kbuild: rust: replace proc macros dependency on `core.o` with the version textMiguel Ojeda2024-09-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | With the `RUSTC_VERSION_TEXT` rebuild support in place, now proc macros can depend on that instead of `core.o`. This means that both the `core` and `macros` crates can be built in parallel, and that touching `core.o` does not trigger a rebuild of the proc macros. This could be accomplished using the same approach as for `core` (i.e. depending directly on `include/config/RUSTC_VERSION_TEXT`). However, that is considered an implementation detail [1], and thus it is best to avoid it. Instead, let fixdep find a string that we explicitly write down in the source code for this purpose (like it is done for `include/linux/compiler-version.h`), which we can easily do (unlike for `core`) since this is our own source code. Suggested-by: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/rust-for-linux/CAK7LNAQBG0nDupXSgAAk-6nOqeqGVkr3H1RjYaqRJ1OxmLm6xA@mail.gmail.com/ [1] Reviewed-by: Nicolas Schier <[email protected]> Tested-by: Alice Ryhl <[email protected]> Acked-by: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: indent list item in `module!`'s docsMiguel Ojeda2024-07-291-1/+1
| | | | | | | | | Like commit e516211f615f ("rust: macros: indent list item in `paste!`'s docs"), but for `module!`. Reviewed-by: Trevor Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: indent list item in `paste!`'s docsMiguel Ojeda2024-07-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new style lint, `doc_lazy_continuation` [1], has been introduced in the upcoming Rust 1.80 (currently in beta), which detects missing indentation in code documentation. We have one such case: error: doc list item missing indentation --> rust/macros/lib.rs:315:5 | 315 | /// default the span of the `[< >]` group is used. | ^ | = help: if this is supposed to be its own paragraph, add a blank line = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation = note: `-D clippy::doc-lazy-continuation` implied by `-D clippy::style` = help: to override `-D clippy::style` add `#[allow(clippy::doc_lazy_continuation)]` help: indent this line | 315 | /// default the span of the `[< >]` group is used. | ++ While the rendering of the docs by `rustdoc` is not affected, we apply this kind of indentation elsewhere since it looks better. Thus clean it up. Link: https://rust-lang.github.io/rust-clippy/master/index.html#/doc_lazy_continuation [1] Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Finn Behrens <[email protected]> Tested-by: Benno Lossin <[email protected]> Tested-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: add 'firmware' field support to module! macroFUJITA Tomonori2024-07-081-0/+32
| | | | | | | | | | | | | | This adds 'firmware' field support to module! macro, corresponds to MODULE_FIRMWARE macro. You can specify the file names of binary firmware that the kernel module requires. The information is embedded in the modinfo section of the kernel module. For example, a tool to build an initramfs uses this information to put the firmware files into the initramfs image. Signed-off-by: FUJITA Tomonori <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: fix datatype in docs for `module` macro argumentsAswin Unnikrishnan2024-07-081-5/+5
| | | | | | | | | | | Remove the mention of byte array as datatype for `module` macro arguments since the arguments are defined as string, and `alias` is a string array. Signed-off-by: Aswin Unnikrishnan <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: add example for `alias` argument in `module` macro documentationAswin Unnikrishnan2024-07-081-0/+1
| | | | | | | | | | | Add example for `alias` argument supported by `module` macro. `alias` accepts an array of alternate names for the module as string. Reviewed-by: Alice Ryhl <[email protected]> Signed-off-by: Aswin Unnikrishnan <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: remove `params` from `module` macro exampleAswin Unnikrishnan2024-04-251-12/+0
| | | | | | | | | | | | | | Remove argument `params` from the `module` macro example, because the macro does not currently support module parameters since it was not sent with the initial merge. Signed-off-by: Aswin Unnikrishnan <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Cc: [email protected] Fixes: 1fbde52bde73 ("rust: add `macros` crate") Link: https://lore.kernel.org/r/[email protected] [ Reworded slightly. ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: support `srctree`-relative linksMiguel Ojeda2023-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of our links use relative paths in order to point to files in the source tree, e.g.: //! C header: [`include/linux/printk.h`](../../../../include/linux/printk.h) /// [`struct mutex`]: ../../../../include/linux/mutex.h These are problematic because they are hard to maintain and do not support `O=` builds. Instead, provide support for `srctree`-relative links, e.g.: //! C header: [`include/linux/printk.h`](srctree/include/linux/printk.h) /// [`struct mutex`]: srctree/include/linux/mutex.h The links are fixed after `rustdoc` generation to be based on the absolute path to the source tree. Essentially, this is the automatic version of Tomonori's fix [1], suggested by Gary [2]. Suggested-by: Gary Guo <[email protected]> Reported-by: FUJITA Tomonori <[email protected]> Closes: https://lore.kernel.org/r/[email protected] [1] Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it") Link: https://lore.kernel.org/rust-for-linux/20231026154525.6d14b495@eugeo/ [2] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: improve `#[vtable]` documentationBenno Lossin2023-12-141-7/+31
| | | | | | | | | | | | | | | | | | | Traits marked with `#[vtable]` need to provide default implementations for optional functions. The C side represents these with `NULL` in the vtable, so the default functions are never actually called. We do not want to replicate the default behavior from C in Rust, because that is not maintainable. Therefore we should use `build_error` in those default implementations. The error message for that is provided at `kernel::error::VTABLE_DEFAULT_ERROR`. Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Finn Behrens <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Wrapped paragraph to 80 as requested and capitalized sentence. ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: update 'paste!' macro to accept string literalsTrevor Gross2023-12-141-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable combining identifiers with literals in the 'paste!' macro. This allows combining user-specified strings with affixes to create namespaced identifiers. This sample code: macro_rules! m { ($name:lit) => { paste!(struct [<_some_ $name _struct_>] {}) } } m!("foo_bar"); Would previously cause a compilation error. It will now generate: struct _some_foo_bar_struct_ {} Signed-off-by: Trevor Gross <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added `:` before example block. ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: add derive macro for `Zeroable`Benno Lossin2023-08-211-0/+20
| | | | | | | | | | | | | | | | | | Add a derive proc-macro for the `Zeroable` trait. The macro supports structs where every field implements the `Zeroable` trait. This way `unsafe` implementations can be avoided. The macro is split into two parts: - a proc-macro to parse generics into impl and ty generics, - a declarative macro that expands to the impl block. Suggested-by: Asahi Lina <[email protected]> Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added `ignore` to the `lib.rs` example and cleaned trivial nit. ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: add `paste!` proc macroGary Guo2023-08-101-0/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This macro provides a flexible way to concatenated identifiers together and it allows the resulting identifier to be used to declare new items, which `concat_idents!` does not allow. It also allows identifiers to be transformed before concatenated. The `concat_idents!` example let x_1 = 42; let x_2 = concat_idents!(x, _1); assert!(x_1 == x_2); can be written with `paste!` macro like this: let x_1 = 42; let x_2 = paste!([<x _1>]); assert!(x_1 == x_2); However `paste!` macro is more flexible because it can be used to create a new variable: let x_1 = 42; paste!(let [<x _2>] = [<x _1>];); assert!(x_1 == x_2); While this is not possible with `concat_idents!`. This macro is similar to the `paste!` crate [1], but this is a fresh implementation to avoid vendoring large amount of code directly. Also, I have augmented it to provide a way to specify span of the resulting token, allowing precise control. For example, this code is broken because the variable is declared inside the macro, so Rust macro hygiene rules prevents access from the outside: macro_rules! m { ($id: ident) => { // The resulting token has hygiene of the macro. paste!(let [<$id>] = 1;) } } m!(a); let _ = a; In this version of `paste!` macro I added a `span` modifier to allow this: macro_rules! m { ($id: ident) => { // The resulting token has hygiene of `$id`. paste!(let [<$id:span>] = 1;) } } m!(a); let _ = a; Link: http://docs.rs/paste/ [1] Signed-off-by: Gary Guo <[email protected]> Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added SPDX license identifier as discussed in the list and fixed typo. ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: init: add `PinnedDrop` trait and macrosBenno Lossin2023-04-121-0/+49
| | | | | | | | | | | | | | | | The `PinnedDrop` trait that facilitates destruction of pinned types. It has to be implemented via the `#[pinned_drop]` macro, since the `drop` function should not be called by normal code, only by other destructors. It also only works on structs that are annotated with `#[pin_data(PinnedDrop)]`. Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: init: add initialization macrosBenno Lossin2023-04-121-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Add the following initializer macros: - `#[pin_data]` to annotate structurally pinned fields of structs, needed for `pin_init!` and `try_pin_init!` to select the correct initializer of fields. - `pin_init!` create a pin-initializer for a struct with the `Infallible` error type. - `try_pin_init!` create a pin-initializer for a struct with a custom error type (`kernel::error::Error` is the default). - `init!` create an in-place-initializer for a struct with the `Infallible` error type. - `try_init!` create an in-place-initializer for a struct with a custom error type (`kernel::error::Error` is the default). Also add their needed internal helper traits and structs. Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Fixed three typos. ] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: add `quote!` macroGary Guo2023-04-121-0/+2
| | | | | | | | | | | | | | Add the `quote!` macro for creating `TokenStream`s directly via the given Rust tokens. It also supports repetitions using iterators. It will be used by the pin-init API proc-macros to generate code. Signed-off-by: Gary Guo <[email protected]> Signed-off-by: Benno Lossin <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: take string literals in `module!`Gary Guo2022-12-041-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of taking binary string literals, take string ones instead, making it easier for users to define a module, i.e. instead of calling `module!` like: module! { ... name: b"rust_minimal", ... } now it is called as: module! { ... name: "rust_minimal", ... } Module names, aliases and license strings are restricted to ASCII only. However, the author and the description allows UTF-8. For simplicity (avoid parsing), escape sequences and raw string literals are not yet handled. Link: https://github.com/Rust-for-Linux/linux/issues/252 Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: add `#[vtable]` proc macroGary Guo2022-12-041-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This procedural macro attribute provides a simple way to declare a trait with a set of operations that later users can partially implement, providing compile-time `HAS_*` boolean associated constants that indicate whether a particular operation was overridden. This is useful as the Rust counterpart to structs like `file_operations` where some pointers may be `NULL`, indicating an operation is not provided. For instance: #[vtable] trait Operations { fn read(...) -> Result<usize> { Err(EINVAL) } fn write(...) -> Result<usize> { Err(EINVAL) } } #[vtable] impl Operations for S { fn read(...) -> Result<usize> { ... } } assert_eq!(<S as Operations>::HAS_READ, true); assert_eq!(<S as Operations>::HAS_WRITE, false); Signed-off-by: Gary Guo <[email protected]> Reviewed-by: Sergio González Collado <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: macros: add `concat_idents!` proc macroBjörn Roy Baron2022-12-041-0/+44
| | | | | | | | | | | | | | | | | | | | | | This macro provides similar functionality to the unstable feature `concat_idents` without having to rely on it. For instance: let x_1 = 42; let x_2 = concat_idents!(x, _1); assert!(x_1 == x_2); It has different behavior with respect to macro hygiene. Unlike the unstable `concat_idents!` macro, it allows, for example, referring to local variables by taking the span of the second macro as span for the output identifier. Signed-off-by: Björn Roy Baron <[email protected]> Reviewed-by: Finn Behrens <[email protected]> Reviewed-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
* rust: add `macros` crateMiguel Ojeda2022-09-281-0/+72
This crate contains all the procedural macros ("proc macros") shared by all the kernel. Procedural macros allow to create syntax extensions. They run at compile-time and can consume as well as produce Rust syntax. For instance, the `module!` macro that is used by Rust modules is implemented here. It allows to easily declare the equivalent information to the `MODULE_*` macros in C modules, e.g.: module! { type: RustMinimal, name: b"rust_minimal", author: b"Rust for Linux Contributors", description: b"Rust minimal sample", license: b"GPL", } Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sumera Priyadarsini <[email protected]> Signed-off-by: Sumera Priyadarsini <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Matthew Bakhtiari <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-01 11:27:16 +0000