| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
Pull Rust updates from Miguel Ojeda:
"The most notable change is the drop of the 'alloc' in-tree fork. This
is nicely reflected in the diffstat as a ~10k lines drop. In turn,
this makes the version upgrades way simpler and smaller in the future,
e.g. the latest one in commit 56f64b370612 ("rust: upgrade to Rust
1.78.0").
More importantly, this increases the chances that a newer compiler
version just works, which in turn means supporting several compiler
versions is easier now. Thus we will look into finally setting a
minimum version in the near future.
Toolchain and infrastructure:
- Upgrade to Rust 1.78.0
This time around, due to how the kernel and Rust schedules have
aligned, there are two upgrades in fact. These allow us to remove
one more unstable feature ('offset_of') from the list, among other
improvements
- Drop 'alloc' in-tree fork of the standard library crate, which
means all the unstable features used by 'alloc' (~30 language ones,
~60 library ones) are not a concern anymore
- Support DWARFv5 via the '-Zdwarf-version' flag
- Support zlib and zstd debuginfo compression via the
'-Zdebuginfo-compression' flag
'kernel' crate:
- Support allocation flags ('GFP_*'), particularly in 'Box' (via
'BoxExt'), 'Vec' (via 'VecExt'), 'Arc' and 'UniqueArc', as well as
in the 'init' module APIs
- Remove usage of the 'allocator_api' unstable feature
- Remove 'try_' prefix in allocation APIs' names
- Add 'VecExt' (an extension trait) to be able to drop the 'alloc'
fork
- Add the '{make,to}_{upper,lower}case()' methods to 'CStr'/'CString'
- Add the 'as_ptr' method to 'ThisModule'
- Add the 'from_raw' method to 'ArcBorrow'
- Add the 'into_unique_or_drop' method to 'Arc'
- Display column number in the 'dbg!' macro output by applying the
equivalent change done to the standard library one
- Migrate 'Work' to '#[pin_data]' thanks to the changes in the
'macros' crate, which allows to remove an unsafe call in its 'new'
associated function
- Prevent namespacing issues when using the '[try_][pin_]init!'
macros by changing the generated name of guard variables
- Make the 'get' method in 'Opaque' const
- Implement the 'Default' trait for 'LockClassKey'
- Remove unneeded 'kernel::prelude' imports from doctests
- Remove redundant imports
'macros' crate:
- Add 'decl_generics' to 'parse_generics()' to support default
values, and use that to allow them in '#[pin_data]'
Helpers:
- Trivial English grammar fix
Documentation:
- Add section on Rust Kselftests to the 'Testing' document
- Expand the 'Abstractions vs. bindings' section of the 'General
Information' document"
* tag 'rust-6.10' of https://github.com/Rust-for-Linux/linux: (31 commits)
rust: alloc: fix dangling pointer in VecExt<T>::reserve()
rust: upgrade to Rust 1.78.0
rust: kernel: remove redundant imports
rust: sync: implement `Default` for `LockClassKey`
docs: rust: extend abstraction and binding documentation
docs: rust: Add instructions for the Rust kselftest
rust: remove unneeded `kernel::prelude` imports from doctests
rust: update `dbg!()` to format column number
rust: helpers: Fix grammar in comment
rust: init: change the generated name of guard variables
rust: sync: add `Arc::into_unique_or_drop`
rust: sync: add `ArcBorrow::from_raw`
rust: types: Make Opaque::get const
rust: kernel: remove usage of `allocator_api` unstable feature
rust: init: update `init` module to take allocation flags
rust: sync: update `Arc` and `UniqueArc` to take allocation flags
rust: alloc: update `VecExt` to take allocation flags
rust: alloc: introduce the `BoxExt` trait
rust: alloc: introduce allocation flags
rust: alloc: remove our fork of the `alloc` crate
...
|
|
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]>
|
|
The `module!` macro creates glue code that are called by C to initialize
the Rust modules using the `Module::init` function. Part of this glue
code are the local functions `__init` and `__exit` that are used to
initialize/destroy the Rust module.
These functions are safe and also visible to the Rust mod in which the
`module!` macro is invoked. This means that they can be called by other
safe Rust code. But since they contain `unsafe` blocks that rely on only
being called at the right time, this is a soundness issue.
Wrap these generated functions inside of two private modules, this
guarantees that the public functions cannot be called from the outside.
Make the safe functions `unsafe` and add SAFETY comments.
Cc: [email protected]
Reported-by: Björn Roy Baron <[email protected]>
Closes: https://github.com/Rust-for-Linux/linux/issues/629
Fixes: 1fbde52bde73 ("rust: add `macros` crate")
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Wedson Almeida Filho <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Moved `THIS_MODULE` out of the private-in-private modules since it
should remain public, as Dirk Behme noticed [1]. Capitalized comments,
avoided newline in non-list SAFETY comments and reworded to add
Reported-by and newline. ]
Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565-Help/topic/x/near/433512583 [1]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
Add support for generic parameters defaults in `#[pin_data]` by using
the newly introduced `decl_generics` instead of the `impl_generics`.
Before this would not compile:
#[pin_data]
struct Foo<const N: usize = 0> {
// ...
}
because it would be expanded to this:
struct Foo<const N: usize = 0> {
// ...
}
const _: () = {
struct __ThePinData<const N: usize = 0> {
__phantom: ::core::marker::PhantomData<fn(Foo<N>) -> Foo<N>>,
}
impl<const N: usize = 0> ::core::clone::Clone for __ThePinData<N> {
fn clone(&self) -> Self {
*self
}
}
// [...] rest of expansion omitted
};
The problem is with the `impl<const N: usize = 0>`, since that is
invalid Rust syntax. It should not mention the default value at all,
since default values only make sense on type definitions.
The new `impl_generics` do not contain the default values, thus
generating correct Rust code.
This is used by the next commit that puts `#[pin_data]` on
`kernel::workqueue::Work`.
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
The generic parameters on a type definition can specify default values.
Currently `parse_generics()` cannot handle this though. For example when
parsing the following generics:
<T: Clone, const N: usize = 0>
The `impl_generics` will be set to `T: Clone, const N: usize = 0` and
`ty_generics` will be set to `T, N`. Now using the `impl_generics` on an
impl block:
impl<$($impl_generics)*> Foo {}
will result in invalid Rust code, because default values are only
available on type definitions.
Therefore add parsing support for generic parameter default values using
a new kind of generics called `decl_generics` and change the old
behavior of `impl_generics` to not contain the generic parameter default
values.
Now `Generics` has three fields:
- `impl_generics`: the generics with bounds
(e.g. `T: Clone, const N: usize`)
- `decl_generics`: the generics with bounds and default values
(e.g. `T: Clone, const N: usize = 0`)
- `ty_generics`: contains the generics without bounds and without
default values (e.g. `T, N`)
`impl_generics` is designed to be used on `impl<$impl_generics>`,
`decl_generics` for the type definition, so `struct Foo<$decl_generics>`
and `ty_generics` whenever you use the type, so `Foo<$ty_generics>`.
Here is an example that uses all three different types of generics:
let (Generics { decl_generics, impl_generics, ty_generics }, rest) = parse_generics(input);
quote! {
struct Foo<$($decl_generics)*> {
// ...
}
impl<$impl_generics> Foo<$ty_generics> {
fn foo() {
// ...
}
}
}
The next commit contains a fix to the `#[pin_data]` macro making it
compatible with generic parameter default values by relying on this new
behavior.
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
Currently Rust kernel modules have their init code placed in the `.text`
section of the .ko file. I don't think this causes any real problems
for Rust modules as long as all code called during initialization lives
in `.text`.
However, if a Rust `init_module()` function (that lives in `.text`)
calls a function marked with `__init` (in C) or
`#[link_section = ".init.text"]` (in Rust), then a warning is
generated by modpost because that function lives in `.init.text`.
For example:
WARNING: modpost: fs/bcachefs/bcachefs: section mismatch in reference: init_module+0x6 (section: .text) -> _RNvXCsj7d3tFpT5JS_15bcachefs_moduleNtB2_8BcachefsNtCsjDtqRIL3JAG_6kernel6Module4init (section: .init.text)
I ran into this while experimenting with converting the bcachefs kernel
module from C to Rust. The module's `init()`, written in Rust, calls C
functions like `bch2_vfs_init()` which are placed in `.init.text`.
This patch places the macro-generated `init_module()` Rust function in
the `.init.text` section. It also marks `init_module()` as unsafe--now
it may not be called after module initialization completes because it
may be freed already.
Note that this is not enough on its own to actually get all the module
initialization code in that section. The module author must still add
the `#[link_section = ".init.text"]` attribute to the Rust `init()` in
the `impl kernel::Module` block in order to then call `__init`
functions. However, this patch enables module authors do so, when
previously it would not be possible (without warnings).
Signed-off-by: Thomas Bertschinger <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded title to add prefix. ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
Pull rust updates from Miguel Ojeda:
"In terms of lines, most changes this time are on the pinned-init API
and infrastructure. While we have a Rust version upgrade, and thus a
bunch of changes from the vendored 'alloc' crate as usual, this time
those do not account for many lines.
Toolchain and infrastructure:
- Upgrade to Rust 1.71.1. This is the second such upgrade, which is a
smaller jump compared to the last time.
This version allows us to remove the '__rust_*' allocator functions
-- the compiler now generates them as expected, thus now our
'KernelAllocator' is used.
It also introduces the 'offset_of!' macro in the standard library
(as an unstable feature) which we will need soon. So far, we were
using a declarative macro as a prerequisite in some not-yet-landed
patch series, which did not support sub-fields (i.e. nested
structs):
#[repr(C)]
struct S {
a: u16,
b: (u8, u8),
}
assert_eq!(offset_of!(S, b.1), 3);
- Upgrade to bindgen 0.65.1. This is the first time we upgrade its
version.
Given it is a fairly big jump, it comes with a fair number of
improvements/changes that affect us, such as a fix needed to
support LLVM 16 as well as proper support for '__noreturn' C
functions, which are now mapped to return the '!' type in Rust:
void __noreturn f(void); // C
pub fn f() -> !; // Rust
- 'scripts/rust_is_available.sh' improvements and fixes.
This series takes care of all the issues known so far and adds a
few new checks to cover for even more cases, plus adds some more
help texts. All this together will hopefully make problematic
setups easier to identify and to be solved by users building the
kernel.
In addition, it adds a test suite which covers all branches of the
shell script, as well as tests for the issues found so far.
- Support rust-analyzer for out-of-tree modules too.
- Give 'cfg's to rust-analyzer for the 'core' and 'alloc' crates.
- Drop 'scripts/is_rust_module.sh' since it is not needed anymore.
Macros crate:
- New 'paste!' proc macro.
This macro is a more flexible version of 'concat_idents!': it
allows the resulting identifier to be used to declare new items and
it allows to transform the identifiers before concatenating them,
e.g.
let x_1 = 42;
paste!(let [<x _2>] = [<x _1>];);
assert!(x_1 == x_2);
The macro is then used for several of the pinned-init API changes
in this pull.
Pinned-init API:
- Make '#[pin_data]' compatible with conditional compilation of
fields, allowing to write code like:
#[pin_data]
pub struct Foo {
#[cfg(CONFIG_BAR)]
a: Bar,
#[cfg(not(CONFIG_BAR))]
a: Baz,
}
- New '#[derive(Zeroable)]' proc macro for the 'Zeroable' trait,
which allows 'unsafe' implementations for structs where every field
implements the 'Zeroable' trait, e.g.:
#[derive(Zeroable)]
pub struct DriverData {
id: i64,
buf_ptr: *mut u8,
len: usize,
}
- Add '..Zeroable::zeroed()' syntax to the 'pin_init!' macro for
zeroing all other fields, e.g.:
pin_init!(Buf {
buf: [1; 64],
..Zeroable::zeroed()
});
- New '{,pin_}init_array_from_fn()' functions to create array
initializers given a generator function, e.g.:
let b: Box<[usize; 1_000]> = Box::init::<Error>(
init_array_from_fn(|i| i)
).unwrap();
assert_eq!(b.len(), 1_000);
assert_eq!(b[123], 123);
- New '{,pin_}chain' methods for '{,Pin}Init<T, E>' that allow to
execute a closure on the value directly after initialization, e.g.:
let foo = init!(Foo {
buf <- init::zeroed()
}).chain(|foo| {
foo.setup();
Ok(())
});
- Support arbitrary paths in init macros, instead of just identifiers
and generic types.
- Implement the 'Zeroable' trait for the 'UnsafeCell<T>' and
'Opaque<T>' types.
- Make initializer values inaccessible after initialization.
- Make guards in the init macros hygienic.
'allocator' module:
- Use 'krealloc_aligned()' in 'KernelAllocator::alloc' preventing
misaligned allocations when the Rust 1.71.1 upgrade is applied
later in this pull.
The equivalent fix for the previous compiler version (where
'KernelAllocator' is not yet used) was merged into 6.5 already,
which added the 'krealloc_aligned()' function used here.
- Implement 'KernelAllocator::{realloc, alloc_zeroed}' for
performance, using 'krealloc_aligned()' too, which forwards the
call to the C API.
'types' module:
- Make 'Opaque' be '!Unpin', removing the need to add a
'PhantomPinned' field to Rust structs that contain C structs which
must not be moved.
- Make 'Opaque' use 'UnsafeCell' as the outer type, rather than
inner.
Documentation:
- Suggest obtaining the source code of the Rust's 'core' library
using the tarball instead of the repository.
MAINTAINERS:
- Andreas and Alice, from Samsung and Google respectively, are
joining as reviewers of the "RUST" entry.
As well as a few other minor changes and cleanups"
* tag 'rust-6.6' of https://github.com/Rust-for-Linux/linux: (42 commits)
rust: init: update expanded macro explanation
rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`
rust: init: make `PinInit<T, E>` a supertrait of `Init<T, E>`
rust: init: implement `Zeroable` for `UnsafeCell<T>` and `Opaque<T>`
rust: init: add support for arbitrary paths in init macros
rust: init: add functions to create array initializers
rust: init: add `..Zeroable::zeroed()` syntax for zeroing all missing fields
rust: init: make initializer values inaccessible after initializing
rust: init: wrap type checking struct initializers in a closure
rust: init: make guards in the init macros hygienic
rust: add derive macro for `Zeroable`
rust: init: make `#[pin_data]` compatible with conditional compilation of fields
rust: init: consolidate init macros
docs: rust: clarify what 'rustup override' does
docs: rust: update instructions for obtaining 'core' source
docs: rust: add command line to rust-analyzer section
scripts: generate_rust_analyzer: provide `cfg`s for `core` and `alloc`
rust: bindgen: upgrade to 0.65.1
rust: enable `no_mangle_with_rust_abi` Clippy lint
rust: upgrade to Rust 1.71.1
...
|
|
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]>
|
|
With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole")
we are now able to use pahole directly to identify Rust compilation
units (CUs) and exclude them from generating BTF debugging information
(when DEBUG_INFO_BTF is enabled).
And if pahole doesn't support the --lang-exclude flag, we can't enable
both RUST and DEBUG_INFO_BTF at the same time.
So, in any case, the script is_rust_module.sh is just redundant and we
can drop it.
NOTE: we may also be able to drop the "Rust loadable module" mark
inside Rust modules, but it seems safer to keep it for now to make sure
we are not breaking any external tool that may potentially rely on it.
Signed-off-by: Andrea Righi <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Eric Curtin <[email protected]>
Reviewed-by: Eric Curtin <[email protected]>
Reviewed-by: Neal Gompa <[email protected]>
Reviewed-by: Masahiro Yamada <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Acked-by: Daniel Xu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Picked the `Reviewed-by`s from the old patch too. ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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]>
|
|
If we define the same function name twice in a trait (using `#[cfg]`),
the `vtable` macro will redefine its `gen_const_name`, e.g. this will
define `HAS_BAR` twice:
#[vtable]
pub trait Foo {
#[cfg(CONFIG_X)]
fn bar();
#[cfg(not(CONFIG_X))]
fn bar(x: usize);
}
Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro")
Signed-off-by: Qingsong Chen <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Sergio González Collado <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
When using `#[pin_data]` on a struct that used `Self` in the field
types, a type error would be emitted when trying to use `pin_init!`.
Since an internal type would be referenced by `Self` instead of the
defined struct.
This patch fixes this issue by replacing all occurrences of `Self` in
the `#[pin_data]` macro with the concrete type circumventing the issue.
Since rust allows type definitions inside of blocks, which are
expressions, the macro also checks for these and emits a compile error
when it finds `trait`, `enum`, `union`, `struct` or `impl`. These
keywords allow creating new `Self` contexts, which conflicts with the
current implementation of replacing every `Self` ident. If these were
allowed, some `Self` idents would be replaced incorrectly.
Signed-off-by: Benno Lossin <[email protected]>
Reported-by: Alice Ryhl <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added newline in commit message ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
Other macros might also want to parse generics. Additionally this makes
the code easier to read, as the next commit will introduce more code in
`#[pin_data]`. Also add more comments to explain how parsing generics
work.
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
When using `quote!` as part of an expression that was not the last one
in a function, the `#[allow(clippy::vec_init_then_push)]` attribute
would be present on an expression, which is not allowed.
This patch refactors that part of the macro to use a statement instead.
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
This is kernel code, so specifying "kernel" is redundant. Let's simplify
things and just call it to_errno().
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Signed-off-by: Asahi Lina <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
Modules can (and usually do) have multiple alias tags, in order to
specify multiple possible device matches for autoloading. Allow this by
changing the alias ModuleInfo field to an Option<Vec<String>>.
Note: For normal device IDs this is autogenerated by modpost (which is
not properly integrated with Rust support yet), so it is useful to be
able to manually add device match aliases for now, and should still be
useful in the future for corner cases that modpost does not handle.
This pulls in the expect_group() helper from the rfl/rust branch
(with credit to authors).
Co-developed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Co-developed-by: Finn Behrens <[email protected]>
Signed-off-by: Finn Behrens <[email protected]>
Co-developed-by: Sumera Priyadarsini <[email protected]>
Signed-off-by: Sumera Priyadarsini <[email protected]>
Reviewed-by: Vincenzo Palazzo <[email protected]>
Signed-off-by: Asahi Lina <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
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]>
|
|
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]>
|
|
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]>
|
|
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]>
|