[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: OS.*
On 16 Aug 2013, at 07:47, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote: > On 16/08/2013 12:42, Anil Madhavapeddy wrote: >> The OS module is best thought of as analogous to the Cohttp.IO >> functor. It's the minimal support needed for building portable >> applications that might run on several backends. >> >> In the longer-term, it makes complete sense to break up OS into a set >> of functors rather than the current pack hack, and to get Mirari to >> instantiate the application by applying the correct backend. >> >> However, the Xen-specific OS functions can and should be pulled out >> from OS, leaving only the portable aliases (e.g. OS.Time) that*use* >> the Xen functions but also have an implementation under UNIX. > > Unfortunately Xs can't be pulled out because only one instance of Xs can be > ever instanciated (We don't support connection multiplexing to the xenstore). We could modify OS to take a handle for all of its function calls. This would let us spin up multiple instances if appropriate for the backend. I can see this immediately being of use in the NS3 simulation backend, for instance. That would solve your problem with Xenstore as well, right? The OS handle could hold the multiplexing lock. -anil
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |