Expose config outside of crosvm crate?

[Sargun Dhillon]

Right now, the config (https://crosvm.dev/doc/crosvm/crosvm/config/struct.Config.html) is in the root crate. Unfortunately, we do not expose the root crate as a library, so anyone who wants to programmatically generate the config for crosvm is stuck doing it themselves.

It is pretty deeply tied into the crate because it depends on internal data types. I do not think it's practical to break it out into its own crate. What do folks here think about making the root crate available as a library, to at least expose the config (and we can use module visibility to inhibit other things from being accidentally exposed).

[Daniel Verkamp]

On Thu, May 23, 2024 at 10:33 AM Sargun Dhillon <sar...@sargun.me> wrote:
>
> Right now, the config (https://crosvm.dev/doc/crosvm/crosvm/config/struct.Config.html) is in the root crate. Unfortunately, we do not expose the root crate as a library, so anyone who wants to programmatically generate the config for crosvm is stuck doing it themselves.
>
> It is pretty deeply tied into the crate because it depends on internal data types. I do not think it's practical to break it out into its own crate. What do folks here think about making the root crate available as a library, to at least expose the config (and we can use module visibility to inhibit other things from being accidentally exposed).

Hi Sargun,

Good question, although I don't think we have a great answer
currently. The configuration that is intended for crosvm users is the
RunCommand struct, which is used for both command line and
configuration file parsing, but similar to Config (which is only meant
to be internal to crosvm), it depends on a lot of internal definitions
that we don't necessarily want to be part of a public API.

I agree it would make sense to have a separate, public crate that only
defines the configuration structures that can be used both inside and
outside of crosvm. Also, ideally it would be updated in a
semver-compatible way, i.e. any breaking changes get a new major
version number (at least once we have stabilized the cmdline/config
file format and cleaned up the deprecated options). This should
hopefully not be too hard, but requires a bunch of careful
refactoring, making sure the existing command line options don't
change/break in subtle ways, such as fields that use serde rename
directives or custom parsing functions. It might also be a bit
challenging to avoid some code duplication; for example, several
options use PciAddress and rely on its custom parsing routine, which
would ideally not need to be duplicated in both the devices crate and
the config crate. I'm not sure how we would resolve situations like
that cleanly.

Until somebody tackles that, I think the easiest thing is to write
your own small wrapper that programmatically generates a
semantically-valid and correctly-quoted command line or JSON config
file covering your specific use case; you can take a look at the
ChromeOS vm_tools/concierge/vm_builder.{cc,h} as an example, although
that API is not ideal is some ways and is still being improved.

Thanks,
-- Daniel