| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit e26fa546042a ("rust: kbuild: auto generate helper exports")
removed the need for these by automatically generating the exports; it
removed the explicit uses of `EXPORT_SYMBOL_GPL` but didn't remove the
`#include <linux/export.h>`s.
Signed-off-by: Tamir Duberstein <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
In case CONFIG_PREEMPT_RT is enabled __mutex_init() becomes a macro
instead of an extern function (simplified from
include/linux/mutex.h):
#ifndef CONFIG_PREEMPT_RT
extern void __mutex_init(struct mutex *lock, const char *name,
struct lock_class_key *key);
#else
#define __mutex_init(mutex, name, key) \
do { \
rt_mutex_base_init(&(mutex)->rtmutex); \
__mutex_rt_init((mutex), name, key); \
} while (0)
#endif
The macro isn't resolved by bindgen, then. What results in a build
error:
error[E0425]: cannot find function `__mutex_init` in crate `bindings`
--> rust/kernel/sync/lock/mutex.rs:104:28
|
104 | unsafe { bindings::__mutex_init(ptr, name, key) }
| ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init`
|
::: rust/bindings/bindings_generated.rs:23722:5
|
23722 | / pub fn __mutex_rt_init(
23723 | | lock: *mut mutex,
23724 | | name: *const core::ffi::c_char,
23725 | | key: *mut lock_class_key,
23726 | | );
| |_____- similarly named function `__mutex_rt_init` defined here
Fix this by adding a helper.
As explained by Gary Guo in [1] no #ifdef CONFIG_PREEMPT_RT
is needed here as rust/bindings/lib.rs prefers externed function to
helpers if an externed function exists.
Reported-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/rust-for-linux/20240913-shack-estate-b376a65921b1@spud/
Link: https://lore.kernel.org/rust-for-linux/[email protected]/ [1]
Fixes: 6d20d629c6d8 ("rust: lock: introduce `Mutex`")
Signed-off-by: Dirk Behme <[email protected]>
Tested-by: Conor Dooley <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded to include the proper example by Dirk. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
This removes the need to explicitly export all symbols.
Generate helper exports similarly to what's currently done for Rust
crates. These helpers are exclusively called from within Rust code and
therefore can be treated similar as other Rust symbols.
Signed-off-by: Gary Guo <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Tested-by: Boqun Feng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Fixed dependency path, reworded slightly, edited comment a bit and
rebased on top of the changes made when applying Andreas' patch
(e.g. no `README.md` anymore, so moved the edits). - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
|
|
This patch splits up the rust helpers C file. When rebasing patch sets on
upstream linux, merge conflicts in helpers.c is common and time consuming
[1]. Thus, split the file so that each kernel component can live in a
separate file.
This patch lists helper files explicitly and thus conflicts in the file
list is still likely. However, they should be more simple to resolve than
the conflicts usually seen in helpers.c.
[ Removed `README.md` and undeleted the original comment since now,
in v3 of the series, we have a `helpers.c` again; which also allows
us to keep the "Sorted alphabetically" line and makes the diff easier.
In addition, updated the Documentation/ mentions of the file, reworded
title and removed blank lines at the end of `page.c`. - Miguel ]
Link: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/Splitting.20up.20helpers.2Ec/near/426694012 [1]
Signed-off-by: Andreas Hindborg <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Acked-by: Dirk Behme <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
|