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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/mirageos-devel
