Rename `env.rs` to `args.rs` or `cli.rs`.

[jounathaen]

My association of the name env would be environment variables. However, env.rs is only about kernel parameters/the CLI.

I suggest renaming env.rs to args.rs or cli.rs

[mkroening]

This currently follows std::env.

The module is about inspection of the kernel's environment, be it via kernel arguments or environment variables or boot information or similar.

I'd suggest keeping it as is and making sure it's properly documented.

[jounathaen]

But std::env is about Environment variables ("Userspace"). Here we are talking about the kernel "runtime" parameters.

This is in general rather confusing, an example:

• The struct cli contains a variable env_vars which is filled with four possible environment variables from the kernel command line (in arch::init)
  • -> These are only the "environment variables" relevant for the kernel (these actually aren't environment variables at all).
  • An application can't read them
• The "real"/application relevant environment variables are retrieved via systemcall (

  kernel/src/lib.rs

  Line 157 in c41204e

  let (argc, argv, environ) = syscalls::get_application_parameters();

  ) and then passed to main.

[mkroening]

But std::env is about Environment variables ("Userspace"). Here we are talking about the kernel "runtime" parameters.

Exactly, std::env is about the environment of the application and hermit::env is about the environment of the kernel, which is a superset of the environment of the application.

Cli parses kernel arguments and provides them as kernel environment variables to other components of the kernel (hermit::env::vars correspond to std::env::vars). The fact that these are provided via kernel arguments instead of any other mechanism is an implementation detail.

The struct cli contains a variable env_vars which is filled with four possible environment variables from the kernel command line (in arch::init)

* -> These are only the "environment variables" relevant for the kernel (these actually aren't environment variables at all).

* An application can't read them

Being a top-level module in does not imply exposition to the user.

• The "real"/application relevant environment variables are retrieved via systemcall

Yes, most system calls live in hermit::syscalls.

[jounathaen]

I understand the reasoning behind the name, but I still don't think it is a good one. The name is IMHO already strongly associated with another concept. I propose one of the following:

• runtime_params.rs => e.g., let mhz = runtime_params::freq().ok_or(err: ())?; -> my favorite
• args.rs => e.g., let mhz = args::freq().ok_or(err: ())?;
• cli.rs => e.g., let mhz = cli::freq().ok_or(err: ())?; -> Not a big fan of this one myself