Parameter support

[ojeda]

To have more flexibility, switch to a procedural macro instead.

Signed-off-by: Miguel Ojeda [email protected]

[ojeda]

The big thing here is that now we can pass parameters, and they work for both built-in and loadable modules. They appear as usual in modinfo and sysfs, etc. They can be set through the kernel command line too.

The "UI" looks like this now:

module!{
    typename: RustExample,
    name: b"rust_example",
    author: b"Rust for Linux Contributors",
    description: b"An example kernel module written in Rust",
    license: b"GPL v2",
    params: {
        my_bool: bool {
            default_: true,
            permissions: 0,
            description: b"Example of bool",
        },
        my_i32: i32 {
            default_: 42,
            permissions: 0o644,
            description: b"Example of i32",
        },
    },
}

The module can access the parameters directly on init() (or anywhere else) via an object like:

my_i32.read()

I didn't pass them as parameters to init() because parameters sometimes are to be accessed at other points, e.g. via sysfs.

Currently only bool and i32 types work as an example (mapping automatically to the kernel's standard bool and int). Adding support for arrays of types, charp type, custom types, custom get/set operations, etc. will be needed.

[ojeda]

The reason behind the move to a procedural macro is that it allows us to remove the modinfo hack for string generation and also to generate unique identifiers and any other thing we may need.

I wrote the proc macro without the usual syn or quote, since it is easy enough for what we need and avoids adding more dependencies.

[ojeda]

By the way, the missing prefixes for built-in modules is also fixed here, as well as the non-unique symbol names for the built-in modules.

However, several built-in modules still don't work since the crates are still compiled for each module.

[ojeda]

Thanks Alex for another review (and thanks for doing it so quickly -- sorry, I couldn't take another look at this until today)!

[alex]

@geofft FYI, since this is the first substantial deviation from our out-of-tree impl

[geofft]

LGTM, thanks for the ping. I didn't realize writing proc macros was this doable with stable, that's cool!

We can probably get rid of the b (I've been wanting to get rid of it anyway, there's just no way to do it with macro_rules) but whatever.