Consider removing the initcall logic from module.rs, use codegen instead

[ojeda]

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!.

[kavirajk]

Can I work on this? :)

[ojeda]

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]

@ojeda Thanks for the heads up :)

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.

1. 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.

2. I don't quite understand how do we even replace _initcall function, it use bare asm.

Thanks in advance for your time :)

[ojeda]

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:

linux/rust/module.rs

Line 584 in 4f0e492

static mut __MOD: Option<{type_}> = None;