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

Remove specialization of hvt tender at unikernel compile time #326

Closed
2 tasks done
mato opened this issue Feb 20, 2019 · 6 comments
Closed
2 tasks done

Remove specialization of hvt tender at unikernel compile time #326

mato opened this issue Feb 20, 2019 · 6 comments

Comments

@mato
Copy link
Task lists! Give feedback
Member

@mato mato commented Feb 20, 2019

A long-standing design issue in Solo5 is the specialization of the hvt tender being done at unikernel compile time, which is a hold-over from the days of ukvm.

With the introduction of the spt tender the problem has become even more pronounced, so the time has come to remove this concept from the codebase.

Among other things (see linked mailing list post for more), this change is blocking:

  • A sane supply chain, allowing the operator (not the developer) to supply the solo5-hvt tender. This is a pre-requisite for a better deployment story, e.g. integration with libvirt-based systems for deployment.
  • Sharing code between the hvt and spt tenders (e.g. ELF loader, common host device/module setup code).
  • Support for multiple instances of block/network devices, and support for "future" devices (e.g. host-only communication channels).

The following sub-tasks are part of this work:

  1. Build system re-factoring (see comment below) and removing hvt compile-time specialization with minimal changes to the current codebase. (#345)

  2. Share common code between tenders. (#364)
    Details:

  3. As a start, we will build one solo5-hvt two tenders, solo5-hvt with all non-debug modules and solo5-hvt-debug including debug modules. the tender will allow any combination of devices to be enabled at run time, i.e. post this step it will no longer enforce any contract between the unikernel and its host on what resources (network, block devices) are required by the unikernel to run.

  4. Tenders need to be able to share common code, as the upcoming support for multiple devices will introduce more common functionality.

After this is complete I will raise a separate issue to deal with the actual implementation of multiple device support and adding back the enforcement of the host/unikernel contract by the tender as the two are ultimately intertwined.

@mato mato self-assigned this Feb 20, 2019
@mato
Copy link
Member Author

@mato mato commented Mar 5, 2019

Progress update: Working on this has led to an overdue refactoring of the build system, with the following overall goals:

  1. Correct dependency handing. i.e. make must always rebuild what has changed, with a minimal amount of dependencies specified manually in Makefiles.
  2. Clear data flow throughout the build system. The build system needs to produce four groups of artifacts (bindings for A targets, B tenders for the host, C tests for A targets and D .pc files for use by OPAM), using different compilers (or flags). As things currently stand, the number of combinations leads to unmaintainable spaghetti code.
  3. Removing as much repetition as possible, without going too deep into GNU make "magic" (limiting use of macros and $$$$(FOO) unless absolutely necessary). Otherwise use best practices where possible.
  4. Allow for sharing of common code between tenders.

Unfortunately there are far too many ways to shoot oneself in the foot with GNU make, so this will take some time to stabilise.

For those that want to follow along, my work in progress branch is at https://github.com/mato/solo5/tree/wip-no-specialization. This is not yet functional with OPAM/MirageOS.

@mato
Copy link
Member Author

@mato mato commented Mar 15, 2019

Progress update: The last week or so has been spent writing an end to end smoketest for Mirage/Solo5, and learning a lot of OCaml along the way! The E2E test is needed in order for me to be able to reproducibly test Solo5 API and build system changes against downstream Mirage/Solo5 using a single command (i.e. score the "Can you make an (end to end) build in one step?" on the Joel Test).

The E2E code temporarily lives at https://github.com/mato/e2e-mirage-solo5, and will likely move into the Solo5 repository under tests/ for practical reasons once I'm happy with it.

@mato
Copy link
Member Author

@mato mato commented Mar 22, 2019

Progress update: The E2E tests have been merged in #340. Next up will be a PR with the build system refactor and removal of compile-time hvt specialization (step 1 here).

@mato
Copy link
Member Author

@mato mato commented Mar 27, 2019

PR for step 1 is now in #345.

@ehmry
Copy link
Contributor

@ehmry ehmry commented Mar 28, 2019

@mato looks good to me, tests still pass.

@mato
Copy link
Member Author

@mato mato commented May 24, 2019

Edited to reflect that this issue does not consider the actual changes for multiple device support, but only preparatory work (build system refactoring, sharing common code between tenders). All done here, so closing.

@mato mato closed this May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants