[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:


(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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.