Re: [MirageOS-devel] decision on oS module future (mirage/mirage-os-shim#7)

[Thomas Leonard <talex5@xxxxxxxxx>]

On Sun, 11 Aug 2019 at 17:17, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>
> Dear all,
>
> I'm back from holidays, and looking into completing the various outstanding 
> merges for the new cross compilation scheme using Dune workspaces.  One PR we 
> need to take a decision on is:
>
> https://github.com/mirage/mirage-os-shim/pull/7
>
> Hannes notes that a virtual module for `oS` is unsatisfactory from a 
> composition perspective and a possible vendor lockin.
>
> My thoughts are that the OS module needs to disappear entirely ahead of the 
> Mirage 4 release.  Its original purpose was to provide a set of core OS 
> functionality without making every application a functor, and predates 
> functoria and used the "linking hack".  I've recently merged a number of 
> other changes to use OS_<backend> alternatives for target-specific 
> functionality (e.g. OS_xen for mirage-block-xen).  Looking at the OS 
> signature, it is very small now:
>
>     module Lifecycle : sig
>       val await_shutdown_request :
>         ?can_poweroff:bool ->
>         ?can_reboot:bool ->
>         unit -> [`Poweroff | `Reboot] Lwt.t
>     end
>
>     module Main : sig
>       val run : unit Lwt.t -> unit
>       val at_enter : (unit -> unit Lwt.t) -> unit
>       val at_exit_iter  : (unit -> unit) -> unit
>       val at_enter_iter : (unit -> unit) -> unit
>     end
>
>     module Time : Mirage_time_lwt.S
>
> Is this really worth keeping this shim over?  We could simply expose a HOOKS 
> signature that could be specified as a functoria device, and OS.Time can be 
> lifted to a TIME device for `sleep_ns`.  I don't know of any users of 
> Lifecycle

The firewall uses it:

https://github.com/mirage/qubes-mirage-firewall/blob/65b79208a146bd30e2bf00ef9381d4337c37230b/unikernel.ml#L72

(it's also mentioned at https://mirage.io/blog/qubes-target)

It would probably be fine to turn it into a separate device, though.

> and think that can be deprecated and restored in a more general way as a 
> hotplug event stream device in the future (e.g. so it can get 
> backend-specific events from Xen or Solo5 as well as generic ones).
>
> Any objections to me taking a shot at removing the remainders of OS in my 
> trees and seeing what mirage-skeleton looks like?


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel