Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[vmm] refactor vmm builder code to separate the architecture dependent code in their own modules #4411

Open
wearyzen opened this issue Jan 29, 2024 · 1 comment
Labels
Good first issue Indicates a good issue for first-time contributors Priority: Low Indicates that an issue or pull request should be resolved behind issues or pull requests labelled ` Status: Parked Indicates that an issues or pull request will be revisited later

Comments

@wearyzen
Copy link
Contributor

Description

The vmm crate hosts most of the modules that implement the Firecracker functionality. Moreover, at its "top-level", mainly lib.rs and builder.rs includes the logic for creating the Vmm the object that describes a Firecracker microVM. The logic for creating Vmm objects is divided between lib.rs and builder.rs. Moreover, this functionality includes a lot of architecture specific code that has been gathered along the years to a code-base the logic of which is hard to follow "sometimes".

Action Items

A nice way to refactor this (and hopefully make it less painful to follow), would be to isolate the logic for building the Vmm in its own module and isolate the architecture specific code in their own sub-modules, one for each architecture.

Acceptance criteria

  1. Do the refactoring. Focus only on the logic related with the building the Vmm object
  2. Ensure that we didn't break something along the way (all the tests are still passing after the refactor).
@andr3wy
Copy link
Contributor

andr3wy commented Apr 3, 2024

Hi everyone,

We're a group at UT Austin and we're interested in picking this issue up. Do you have any estimates for how long this will take?

@roypat roypat added Good first issue Indicates a good issue for first-time contributors Status: Parked Indicates that an issues or pull request will be revisited later labels Aug 12, 2024
@Manciukic Manciukic added the Priority: Low Indicates that an issue or pull request should be resolved behind issues or pull requests labelled ` label Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good first issue Indicates a good issue for first-time contributors Priority: Low Indicates that an issue or pull request should be resolved behind issues or pull requests labelled ` Status: Parked Indicates that an issues or pull request will be revisited later
Projects
None yet
Development

No branches or pull requests

4 participants