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

Slim register function arguments #1434

Merged
merged 1 commit into from Jun 23, 2023
Merged

Slim register function arguments #1434

merged 1 commit into from Jun 23, 2023

Conversation

hannesm
Copy link
Member

@hannesm hannesm commented Jun 20, 2023

To test with: mirage/mirage-skeleton#362

Once mirage 4.4.0 is merged into opam-repository, we'll be lucky and the CI may pass.

In the meantime, let me please know whether this is a bad idea or completely stupid. Thanks a lot.

@hannesm
Copy link
Member Author

hannesm commented Jun 21, 2023

turns out, there was some changes needed to mirage-skeleton, namely moving the ~packages to main/foreign (see mirage/mirage-skeleton#362) -- anyone against this?

@hannesm
Copy link
Member Author

hannesm commented Jun 23, 2023

/cc @samoht any opinion on this?

@samoht
Copy link
Member

samoht commented Jun 23, 2023

LGTM

@samoht samoht merged commit 8fbec84 into mirage:main Jun 23, 2023
3 checks passed
@hannesm hannesm deleted the slim-register branch June 23, 2023 10:13
samoht added a commit to samoht/opam-repository that referenced this pull request Apr 9, 2024
CHANGES:

- This release introduces a significant change in the Mirage tool by
  splitting the definition of command-line arguments used at
  configure-time and runtime. Command-line arguments used in the
  configure script (also called 'configuration keys' and defined in
  the `Key` module) are essential during the setup of module
  dependencies for the unikernel, allowing for a specialized
  production of a unikernel for a given target runtime environment. On
  the other hand, command-line arguments that the unikernel can use at
  runtime (defined in the `Runtime_arg` module) are useful for
  customizing deployments without altering the dependencies of the
  unikernels. (mirage/mirage#1449, mirage/mirage#1450, mirage/mirage#1451, mirage/mirage#1455 @samoht, review by @hannesm)

  * API changes:
    - There is no more `~stage` parameter for `Key.Arg.info`.
    - `Key` now define command-line arguments for the configuration tool.
    - There is a new module `Runtime_arg` to define command-line arguments
      for the unikernel.
    - As there are no more keys type `'Both`, users are now expected to create
      two separated keys in that case (one for configure-time, one for runtime)
      or decide if the key is useful at runtime of configure-time.

  * Intended use of configuration keys (values of type `'a key`):
    - Used to set up module dependencies of the unikernel, such as the
      target (hvt, xen, etc.) and whether to use DHCP or a fixed IP address.
    - Enable the production of specialized unikernels suitable for
      specific target runtime environments and dedicated network and
      storage stacks.
    - Similar keys will produce reproducible binaries to be uploaded to artifact
      repositories like Docker Hub or https://builds.robur.coop/.

  * Intended use of command-line runtime arguments (values of type
    `a runtime_arg`):
    - Allow users to customize deployments by changing device
      configuration, like IP addresses, secrets, block device names,
      etc., post downloading of binaries.
    - These keys don’t alter the dependencies of the unikernels.
    - A runtime keys is just a reference to a normal Cmdliner term.

  * `key_gen.ml` is not generated anymore, so users cannot refer to
    `Key_gen.<key_name>` directy.
    - Any runtime argument has to be declared (using `runtime_arg` and
      registered on the device (using `~runtime_args`). The value of that
      argument will then be passed  as an extra parameter of the `connect`
      function of that device.
    - Configuration keys are not available at runtime anymore. For
      instance, `Key_gen.target` has been removed.

* Code migration:
    ```ocaml
    (* in config.ml *)
    let key =
      let doc = Key.Arg.info ~doc:"A Key." ~stage:`Run [ "key" ] in
      Key.(create "key" Arg.(opt_all ~stage:`Run string doc))
    ```
    becomes:
    ```ocaml
    (* in unikernel.ml *)
    open Cmdliner

    let key =
      let doc = Arg.info ~doc:"A Key." [ "key" ] in
      Arg.(value & opt_all string [] doc)
    ```

    ```ocaml
    (* in unikernel.ml *)
    let start _ =
      let key = Key_gen.hello () in
      ...
    ```
    becomes:
    ```ocaml
    (* in config.ml *)
    let hello = runtime_arg ~pos:__POS__ "Unikernel.hello"
    let main = main ~runtime_args:[hello] ...
    ```

    ```
    (* in unikernel.ml *)
    let hello =
      let open Cmdliner in
      let doc = Arg.info ~doc:"How to say hello." [ "hello" ] in
      Arg.(value & opt string "Hello World!" doc)

    let start _ hello =
      ...
    ```

- bump minimal ocaml-solo5 version bound to 0.8.2 to avoid fast memory usage
  error (mirage/mirage#1507, @palainp)
- BREAKING: the packages `functoria` and `functoria-runtime` are removed. The
  respectives libraries became `mirage.functoria` and `mirage-runtime.functoria`
  (mirage/mirage#1509, @samoht)
- BREAKING: `Mirage.keys` is renamed to `Mirage.runtime_args` (mirage/mirage#1506, @samoht)
- BREAKING: remove `Mirage.foreign. Use `Mirage.main` instead (mirage/mirage#1505, @samoht)
- BREAKING: `Mirage.main` does not take a `?extra_deps` parameter anymore
  (mirage/mirage#1505, @samoht)
- BREAKING: the `Mirage.connect` functions passed to create devices
  (with `Mirage.impl`)  now take values of type `'a Mirage.code` instead
  of `string`. Value of type `code` are created using a new `Mirage.code`
  function, that takes `~pos:__POS__` as parameter. This is used to generate
  better locations in the generated code, leading to better error messages
  (mirage/mirage#1504, @samoht)
- BUGFIX: fix `mirage describe` output (mirage/mirage#1446 @samoht), add test (mirage/mirage#1458 @samoht)
- Remove ipaddr from runtime (mirage/mirage#1437 @samoht, mirage/mirage#1465 @hannesm)
- BREAKING: `Mirage.register` no longer have `?packages` and `?keys` arguments
  (mirage/mirage#1433, mirage/mirage#1434 @hannesm)
- BREAKING: Remove deprecated bindings and types (mirage/mirage#1461 @hannesm)
- BREAKING: Remove `mirage build` subcommand, use `dune build` in Makefile
  (mirage/mirage#1404 @hannesm), put `--profile release` in Makefile instead of
  dune-workspace (mirage/mirage#1470 @hannesm)
- Increase dune version to 2.9 in generated dune-project (mirage/mirage#1443 @samoht)
samoht added a commit to samoht/opam-repository that referenced this pull request Apr 10, 2024
CHANGES:

- This release introduces a significant change in the Mirage tool by
  splitting the definition of command-line arguments used at
  configure-time and runtime. Command-line arguments used in the
  configure script (also called 'configuration keys' and defined in
  the `Key` module) are essential during the setup of module
  dependencies for the unikernel, allowing for a specialized
  production of a unikernel for a given target runtime environment. On
  the other hand, command-line arguments that the unikernel can use at
  runtime (defined in the `Runtime_arg` module) are useful for
  customizing deployments without altering the dependencies of the
  unikernels. (mirage/mirage#1449, mirage/mirage#1450, mirage/mirage#1451, mirage/mirage#1455 @samoht, review by @hannesm)

  * API changes:
    - There is no more `~stage` parameter for `Key.Arg.info`.
    - `Key` now define command-line arguments for the configuration tool.
    - There is a new module `Runtime_arg` to define command-line arguments
      for the unikernel.
    - As there are no more keys type `'Both`, users are now expected to create
      two separated keys in that case (one for configure-time, one for runtime)
      or decide if the key is useful at runtime of configure-time.

  * Intended use of configuration keys (values of type `'a key`):
    - Used to set up module dependencies of the unikernel, such as the
      target (hvt, xen, etc.) and whether to use DHCP or a fixed IP address.
    - Enable the production of specialized unikernels suitable for
      specific target runtime environments and dedicated network and
      storage stacks.
    - Similar keys will produce reproducible binaries to be uploaded to artifact
      repositories like Docker Hub or https://builds.robur.coop/.

  * Intended use of command-line runtime arguments (values of type
    `a runtime_arg`):
    - Allow users to customize deployments by changing device
      configuration, like IP addresses, secrets, block device names,
      etc., post downloading of binaries.
    - These keys don’t alter the dependencies of the unikernels.
    - A runtime keys is just a reference to a normal Cmdliner term.

  * `key_gen.ml` is not generated anymore, so users cannot refer to
    `Key_gen.<key_name>` directy.
    - Any runtime argument has to be declared (using `runtime_arg` and
      registered on the device (using `~runtime_args`). The value of that
      argument will then be passed  as an extra parameter of the `connect`
      function of that device.
    - Configuration keys are not available at runtime anymore. For
      instance, `Key_gen.target` has been removed.

* Code migration:
    ```ocaml
    (* in config.ml *)
    let key =
      let doc = Key.Arg.info ~doc:"A Key." ~stage:`Run [ "key" ] in
      Key.(create "key" Arg.(opt_all ~stage:`Run string doc))
    ```
    becomes:
    ```ocaml
    (* in unikernel.ml *)
    open Cmdliner

    let key =
      let doc = Arg.info ~doc:"A Key." [ "key" ] in
      Arg.(value & opt_all string [] doc)
    ```

    ```ocaml
    (* in unikernel.ml *)
    let start _ =
      let key = Key_gen.hello () in
      ...
    ```
    becomes:
    ```ocaml
    (* in config.ml *)
    let hello = runtime_arg ~pos:__POS__ "Unikernel.hello"
    let main = main ~runtime_args:[hello] ...
    ```

    ```
    (* in unikernel.ml *)
    let hello =
      let open Cmdliner in
      let doc = Arg.info ~doc:"How to say hello." [ "hello" ] in
      Arg.(value & opt string "Hello World!" doc)

    let start _ hello =
      ...
    ```

- bump minimal ocaml-solo5 version bound to 0.8.2 to avoid fast memory usage
  error (mirage/mirage#1507, @palainp)
- BREAKING: the packages `functoria` and `functoria-runtime` are removed. The
  respectives libraries became `mirage.functoria` and `mirage-runtime.functoria`
  (mirage/mirage#1509, @samoht)
- BREAKING: `Mirage.keys` is renamed to `Mirage.runtime_args` (mirage/mirage#1506, @samoht)
- BREAKING: remove `Mirage.foreign. Use `Mirage.main` instead (mirage/mirage#1505, @samoht)
- BREAKING: `Mirage.main` does not take a `?extra_deps` parameter anymore
  (mirage/mirage#1505, @samoht)
- BREAKING: the `Mirage.connect` functions passed to create devices
  (with `Mirage.impl`)  now take values of type `'a Mirage.code` instead
  of `string`. Value of type `code` are created using a new `Mirage.code`
  function, that takes `~pos:__POS__` as parameter. This is used to generate
  better locations in the generated code, leading to better error messages
  (mirage/mirage#1504, @samoht)
- BUGFIX: fix `mirage describe` output (mirage/mirage#1446 @samoht), add test (mirage/mirage#1458 @samoht)
- Remove ipaddr from runtime (mirage/mirage#1437 @samoht, mirage/mirage#1465 @hannesm)
- BREAKING: `Mirage.register` no longer have `?packages` and `?keys` arguments
  (mirage/mirage#1433, mirage/mirage#1434 @hannesm)
- BREAKING: Remove deprecated bindings and types (mirage/mirage#1461 @hannesm)
- BREAKING: Remove `mirage build` subcommand, use `dune build` in Makefile
  (mirage/mirage#1404 @hannesm), put `--profile release` in Makefile instead of
  dune-workspace (mirage/mirage#1470 @hannesm)
- Increase dune version to 2.9 in generated dune-project (mirage/mirage#1443 @samoht)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants