Hard code require kernel version in process loading

[Ioan-Cristian]

Currently, required kernel version is hard coded in the code. I suggest changing this in two ways:

1. If newer Tock kernel versions are designed to always ask for a minimum required kernel version, then remove the parameter from ProcessStandard::create

2. If the current design still envisages the option not to require a minimum kernel version, then:

   • add a new config variable
   • use a constant generic to allow board users to determine if a minimum kernel version should be required

What do you think? I'm willing to implement either solution.

[bradjc]

When we added kernel version checking, we decided that it is up to the specific kernel (ie board) if it wanted to enforce the check or not, hence the argument to ProcessStandard::create(). What is the reason to change that?

We might only have code in the upstream repo that sets it to true, but the expectation was that out-of-tree boards might want to do it differently.

[Ioan-Cristian]

I understand that downstream projects might not want to require a minimum kernel version. However, my general expectation is that one shouldn't dive into kernel's source code if they want to configure it. In my opinion, kernel configuration should be done either at board level or through configuration parameters. Note that my second proposed solution doesn't prevent Tock upstream code to continue enforcing minimum kernel version:

• config variable: set to true upstream. Downstream projects may change it depending on their needs.
• constant generic: load_processes and load_and_check_processes take a boolean constant generic parameter that is set to true in upstream board files. Its value can be changed on a board by board basis by downstream projects.

The difference between the two approaches is evident:

• config variable: configuration at kernel level
• constant generic: configuration at board level

I would opt for the second approach since it allows finer configuration. However, such fine configuration may be considered unnecessary. In this case, the first approach is more suitable.

[lschuermann]

I'd be happy with a const generic for this. However, boolean const generics don't carry much inherent meaning when you just look at the instantiation. Similar to how such runtime parameters are more cleanly passed as enums, we can pass this as types:

trait KernelVersionEnforcement {
    fn enforce_mininum_kernel_version() -> bool;
}

enum EnforceMinimumKernelVersion {}
impl KernelVersionEnforcement for EnforceMinimumKernelVersion { ... }

enum SkipVersionCheck {}
impl KernelVersionEnforcement for SkipVersionCheck { ... }

Perhaps with better type names. This would allow us to also ship more granular policies in the future, while not breaking any APIs.

[bradjc]

Calling ProcessStandard::create(..., true, ...) is at the board level. The process_loading functions are just helpers that boards can choose to use, and can use different variants if they want.

[Ioan-Cristian]

However, boolean const generics don't carry much inherent meaning when you just look at the instantiation.

This can be easily avoided by using a const:

const MY_CONST: bool = true;

my_function::<MY_CONST>(...)

Calling ProcessStandard::create(..., true, ...) is at the board level. The process_loading functions are just helpers that boards can choose to use, and can use different variants if they want.

I always thought process loading should be done through process loading functions. Is there any upstream board that doesn't use the process loading functions? Do you know any downstream project that doesn't rely on process loading functions?

[bradjc]

I always thought process loading should be done through process loading functions. Is there any upstream board that doesn't use the process loading functions? Do you know any downstream project that doesn't rely on process loading functions?

No, and, well, no. But it is a very conscious design choice since we added shared process loading functions back in #511.

[jrvanwhy]

Do you know any downstream project that doesn't rely on process loading functions?

I think Ti50 has their own process loading logic, though I'm not 100% sure of that.

[bradjc]

Boards need the option to be able to disable version checking, but they do not need to be able to dynamically choose whether to check versions or not (say to do it for some process binaries but not others).

I think a reasonable next step would be to:

1. Change ProcessBinary to use a const to avoid the dynamic bool we don't need.
2. Mark this as something to remove entirely after the next 2.x release, as I think it is reasonable at this point that all boards want to do version checking.