You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For discovering what options are available for a Mirage unikernel binary there are a number of paths:
Having the source code available and the mirage tool installed you can run mirage describe. This is easy if you built the unikernel yourself.
Having the source code available you can inspect the config.ml file1 and read the source code to discover what options are available.
Run the unikernel binary with argument --help. This has the nice property that you don't need to have the mirage tool and you don't need access to the unikernel source code. The downside is that it may require some setup in order to just run the unikernel with --help: for solo5 you need to figure out the devices required in the solo5 manifest and set them up -- and you may want to use dummy interfaces.
I think it is worth focusing on the case where you don't have the source code available. This is useful for binary distribution of unikernel applications, but also for when you can't find the correct revision of the source code the application was built from.
An idea I had was to write a script for solo5 at least that would read the manifest and set up the required dummy devices and then running the unikernel with --help. I'm not sure if this is feasible as devices can in connect () do network and block operations and raise if that fails. This might interfere with --help (I'm not sure; needs investigating). Setting up the dummy devices could also be a challenge. As demonstrated in https://github.com/reynir/mirage-cat we can get away with using other files than tap devices as network devices. For block devices there are requirements that the file is at least one block (and a block is a multiple of 2 >= 512). Perhaps a way forward is to develop solo5 tenders with dummy net and block devices...
For the unix target I think it is always straight forward to run with --help (please correct me if I am mistaken). For Xen (and Qubes) I suspect it is as well a bit cumbersome to run --help.
Footnotes
This is the case of the current release. In current main you may have to look at other files, too... ↩
The text was updated successfully, but these errors were encountered:
For discovering what options are available for a Mirage unikernel binary there are a number of paths:
mirage describe
. This is easy if you built the unikernel yourself.config.ml
file1 and read the source code to discover what options are available.--help
. This has the nice property that you don't need to have the mirage tool and you don't need access to the unikernel source code. The downside is that it may require some setup in order to just run the unikernel with--help
: for solo5 you need to figure out the devices required in the solo5 manifest and set them up -- and you may want to use dummy interfaces.I think it is worth focusing on the case where you don't have the source code available. This is useful for binary distribution of unikernel applications, but also for when you can't find the correct revision of the source code the application was built from.
An idea I had was to write a script for solo5 at least that would read the manifest and set up the required dummy devices and then running the unikernel with
--help
. I'm not sure if this is feasible as devices can inconnect ()
do network and block operations and raise if that fails. This might interfere with--help
(I'm not sure; needs investigating). Setting up the dummy devices could also be a challenge. As demonstrated in https://github.com/reynir/mirage-cat we can get away with using other files than tap devices as network devices. For block devices there are requirements that the file is at least one block (and a block is a multiple of 2 >= 512). Perhaps a way forward is to develop solo5 tenders with dummy net and block devices...For the unix target I think it is always straight forward to run with
--help
(please correct me if I am mistaken). For Xen (and Qubes) I suspect it is as well a bit cumbersome to run--help
.Footnotes
This is the case of the current release. In current main you may have to look at other files, too... ↩
The text was updated successfully, but these errors were encountered: