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

Allow qubesdb to be used under Xen #807

Merged
merged 2 commits into from Mar 9, 2017

Conversation

Projects
None yet
3 participants
@talex5
Copy link
Contributor

talex5 commented Mar 7, 2017

-t qubes is useful to run generic unikernels on Qubes, but for Qubes-specific unikernels we need to use the Xen target so that we can control the agents directly.

See e.g. talex5/qubes-mirage-skeleton#2

Allow qubesdb to be used under Xen
`-t qubes` is useful to run generic unikernels on Qubes, but for
Qubes-specific unikernels we need to use the Xen target so that we
can control the agents directly.

@talex5 talex5 referenced this pull request Mar 8, 2017

Merged

Update to mirage 3 #3

@yomimono yomimono merged commit f0b71a5 into mirage:master Mar 9, 2017

6 checks passed

ci/datakit/1 V1.2 Build V1.2 Build
Details
ci/datakit/2 V1.2 Revdeps V1.2 Revdeps
Details
ci/datakit/3 V1.2 Compilers V1.2 Compilers
Details
ci/datakit/4 V1.2 Common Distros V1.2 Common Distros
Details
ci/datakit/5 V1.2 All Distros V1.2 All Distros
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@yomimono

This comment has been minimized.

Copy link
Member

yomimono commented Mar 9, 2017

thanks @talex5 !

@hannesm

This comment has been minimized.

Copy link
Member

hannesm commented Mar 9, 2017

it looks weird to me to have a qubes target and nevertheless use -t xen for unikernels running on qubes. is it worth having a qubes target? can the qubes target be massaged to allow controllng the agents explicitly?

@yomimono

This comment has been minimized.

Copy link
Member

yomimono commented Mar 9, 2017

is it worth having a qubes target?

I was kind of on the fence about -t qubes, but the only other way I could think of to get the thing I needed (automatic building of unikernels bootable on Qubes without changing the config or unikernel) was to add something like --with-qubes, which would then be invalid for all targets but -t xen. -t qubes seemed more honest.

This PR is for users who are trying to accomplish a different goal than I was -- they're willing to forego being able to run their unikernels unmodified on other targets and have explicitly put the dependency in their configs.

can the qubes target be massaged to allow controllng the agents explicitly?

Generally, we should provide methods for overriding the various stubs that -t qubes gives you by default. This was left as a TODO in the original PR... further PRs welcome ;)

@hannesm

This comment has been minimized.

Copy link
Member

hannesm commented Mar 9, 2017

what about qrexec and gui_qubes then (both in mirage.mli)? do they need to be allowed on xen as well?

instead of including more workarounds for xen and qubes, why don't finish the TODO items, and have qubes unikernels built with -t qubes, always!?

@talex5

This comment has been minimized.

Copy link
Contributor Author

talex5 commented Mar 9, 2017

Mirage doesn't seem to have a good way to override defaults. We had the same problem with the log reporter (if you specify a logger you should get that, but if you don't then you should get a default instead). We solved that with a custom argument to register.

We could expose qrexec and gui_qubes, but there's little benefit since if you want to target Qubes then you can create these manually. qubesdb is special only because we need it to set up networking and that's a pain to do manually.

@hannesm

This comment has been minimized.

Copy link
Member

hannesm commented Mar 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.