You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider removing the initcall logic from module.rs, use codegen instead #77
Currently we duplicate a bit of logic on the Rust side for our initcall handling.
Consider performing codegen instead to be able to reuse the C macros instead. This is basically the approach we took in rust/exports.c too. Even if may look ugly, it is best to avoid redoing parts of the C infrastructure.
This would also remove our need for the unstable global_asm!.
Please note it is quite an open-ended issue though, and how to do it best is not clear (I say this because sometimes with this kind of issue one may do a lot of work to then find a given approach was not a good idea to begin with. It is also why I wrote "Consider" in the title).
Checking my understanding.
The goal is actually to replace handwritten init_module,cleanup_module and the way we use initcall with existing corresponding c's functions correct? and the suggestion is to generate these FFI via bindgen correct?
I have few questions: Hope you can clarify.
I see from the code that those function eventually calls __init() and __exit() functions, which just set __MOD variable to Some(m) and None respectively. I don't understand what is this __MOD and where is it comes from? I grepped through the code and couldn't figure out.
I don't quite understand how do we even replace _initcall function, it use bare asm.
The goal is actually to replace handwritten init_module,cleanup_module and the way we use initcall with existing corresponding c's functions correct? and the suggestion is to generate these FFI via bindgen correct?
Not exactly! The idea is to generate a C source file on the fly that contains the invocations of the MODULE_* macros from the module! call. Then, compile that C file and link it with the module automatically.
I don't understand what is this __MOD and where is it comes from? I grepped through the code and couldn't figure out.
__MOD represents the module (it is an Option of the type that the user specified in module!) and is generated in rust/module.rs:
Activity
kavirajk commentedon Mar 21, 2021
Can I work on this? :)
ojeda commentedon Mar 21, 2021
Sure!
Please note it is quite an open-ended issue though, and how to do it best is not clear (I say this because sometimes with this kind of issue one may do a lot of work to then find a given approach was not a good idea to begin with. It is also why I wrote "Consider" in the title).
kavirajk commentedon Mar 24, 2021
@ojeda Thanks for the heads up :)
Checking my understanding.
The goal is actually to replace handwritten
init_module,cleanup_moduleand the way we useinitcallwith existing corresponding c's functions correct? and the suggestion is to generate these FFI via bindgen correct?I have few questions: Hope you can clarify.
I see from the code that those function eventually calls
__init()and__exit()functions, which just set__MODvariable toSome(m)andNonerespectively. I don't understand what is this __MOD and where is it comes from? I grepped through the code and couldn't figure out.I don't quite understand how do we even replace
_initcallfunction, it use bare asm.Thanks in advance for your time :)
ojeda commentedon Mar 25, 2021
Not exactly! The idea is to generate a C source file on the fly that contains the invocations of the
MODULE_*macros from themodule!call. Then, compile that C file and link it with the module automatically.__MODrepresents the module (it is anOptionof the type that the user specified inmodule!) and is generated inrust/module.rs:linux/rust/module.rs
Line 584 in 4f0e492
dmaengine: xilinx: dpdma: initialize registers before request_irq
cifs: fix use-after-free on the link name
mm: kmem: properly initialize local objcg variable in current_obj_cgr…
bpf: Fix a few selftest failures due to llvm18 change
ocfs2: check tl->count of truncate log inode in ocfs2_get_truncate_lo…
fs/dax: Fix "don't skip locked entries when scanning entries"
ocfs2: check tl->count of truncate log inode in ocfs2_get_truncate_lo…