Complete kernel params support

[ojeda]

#7 introduces the machinery to support kernel parameters, but there are some things to do:

• bool and i32 — Parameter support #7
• u8, u16, u32, u64 and i16 — Add charp and some primitive param types #82
• charp/string — Add charp and some primitive param types #82 and Array and string params #110
• invbool was added a long time ago but was only ever used by 2 modules or so: we decided not to support it — Add charp and some primitive param types #82
• bint was added a long time ago, used by about 8 modules, but users should probably use bool properly instead.
• bool_enable_only was added in 2015, but it is used by 1 module only, so we can skip it for now.
• hexint was added in 2020 but only 1 amdgpu module uses it so far, so we can skip it for now. We could also consider having our own parser for the primitive types, accepting hex/oct/bin etc. automatically, rather than have different param types like this one.
• i128 and u128: we forbid code using 128-bit integers.
• i8, i64, usize and isize — Add Rust int param types #87
• Arrays — Array and string params #110
• unsafe flag (taints kernel)
• hwparam flag + hwparam_type: probably another key in the dictionary, or use wrapper types.
• An easy interface to provide custom types/ops (create a trait for it etc.)

[kloenk]

Not sure if I understand. What are those for settings? are they from the build system?

[ojeda]

Kernel modules can take parameters that you pass either in the kernel command line for builtins or through insmod/modprobe for loadable ones. They can also optionally be modified on the fly through sysfs.

[ojeda]

Updated the list and added some information on some of the missing ones and rationale for skipping some of them.

[adamrk]

Why don't we want i128 and u128?

[adamrk]

One question for arrays and custom types is how we expand the macro parsing logic. Currently we're limited to parsing identifiers for the param type and identifiers or literals for the the default value, but at least for custom types I'd think people would expect more flexibility. Should we consider bringing in the syn crate?

[ojeda]

Why don't we want i128 and u128?

We don't support their intrinsics (which, to be fair, are only needed for some ops). Having said that, we could bring them if we want them (it is not like floating-point with its environment etc.), but I don't know what they could be used for. In any case, for parameters it is even less likely they are needed.

but at least for custom types I'd think people would expect more flexibility

Do you have an example in mind? Perhaps you are thinking of parameters that could support things like passing a dictionary?

[adamrk]

We don't support their intrinsics (which, to be fair, are only needed for some ops). Having said that, we could bring them if we want them (it is not like floating-point with its environment etc.), but I don't know what they could be used for. In any case, for parameters it is even less likely they are needed.

Makes sense.

Do you have an example in mind? Perhaps you are thinking of parameters that could support things like passing a dictionary?

With the existing logic you can't have the following param

        my_i32: i32 {
            default: core::i32::MAX,
            permissions: 0o644,
            description: b"Example of i32",
        },

because core::i32::MAX isn't an identifier. I expect that's not a big deal for the standard params, but if someone implements custom param ops for Option<u8> then the following will also fail

        my_custom_param: Option<u8> {
            default: Some(5),
            permissions: 0o644,
            description: b"Example of custom param",
        },

because neither Option<u8> nor Some(5) are identifiers. This is something that I imagine people would expect to just work. But to make it work we'll need the ability to parse types and expressions which we could get from syn.

[ojeda]

Those are two good examples!

Hmm... For the moment, I think it is best to avoid any extra dependency if possible. I believe the slimmer we are (within reason), the best chances we have to get into mainline. Afterwards, it is easier to integrate more things as needed.

For the time being, I think it is a reasonable constraint on the params. I mean, we could even go without params support at all, but I thought it was a nice touch to have them ready to some degree, since many drivers use them, plus it showed how nice the module declaration could look like in Rust.

Note that I am in favor of supporting such cases/examples, just perhaps not right away. I am open to hearing other viewpoints, though (e.g. we could use it to showcase what we can do in the Rust side that isn't possible in the C side -- i.e. easily writing safe parsers etc.).

[ojeda]

Edited with #87.