feat(env): parse env=KEY=VALUE for env vars

[mkroening]

This PR

1. unifies FDT bootargs parsing across all platforms,
2. adds env=KEY=VALUE kernel arguments for environment variable initialization, and
3. disables the Uhyve CMDSIZE and CMDVAL hypercalls to use the kernel-maintained environment on Uhyve (breaking).

Questions

1. Should we use the proposed env=KEY=VALUE format? This differs from our current format for other kernel arguments, such as -freq FREQ and -ip IP. I think we should migrate those to freq=FREQ and ip=IP eventually.
2. Do we need to support = in environment variable names?
3. Should we immediately disable the Uhyve hypercalls (easy)? This would break older versions of Uhyve, but I don't think this is a big problem. Alternatively, we could merge the Uhyve hypercall environment with the kernel one (complicated), or we only use the kernel environment when Uhyve returns an empty one (medium).

Extracted 0. commit: #1396
Corresponding Uhyve PR: hermit-os/uhyve#758

[jounathaen]

I like brief doc comments on functions, but this is a personal preference.

Shouldn't these functions be pub (crate)?

[mkroening]

Shouldn't these functions be pub (crate)?

I prefer not setting the export scope when the whole module is private.

[jounathaen]

Couldn't we throw out these functions while we are on it?

[mkroening]

We can do away with these architecture-specific bootargs once we have migrated all platforms to FDT bootargs and do the bootinfo version jump. We still have the bootargs in the bootinfo for x86-64 QEMU and Linux boot.

[jounathaen]

LGTM

Should we use the proposed env=KEY=VALUE format? This differs from our current format for other kernel arguments, such as -freq FREQ and -ip IP. I think we should migrate those to freq=FREQ and ip=IP eventually.

Sounds reasonable.

Do we need to support = in environment variables? That would require some tuning of shell_words, I think.

I think this is a must. It is exotic, but would lead to some strange bugs if there is just some environment that uses it.

Should we immediately disable the Uhyve hypercalls (easy)? This would break older versions of Uhyve, but I don't think this is a big problem. Alternatively, we could merge the Uhyve hypercall environment with the kernel one (complicated), or we only use the kernel environment when Uhyve returns an empty one (medium).

Just throw them out. On my V2 of the uhyve interface, these are also not present anymore. I doubt that uhyve is used "in production" right now.

[mkroening]

Do we need to support = in environment variables? That would require some tuning of shell_words, I think.

I think this is a must. It is exotic, but would lead to some strange bugs if there is just some environment that uses it.

I have implemented support for = in environment variable values, but not in names. This is fine according to POSIX.

Just throw them out.

👍