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

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Dear Anil,

thanks for bringing this issue to this list.

On 11/08/2019 18:15, Anil Madhavapeddy wrote:
> Hannes notes that a virtual module for `oS` is unsatisfactory from a 
> composition perspective and a possible vendor lockin.  
>   
> ...
>
> 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 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?

As mentioned in
https://github.com/mirage/mirage-os-shim/pull/7#issuecomment-501297905,
I'd be fine with removing the OS module and instead defining a
mirage-lifecycle and mirage-main interface (where lifecycle seems to be
rather xen-specific atm, maybe it should be part of the mirage on xen
interface (I guess currently ocamlfind "mirage-xen.internals"/module
OS_xen) until there's at least a second platform supporting this feature).

The questions (from
https://github.com/mirage/mirage-os-shim/pull/7#issuecomment-518234377)
are still open. Especially whether these are "temporary" -- and if so,
is there a roadmap for solving them:
- why can "virtual libraries" only be provided by a dune-project? (this
is the vendor lock-in I'm afraid of)
- "implementations can not introduce new modules" -- is this temporary?


Best,

hannes

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