Use consistent terminology to refer to various parts of an Oak application

[tiziano88]

I suggest the following crate names (which will match folder names, as well as compiled binary names); e.g. for an application such as "Oak Functions":

• oak_functions_bin_freestanding
  • "trusted" "bare metal" bootable binary (already linked with the Oak Restricted Kernel)
  • renamed from https://github.com/project-oak/oak/tree/main/experimental/oak_baremetal_app_crosvm
• oak_functions_bin_linux_fd
  • "trusted" linux-based executable binary listening on file descriptor
  • renamed from https://github.com/project-oak/oak/tree/main/experimental/oak_functions_loader_linux_native
• oak_functions_bin_linux_vsock
  • "trusted" linux-based executable binary listening on vsock
  • renamed from https://github.com/project-oak/oak/tree/main/experimental/oak_functions_loader_linux_vsock
• oak_functions_launcher
  • "untrusted" linux untrusted launcher, using either qemu / crosvm or a linux subprocess in order to run the trusted binary
  • renamed from https://github.com/project-oak/oak/tree/main/experimental/oak_baremetal_launcher

In particular, for a given application, the untrusted part has the suffix _launcher, while the trusted part has the suffix _bin, plus extra qualifiers about the environment in which it is meant to run.

Eventually, when we separate user space from kernel space in Oak Restricted Kernel, then the user space application will have suffix app; then a script / build process of some sort will generate the bin artifact by linking the app with the Oak Restricted Kernel itself.

Note I also suggest using the term "freestanding" instead of "bare-metal" going forward, since that's also what's used in C++ terminology; "bare-metal" is also already used to describe booting without virtualization at all (i.e. on the bare metal hardware instead of virtualized hardware), which came up a few times in discussions and caused confusion (and I expect will come up again when talking about different hardware configurations).

@conradgrobler @andrisaar WDYT?

[conradgrobler]

Makes sense. I agree that we should stop using the term "bare-metal".

[andrisaar]

I agree that we should deprecate the "bare-metal" term. It's a misnomer.

What about the other oak_baremetal_ crates, especially the runtime? That should be renamed to have a oak_functions_ prefix as well. oak_functions_runtime?

[ipetr0v]

From github updates:

rename {experimental/oak_baremetal_runtime => oak_functions_freestanding}

I think freestanding is not intuitive and doesn't describe what the object is. It's also not a noun.

[tiziano88]

Thanks Ivan; that particular crate is a library, not a binary, so I don't expect that it needs to end with a noun (unlike the binary crates, which now consistently end in _bin). Anyways I am also thinking of removing the freestanding suffix from all non-binary crates entirely, and leave it to developer to figure out what's no_std-compatible and what not. @andrisaar also suggested this in #3311

[ipetr0v]

I think standalone may be more understandable than freestanding.

But we need to come up with a shorter and more intuitive name for the "thing that runs in the VM".