From avsm@dark.recoil.org Mon Oct 17 12:45:32 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFldM-0004gt-P8 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 12:45:32 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:24147 helo=dark.recoil.org) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp (csa=unknown) id 1RFldM-0006GY-q2 (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 12:45:32 +0100 Received: (qmail 17782 invoked by uid 10000); 17 Oct 2011 11:45:31 -0000 Date: Mon, 17 Oct 2011 12:45:31 +0100 From: Anil Madhavapeddy To: cl-mirage@lists.cam.ac.uk Subject: Thoughts on cloud control APIs for Mirage Message-ID: <20111017114531.GA8005@dark.recoil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:45:32 -0000 X-Keywords: X-UID: 106 Status: O Content-Length: 4949 Lines: 97 Mirage now has a number of protocols implemented as libraries, as well as device drivers. What's missing is an effective control stack to glue all this together into a proper OS. So far, we are just wiring together applications manually from the libraries, which is fine for development but not for any real deployment. I've been re-reading the Plan 9 papers [1] for inspiration, and many of the ideas there are highly applicable to us. To realise the Mirage goal of synthesising microkernels that are 'minimal for purpose', we need to: - have multiple intercommunicating components, separated by process boundaries (on UNIX) or VM isolation (on Xen), or simply a function call compiled as part of the same kernel. - minimise information flow between components, so they can be dynamically split up ('self scaling') or combined more easily. - deal with the full lifecycle of all these VMs and processes, and not just spawning them. Plan 9 was built on very similar principles: instead of a big monolithic kernel, the system is built on many processes that communicate via a well-defined wire protocol (9P), and per-process namespaces and filesystem abstractions for almost every service. For example, instead of 'ifconfig', the network is simply exposed as a /net filesystem and configured through filesystem calls rather than an alternative command line. Crucially, the 9P protocol can be remotely called, or directly via a simple function call (for direct in-kernel operations). In contrast, modern cloud stacks are just terribly designed: they consist of a huge amount of static specification of VM and network state, with little attention paid to simple UNIX/Plan9 principles that can be used to build the more complicated abstractions. So, this leaves us with an interesting opportunity: to implement the Mirage control interface using similar principles: - a per-deployment global hierarchial tree (i.e. a filesystem), with ways to synchronise on entries (i.e. blocking I/O, or a select/poll equivalent). Our consistency model may vary somewhat, as we could be strongly consistent between VMs when running on the same physical host, and more loose cluster-wide. - every library exposes a set of keys and values, as well as a mechanism for session setup, authentication and teardown (the lifecycle of the process. Plan 9 used ASCII for everything, whereas Mirage would layer a well-typed API on top of it (e.g. just write a record to a file rather than manually serialising it). - extend the Xen Cloud Platform to support delegation, so that microVMs can be monitored or killed by supervisors. Unlike Plan9, this also includes operations across physical hosts (e.g. live relocation), or across cloud providers. There are some nice implications of this work that goes beyond Mirage: - it generally applies to all of the exokernel libraries out there, including HalVM (Haskell) or GuestVM (Java), as they all have this control problem that makes manpulating raw kernels such a pain to do. - it can easily be extended to support existing applications on a monolithic guest kernel, and in make it easier to manage them too. - application synthesis becomes much more viable: this approach could let me build a HTTP microkernel without a TCP stack, and simply receive a typed RPC from a HTTP proxy (which has done all the work of parsing the TCP and HTTP bits, so why repeat it?). If my HTTP server microkernel later live migrates away, then it could swap back to a network connection. Modern cloudy applications (especialy Hadoop or CIEL) use HTTP very heavily to talk between components, so optimising this part of the stack is worthwhile (numbers needed!) - Even if components are compiled up in the same binary and use function calls, they still have to establish and authenticate connections to each others. This makes monitoring and scaling hugely easier, since the control filesystem operations provide a natural logging and introspection point, even for large clusters. If we had a hardware-capability-aware CPU in the future, it could use this information too :-) I highly recommend that anyone interested in this area read the Plan 9 paper, as it's a really good read anyway [1]. Also the Scout OS and x-kernel stack are good. Our main difference from this work is the heavy emphasis on type-safe components, as well as realistic deployment due to the use of Xen cloud providers as a stable hardware interface. In the very short-term, Mort and I have an OpenFlow tutorial coming up in mid-November, so I'll lash up the network stack to have a manual version of this as soon as possible, so that you can configure all the tap interfaces and such much more quickly. Meanwhile, all and any thoughts are most welcome! [1] Plan 9 papers: http://cm.bell-labs.com/sys/doc/ -- Anil Madhavapeddy http://anil.recoil.org From thomas.gazagnaire@gmail.com Mon Oct 17 12:57:23 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFlop-0005EJ-RJ (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 12:57:23 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -2.7 from SpamAssassin-3.3.2-1162027 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [74.125.82.51 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (thomas.gazagnaire[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail-ww0-f51.google.com ([74.125.82.51]:47423) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp (csa=unknown) id 1RFloo-000832-sf (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 12:57:23 +0100 Received: by wwe32 with SMTP id 32so1613091wwe.20 for ; Mon, 17 Oct 2011 04:57:22 -0700 (PDT) Received: by 10.216.138.11 with SMTP id z11mr3768961wei.38.1318852642074; Mon, 17 Oct 2011 04:57:22 -0700 (PDT) Received: from [192.168.0.13] (gou06-3-88-170-165-56.fbx.proxad.net. [88.170.165.56]) by mx.google.com with ESMTPS id fo7sm30639274wbb.20.2011.10.17.04.57.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 04:57:21 -0700 (PDT) Subject: Re: Thoughts on cloud control APIs for Mirage Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Gazagnaire In-Reply-To: <20111017114531.GA8005@dark.recoil.org> Date: Mon, 17 Oct 2011 13:57:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> References: <20111017114531.GA8005@dark.recoil.org> To: Anil Madhavapeddy X-Mailer: Apple Mail (2.1084) Cc: cl-mirage@lists.cam.ac.uk X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:57:23 -0000 X-Keywords: X-UID: 107 Status: O Content-Length: 5261 Lines: 108 Basically you say we need Xenstore :-) putting the plan9 paper on my to-read list. -- Thomas On Oct 17, 2011, at 1:45 PM, Anil Madhavapeddy wrote: > Mirage now has a number of protocols implemented as libraries, as > well as device drivers. What's missing is an effective control stack to > glue all this together into a proper OS. So far, we are just wiring > together applications manually from the libraries, which is fine for > development but not for any real deployment. > > I've been re-reading the Plan 9 papers [1] for inspiration, and many of > the ideas there are highly applicable to us. To realise the Mirage goal of > synthesising microkernels that are 'minimal for purpose', we need to: > > - have multiple intercommunicating components, separated by process > boundaries (on UNIX) or VM isolation (on Xen), or simply a function > call compiled as part of the same kernel. > > - minimise information flow between components, so they can be > dynamically split up ('self scaling') or combined more easily. > > - deal with the full lifecycle of all these VMs and processes, and not > just spawning them. > > Plan 9 was built on very similar principles: instead of a big monolithic > kernel, the system is built on many processes that communicate via a > well-defined wire protocol (9P), and per-process namespaces and filesystem > abstractions for almost every service. For example, instead of 'ifconfig', > the network is simply exposed as a /net filesystem and configured through > filesystem calls rather than an alternative command line. Crucially, the > 9P protocol can be remotely called, or directly via a simple function call > (for direct in-kernel operations). > > In contrast, modern cloud stacks are just terribly designed: they consist > of a huge amount of static specification of VM and network state, with > little attention paid to simple UNIX/Plan9 principles that can be used to > build the more complicated abstractions. > > So, this leaves us with an interesting opportunity: to implement the > Mirage control interface using similar principles: > > - a per-deployment global hierarchial tree (i.e. a filesystem), with ways > to synchronise on entries (i.e. blocking I/O, or a select/poll > equivalent). Our consistency model may vary somewhat, as we could be > strongly consistent between VMs when running on the same physical host, > and more loose cluster-wide. > > - every library exposes a set of keys and values, as well as a mechanism > for session setup, authentication and teardown (the lifecycle of the > process. Plan 9 used ASCII for everything, whereas Mirage would layer > a well-typed API on top of it (e.g. just write a record to a file rather > than manually serialising it). > > - extend the Xen Cloud Platform to support delegation, so that microVMs > can be monitored or killed by supervisors. Unlike Plan9, this also > includes operations across physical hosts (e.g. live relocation), or > across cloud providers. > > There are some nice implications of this work that goes beyond Mirage: > > - it generally applies to all of the exokernel libraries out there, > including HalVM (Haskell) or GuestVM (Java), as they all have this > control problem that makes manpulating raw kernels such a pain to do. > > - it can easily be extended to support existing applications on a > monolithic guest kernel, and in make it easier to manage them too. > > - application synthesis becomes much more viable: this approach could let > me build a HTTP microkernel without a TCP stack, and simply receive a > typed RPC from a HTTP proxy (which has done all the work of parsing the > TCP and HTTP bits, so why repeat it?). If my HTTP server microkernel > later live migrates away, then it could swap back to a network connection. > > Modern cloudy applications (especialy Hadoop or CIEL) use HTTP very > heavily to talk between components, so optimising this part of the stack > is worthwhile (numbers needed!) > > - Even if components are compiled up in the same binary and use function > calls, they still have to establish and authenticate connections to each > others. This makes monitoring and scaling hugely easier, since the > control filesystem operations provide a natural logging and introspection > point, even for large clusters. If we had a hardware-capability-aware > CPU in the future, it could use this information too :-) > > I highly recommend that anyone interested in this area read the Plan 9 > paper, as it's a really good read anyway [1]. Also the Scout OS and > x-kernel stack are good. Our main difference from this work is the > heavy emphasis on type-safe components, as well as realistic deployment > due to the use of Xen cloud providers as a stable hardware interface. > > In the very short-term, Mort and I have an OpenFlow tutorial coming up in > mid-November, so I'll lash up the network stack to have a manual version > of this as soon as possible, so that you can configure all the tap > interfaces and such much more quickly. Meanwhile, all and any thoughts > are most welcome! > > [1] Plan 9 papers: http://cm.bell-labs.com/sys/doc/ > > -- > Anil Madhavapeddy http://anil.recoil.org > From anil@recoil.org Mon Oct 17 13:04:01 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFlvF-0005XF-PD (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 13:04:01 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:41495 helo=dark.recoil.org) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp (csa=unknown) id 1RFlvE-0003J5-re (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 13:04:01 +0100 Received: (qmail 23269 invoked by uid 634); 17 Oct 2011 12:04:00 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.4 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from Unknown (HELO [172.17.29.71]) (12.238.56.2) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.83) with ESMTPA; Mon, 17 Oct 2011 13:03:59 +0100 Subject: Re: Thoughts on cloud control APIs for Mirage Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Anil Madhavapeddy In-Reply-To: <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> Date: Mon, 17 Oct 2011 08:03:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <921B1832-6164-4929-B8D8-596B3E502021@recoil.org> References: <20111017114531.GA8005@dark.recoil.org> <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: cl-mirage@lists.cam.ac.uk X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 12:04:01 -0000 X-Keywords: X-UID: 108 Status: O Content-Length: 6515 Lines: 166 Right... Xenstore is 'almost there' but not quite. For example, it has = transactions and a globally shared namespace, whereas the Plan 9 model = is to give processes their own namespace and mount other services into = that. So if you have an HTTP server domain, it might export a = /http/server/recoil.org directory, and clients wanting to read a URL can = import that filesystem somewhere into their system and read files under = it. A HTTP proxy could then serialise that file into actual HTTP and = write it to a /net/tcp/555/data to respond to an external request. This = could all happen within the same kernel, or across multiple domains. Xenstore will always require a globally privileged Xenstored to manage = the namespace, whereas the Plan 9 model is far better suited to multiple = intercommunicating processes (or stub domains). I'm just thinking = through the implications on consistency models across a cluster of = physical hosts at the moment though... Anil On 17 Oct 2011, at 07:57, Thomas Gazagnaire wrote: > Basically you say we need Xenstore :-) >=20 > putting the plan9 paper on my to-read list. >=20 > -- > Thomas >=20 > On Oct 17, 2011, at 1:45 PM, Anil Madhavapeddy wrote: >=20 >> Mirage now has a number of protocols implemented as libraries, as >> well as device drivers. What's missing is an effective control stack = to >> glue all this together into a proper OS. So far, we are just wiring >> together applications manually from the libraries, which is fine for >> development but not for any real deployment. >>=20 >> I've been re-reading the Plan 9 papers [1] for inspiration, and many = of >> the ideas there are highly applicable to us. To realise the Mirage = goal of >> synthesising microkernels that are 'minimal for purpose', we need to: >>=20 >> - have multiple intercommunicating components, separated by process >> boundaries (on UNIX) or VM isolation (on Xen), or simply a function >> call compiled as part of the same kernel. >>=20 >> - minimise information flow between components, so they can be >> dynamically split up ('self scaling') or combined more easily. >>=20 >> - deal with the full lifecycle of all these VMs and processes, and = not=20 >> just spawning them. >>=20 >> Plan 9 was built on very similar principles: instead of a big = monolithic >> kernel, the system is built on many processes that communicate via a >> well-defined wire protocol (9P), and per-process namespaces and = filesystem >> abstractions for almost every service. For example, instead of = 'ifconfig', >> the network is simply exposed as a /net filesystem and configured = through >> filesystem calls rather than an alternative command line. Crucially, = the >> 9P protocol can be remotely called, or directly via a simple function = call >> (for direct in-kernel operations). >>=20 >> In contrast, modern cloud stacks are just terribly designed: they = consist >> of a huge amount of static specification of VM and network state, = with >> little attention paid to simple UNIX/Plan9 principles that can be = used to >> build the more complicated abstractions. >>=20 >> So, this leaves us with an interesting opportunity: to implement the >> Mirage control interface using similar principles: >>=20 >> - a per-deployment global hierarchial tree (i.e. a filesystem), with = ways >> to synchronise on entries (i.e. blocking I/O, or a select/poll >> equivalent). Our consistency model may vary somewhat, as we could be >> strongly consistent between VMs when running on the same physical = host, >> and more loose cluster-wide. >>=20 >> - every library exposes a set of keys and values, as well as a = mechanism >> for session setup, authentication and teardown (the lifecycle of the >> process. Plan 9 used ASCII for everything, whereas Mirage would layer >> a well-typed API on top of it (e.g. just write a record to a file = rather >> than manually serialising it). >>=20 >> - extend the Xen Cloud Platform to support delegation, so that = microVMs >> can be monitored or killed by supervisors. Unlike Plan9, this also >> includes operations across physical hosts (e.g. live relocation), or >> across cloud providers. >>=20 >> There are some nice implications of this work that goes beyond = Mirage: >>=20 >> - it generally applies to all of the exokernel libraries out there, >> including HalVM (Haskell) or GuestVM (Java), as they all have this >> control problem that makes manpulating raw kernels such a pain to do. >>=20 >> - it can easily be extended to support existing applications on a >> monolithic guest kernel, and in make it easier to manage them too. >>=20 >> - application synthesis becomes much more viable: this approach could = let >> me build a HTTP microkernel without a TCP stack, and simply receive a >> typed RPC from a HTTP proxy (which has done all the work of parsing = the >> TCP and HTTP bits, so why repeat it?). If my HTTP server microkernel >> later live migrates away, then it could swap back to a network = connection. >>=20 >> Modern cloudy applications (especialy Hadoop or CIEL) use HTTP very >> heavily to talk between components, so optimising this part of the = stack >> is worthwhile (numbers needed!) >>=20 >> - Even if components are compiled up in the same binary and use = function >> calls, they still have to establish and authenticate connections to = each >> others. This makes monitoring and scaling hugely easier, since the=20= >> control filesystem operations provide a natural logging and = introspection >> point, even for large clusters. If we had a = hardware-capability-aware >> CPU in the future, it could use this information too :-) >>=20 >> I highly recommend that anyone interested in this area read the Plan = 9 >> paper, as it's a really good read anyway [1]. Also the Scout OS and >> x-kernel stack are good. Our main difference from this work is the >> heavy emphasis on type-safe components, as well as realistic = deployment >> due to the use of Xen cloud providers as a stable hardware interface. >>=20 >> In the very short-term, Mort and I have an OpenFlow tutorial coming = up in >> mid-November, so I'll lash up the network stack to have a manual = version >> of this as soon as possible, so that you can configure all the tap >> interfaces and such much more quickly. Meanwhile, all and any = thoughts >> are most welcome! >>=20 >> [1] Plan 9 papers: http://cm.bell-labs.com/sys/doc/ >>=20 >> --=20 >> Anil Madhavapeddy = http://anil.recoil.org >>=20 >=20 >=20 From smh22@cl.cam.ac.uk Mon Oct 17 13:41:57 2011 Received: from ppsw-41.csi.cam.ac.uk ([131.111.8.141]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFmVx-0007Kv-Le (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 13:41:57 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -3.4 from SpamAssassin-3.3.2-1162027 * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay * domain * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mta1.cl.cam.ac.uk ([128.232.25.21]:50064) by ppsw-41.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp id 1RFmVt-0000ac-QQ (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 13:41:57 +0100 Received: from paddington.ad.cl.cam.ac.uk ([128.232.13.42]) by mta1.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1RFmVs-0002M9-CR; Mon, 17 Oct 2011 13:41:52 +0100 Received: from paddington.ad.cl.cam.ac.uk ([fe80::69c6:4d69:c57c:7b59]) by paddington.ad.cl.cam.ac.uk ([fe80::69c6:4d69:c57c:7b59%13]) with mapi; Mon, 17 Oct 2011 13:41:49 +0100 From: Steven Hand To: Anil Madhavapeddy , Thomas Gazagnaire Date: Mon, 17 Oct 2011 13:41:49 +0100 Subject: RE: Thoughts on cloud control APIs for Mirage Thread-Topic: Thoughts on cloud control APIs for Mirage Thread-Index: AcyMxN3AtSyTOI6WR825OKKq5GEW+AABRmAg Message-ID: <7749CD9FB4CE5940A68F1DF96D34A66401FF4514A3CA@paddington.ad.cl.cam.ac.uk> References: <20111017114531.GA8005@dark.recoil.org> <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> <921B1832-6164-4929-B8D8-596B3E502021@recoil.org> In-Reply-To: <921B1832-6164-4929-B8D8-596B3E502021@recoil.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cl-mirage@lists.cam.ac.uk" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 12:41:57 -0000 X-Keywords: X-UID: 109 Status: O Content-Length: 7137 Lines: 169 Funnily enough, the *original* model for XenStore was distributed, and was = inspired by Plan 9 name spaces.=20 Nowadays I'd recommend looking into Zookeeper for a more interesting kind o= f coordination space... Cheers, S. =20 -----Original Message----- From: cl-mirage-bounces@lists.cam.ac.uk [mailto:cl-mirage-bounces@lists.cam= .ac.uk] On Behalf Of Anil Madhavapeddy Sent: Monday, October 17, 2011 1:04 PM To: Thomas Gazagnaire Cc: cl-mirage@lists.cam.ac.uk Subject: Re: Thoughts on cloud control APIs for Mirage Right... Xenstore is 'almost there' but not quite. For example, it has tra= nsactions and a globally shared namespace, whereas the Plan 9 model is to g= ive processes their own namespace and mount other services into that. So if you have an HTTP server domain, it might export a /http/server/recoil= .org directory, and clients wanting to read a URL can import that filesyste= m somewhere into their system and read files under it. A HTTP proxy could = then serialise that file into actual HTTP and write it to a /net/tcp/555/da= ta to respond to an external request. This could all happen within the sam= e kernel, or across multiple domains. Xenstore will always require a globally privileged Xenstored to manage the = namespace, whereas the Plan 9 model is far better suited to multiple interc= ommunicating processes (or stub domains). I'm just thinking through the im= plications on consistency models across a cluster of physical hosts at the = moment though... Anil On 17 Oct 2011, at 07:57, Thomas Gazagnaire wrote: > Basically you say we need Xenstore :-) >=20 > putting the plan9 paper on my to-read list. >=20 > -- > Thomas >=20 > On Oct 17, 2011, at 1:45 PM, Anil Madhavapeddy wrote: >=20 >> Mirage now has a number of protocols implemented as libraries, as >> well as device drivers. What's missing is an effective control stack to >> glue all this together into a proper OS. So far, we are just wiring >> together applications manually from the libraries, which is fine for >> development but not for any real deployment. >>=20 >> I've been re-reading the Plan 9 papers [1] for inspiration, and many of >> the ideas there are highly applicable to us. To realise the Mirage goal = of >> synthesising microkernels that are 'minimal for purpose', we need to: >>=20 >> - have multiple intercommunicating components, separated by process >> boundaries (on UNIX) or VM isolation (on Xen), or simply a function >> call compiled as part of the same kernel. >>=20 >> - minimise information flow between components, so they can be >> dynamically split up ('self scaling') or combined more easily. >>=20 >> - deal with the full lifecycle of all these VMs and processes, and not=20 >> just spawning them. >>=20 >> Plan 9 was built on very similar principles: instead of a big monolithic >> kernel, the system is built on many processes that communicate via a >> well-defined wire protocol (9P), and per-process namespaces and filesyst= em >> abstractions for almost every service. For example, instead of 'ifconfi= g', >> the network is simply exposed as a /net filesystem and configured throug= h >> filesystem calls rather than an alternative command line. Crucially, th= e >> 9P protocol can be remotely called, or directly via a simple function ca= ll >> (for direct in-kernel operations). >>=20 >> In contrast, modern cloud stacks are just terribly designed: they consis= t >> of a huge amount of static specification of VM and network state, with >> little attention paid to simple UNIX/Plan9 principles that can be used t= o >> build the more complicated abstractions. >>=20 >> So, this leaves us with an interesting opportunity: to implement the >> Mirage control interface using similar principles: >>=20 >> - a per-deployment global hierarchial tree (i.e. a filesystem), with way= s >> to synchronise on entries (i.e. blocking I/O, or a select/poll >> equivalent). Our consistency model may vary somewhat, as we could be >> strongly consistent between VMs when running on the same physical host, >> and more loose cluster-wide. >>=20 >> - every library exposes a set of keys and values, as well as a mechanism >> for session setup, authentication and teardown (the lifecycle of the >> process. Plan 9 used ASCII for everything, whereas Mirage would layer >> a well-typed API on top of it (e.g. just write a record to a file rather >> than manually serialising it). >>=20 >> - extend the Xen Cloud Platform to support delegation, so that microVMs >> can be monitored or killed by supervisors. Unlike Plan9, this also >> includes operations across physical hosts (e.g. live relocation), or >> across cloud providers. >>=20 >> There are some nice implications of this work that goes beyond Mirage: >>=20 >> - it generally applies to all of the exokernel libraries out there, >> including HalVM (Haskell) or GuestVM (Java), as they all have this >> control problem that makes manpulating raw kernels such a pain to do. >>=20 >> - it can easily be extended to support existing applications on a >> monolithic guest kernel, and in make it easier to manage them too. >>=20 >> - application synthesis becomes much more viable: this approach could le= t >> me build a HTTP microkernel without a TCP stack, and simply receive a >> typed RPC from a HTTP proxy (which has done all the work of parsing the >> TCP and HTTP bits, so why repeat it?). If my HTTP server microkernel >> later live migrates away, then it could swap back to a network connectio= n. >>=20 >> Modern cloudy applications (especialy Hadoop or CIEL) use HTTP very >> heavily to talk between components, so optimising this part of the stack >> is worthwhile (numbers needed!) >>=20 >> - Even if components are compiled up in the same binary and use function >> calls, they still have to establish and authenticate connections to each >> others. This makes monitoring and scaling hugely easier, since the=20 >> control filesystem operations provide a natural logging and introspectio= n >> point, even for large clusters. If we had a hardware-capability-aware >> CPU in the future, it could use this information too :-) >>=20 >> I highly recommend that anyone interested in this area read the Plan 9 >> paper, as it's a really good read anyway [1]. Also the Scout OS and >> x-kernel stack are good. Our main difference from this work is the >> heavy emphasis on type-safe components, as well as realistic deployment >> due to the use of Xen cloud providers as a stable hardware interface. >>=20 >> In the very short-term, Mort and I have an OpenFlow tutorial coming up i= n >> mid-November, so I'll lash up the network stack to have a manual version >> of this as soon as possible, so that you can configure all the tap >> interfaces and such much more quickly. Meanwhile, all and any thoughts >> are most welcome! >>=20 >> [1] Plan 9 papers: http://cm.bell-labs.com/sys/doc/ >>=20 >> --=20 >> Anil Madhavapeddy http://anil.recoil.org >>=20 >=20 >=20 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1831 / Virus Database: 2090/4557 - Release Date: 10/17/11 From anil@recoil.org Mon Oct 17 14:03:41 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFmqz-0000fP-2X (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 14:03:41 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:44283 helo=dark.recoil.org) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp (csa=unknown) id 1RFmqu-0000Xq-sg (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 14:03:40 +0100 Received: (qmail 18777 invoked by uid 634); 17 Oct 2011 13:03:36 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.4 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from Unknown (HELO [172.17.29.71]) (12.238.56.2) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.83) with ESMTPA; Mon, 17 Oct 2011 14:03:36 +0100 Subject: Re: Thoughts on cloud control APIs for Mirage Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Anil Madhavapeddy In-Reply-To: <7749CD9FB4CE5940A68F1DF96D34A66401FF4514A3CA@paddington.ad.cl.cam.ac.uk> Date: Mon, 17 Oct 2011 09:03:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111017114531.GA8005@dark.recoil.org> <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> <921B1832-6164-4929-B8D8-596B3E502021@recoil.org> <7749CD9FB4CE5940A68F1DF96D34A66401FF4514A3CA@paddington.ad.cl.cam.ac.uk> To: Steven Hand X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: "cl-mirage@lists.cam.ac.uk" , Thomas Gazagnaire X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:03:41 -0000 X-Keywords: X-UID: 110 Status: O Content-Length: 8044 Lines: 219 I've got the 'Life and times of a Zookeeper' paper on my iPad for = reading next, in fact! :-) In Plan 9, the data for streams were also handled through files as well = as the coordination and control, whereas Zookeeper is very much a = centralised name service that runs distributed. I wonder if there may be a useful middle ground between the name service = (distributed with a central controller and leadership) and the local = filesystem views themselves (which seem more convenient for a library to = manipulate, and could be hardwired easily if the system is not = distributed). -anil On 17 Oct 2011, at 08:41, Steven Hand wrote: > Funnily enough, the *original* model for XenStore was distributed, and = was inspired by Plan 9 name spaces.=20 >=20 > Nowadays I'd recommend looking into Zookeeper for a more interesting = kind of coordination space... >=20 > Cheers, >=20 > S. >=20 >=20 > -----Original Message----- > From: cl-mirage-bounces@lists.cam.ac.uk = [mailto:cl-mirage-bounces@lists.cam.ac.uk] On Behalf Of Anil = Madhavapeddy > Sent: Monday, October 17, 2011 1:04 PM > To: Thomas Gazagnaire > Cc: cl-mirage@lists.cam.ac.uk > Subject: Re: Thoughts on cloud control APIs for Mirage >=20 > Right... Xenstore is 'almost there' but not quite. For example, it = has transactions and a globally shared namespace, whereas the Plan 9 = model is to give processes their own namespace and mount other services = into that. >=20 > So if you have an HTTP server domain, it might export a = /http/server/recoil.org directory, and clients wanting to read a URL can = import that filesystem somewhere into their system and read files under = it. A HTTP proxy could then serialise that file into actual HTTP and = write it to a /net/tcp/555/data to respond to an external request. This = could all happen within the same kernel, or across multiple domains. >=20 > Xenstore will always require a globally privileged Xenstored to manage = the namespace, whereas the Plan 9 model is far better suited to multiple = intercommunicating processes (or stub domains). I'm just thinking = through the implications on consistency models across a cluster of = physical hosts at the moment though... >=20 > Anil >=20 > On 17 Oct 2011, at 07:57, Thomas Gazagnaire wrote: >=20 >> Basically you say we need Xenstore :-) >>=20 >> putting the plan9 paper on my to-read list. >>=20 >> -- >> Thomas >>=20 >> On Oct 17, 2011, at 1:45 PM, Anil Madhavapeddy wrote: >>=20 >>> Mirage now has a number of protocols implemented as libraries, as >>> well as device drivers. What's missing is an effective control stack = to >>> glue all this together into a proper OS. So far, we are just wiring >>> together applications manually from the libraries, which is fine for >>> development but not for any real deployment. >>>=20 >>> I've been re-reading the Plan 9 papers [1] for inspiration, and many = of >>> the ideas there are highly applicable to us. To realise the Mirage = goal of >>> synthesising microkernels that are 'minimal for purpose', we need = to: >>>=20 >>> - have multiple intercommunicating components, separated by process >>> boundaries (on UNIX) or VM isolation (on Xen), or simply a function >>> call compiled as part of the same kernel. >>>=20 >>> - minimise information flow between components, so they can be >>> dynamically split up ('self scaling') or combined more easily. >>>=20 >>> - deal with the full lifecycle of all these VMs and processes, and = not=20 >>> just spawning them. >>>=20 >>> Plan 9 was built on very similar principles: instead of a big = monolithic >>> kernel, the system is built on many processes that communicate via a >>> well-defined wire protocol (9P), and per-process namespaces and = filesystem >>> abstractions for almost every service. For example, instead of = 'ifconfig', >>> the network is simply exposed as a /net filesystem and configured = through >>> filesystem calls rather than an alternative command line. = Crucially, the >>> 9P protocol can be remotely called, or directly via a simple = function call >>> (for direct in-kernel operations). >>>=20 >>> In contrast, modern cloud stacks are just terribly designed: they = consist >>> of a huge amount of static specification of VM and network state, = with >>> little attention paid to simple UNIX/Plan9 principles that can be = used to >>> build the more complicated abstractions. >>>=20 >>> So, this leaves us with an interesting opportunity: to implement the >>> Mirage control interface using similar principles: >>>=20 >>> - a per-deployment global hierarchial tree (i.e. a filesystem), with = ways >>> to synchronise on entries (i.e. blocking I/O, or a select/poll >>> equivalent). Our consistency model may vary somewhat, as we could = be >>> strongly consistent between VMs when running on the same physical = host, >>> and more loose cluster-wide. >>>=20 >>> - every library exposes a set of keys and values, as well as a = mechanism >>> for session setup, authentication and teardown (the lifecycle of the >>> process. Plan 9 used ASCII for everything, whereas Mirage would = layer >>> a well-typed API on top of it (e.g. just write a record to a file = rather >>> than manually serialising it). >>>=20 >>> - extend the Xen Cloud Platform to support delegation, so that = microVMs >>> can be monitored or killed by supervisors. Unlike Plan9, this also >>> includes operations across physical hosts (e.g. live relocation), or >>> across cloud providers. >>>=20 >>> There are some nice implications of this work that goes beyond = Mirage: >>>=20 >>> - it generally applies to all of the exokernel libraries out there, >>> including HalVM (Haskell) or GuestVM (Java), as they all have this >>> control problem that makes manpulating raw kernels such a pain to = do. >>>=20 >>> - it can easily be extended to support existing applications on a >>> monolithic guest kernel, and in make it easier to manage them too. >>>=20 >>> - application synthesis becomes much more viable: this approach = could let >>> me build a HTTP microkernel without a TCP stack, and simply receive = a >>> typed RPC from a HTTP proxy (which has done all the work of parsing = the >>> TCP and HTTP bits, so why repeat it?). If my HTTP server = microkernel >>> later live migrates away, then it could swap back to a network = connection. >>>=20 >>> Modern cloudy applications (especialy Hadoop or CIEL) use HTTP very >>> heavily to talk between components, so optimising this part of the = stack >>> is worthwhile (numbers needed!) >>>=20 >>> - Even if components are compiled up in the same binary and use = function >>> calls, they still have to establish and authenticate connections to = each >>> others. This makes monitoring and scaling hugely easier, since the=20= >>> control filesystem operations provide a natural logging and = introspection >>> point, even for large clusters. If we had a = hardware-capability-aware >>> CPU in the future, it could use this information too :-) >>>=20 >>> I highly recommend that anyone interested in this area read the Plan = 9 >>> paper, as it's a really good read anyway [1]. Also the Scout OS and >>> x-kernel stack are good. Our main difference from this work is the >>> heavy emphasis on type-safe components, as well as realistic = deployment >>> due to the use of Xen cloud providers as a stable hardware = interface. >>>=20 >>> In the very short-term, Mort and I have an OpenFlow tutorial coming = up in >>> mid-November, so I'll lash up the network stack to have a manual = version >>> of this as soon as possible, so that you can configure all the tap >>> interfaces and such much more quickly. Meanwhile, all and any = thoughts >>> are most welcome! >>>=20 >>> [1] Plan 9 papers: http://cm.bell-labs.com/sys/doc/ >>>=20 >>> --=20 >>> Anil Madhavapeddy = http://anil.recoil.org >>>=20 >>=20 >>=20 >=20 >=20 >=20 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1831 / Virus Database: 2090/4557 - Release Date: = 10/17/11 >=20 From robert.watson@cl.cam.ac.uk Mon Oct 17 14:05:36 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFmsq-0000iz-8c (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 14:05:36 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cyrus.watson.org ([65.122.17.42]:64379) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp (csa=unknown) id 1RFmso-0002kE-sZ (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 14:05:36 +0100 Received: from c0138.aw.cl.cam.ac.uk (c0138.aw.cl.cam.ac.uk [128.232.100.138]) by cyrus.watson.org (Postfix) with ESMTPSA id 2B6AB46B1A; Mon, 17 Oct 2011 09:05:33 -0400 (EDT) Subject: Re: Thoughts on cloud control APIs for Mirage Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <7749CD9FB4CE5940A68F1DF96D34A66401FF4514A3CA@paddington.ad.cl.cam.ac.uk> Date: Mon, 17 Oct 2011 14:05:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50EC78B7-F739-410D-9776-C5DA24C77C7C@cl.cam.ac.uk> References: <20111017114531.GA8005@dark.recoil.org> <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> <921B1832-6164-4929-B8D8-596B3E502021@recoil.org> <7749CD9FB4CE5940A68F1DF96D34A66401FF4514A3CA@paddington.ad.cl.cam.ac.uk> To: Steven Hand X-Mailer: Apple Mail (2.1084) Cc: Thomas Gazagnaire , "cl-mirage@lists.cam.ac.uk" , Anil Madhavapeddy X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:05:36 -0000 X-Keywords: X-UID: 111 Status: O Content-Length: 7935 Lines: 216 On 17 Oct 2011, at 13:41, Steven Hand wrote: > Funnily enough, the *original* model for XenStore was distributed, and = was inspired by Plan 9 name spaces.=20 >=20 > Nowadays I'd recommend looking into Zookeeper for a more interesting = kind of coordination space... Remind me a lot of Mach namespaces, needless to say! Some of my = favourite NeXTStep/Mac OS X vulnerabilities come from a composition of = the UNIX security model (grounded in the reliability of global = namespaces) and Mach-based services such as NetInfo (now = DirectoryServices). On the UNIX side, su(1) depends on safe access to = the password file, but on the Mach side, the password file access = service is via per-process Mach namespaces, which can be interposed on. Robert >=20 > Cheers, >=20 > S. >=20 >=20 > -----Original Message----- > From: cl-mirage-bounces@lists.cam.ac.uk = [mailto:cl-mirage-bounces@lists.cam.ac.uk] On Behalf Of Anil = Madhavapeddy > Sent: Monday, October 17, 2011 1:04 PM > To: Thomas Gazagnaire > Cc: cl-mirage@lists.cam.ac.uk > Subject: Re: Thoughts on cloud control APIs for Mirage >=20 > Right... Xenstore is 'almost there' but not quite. For example, it = has transactions and a globally shared namespace, whereas the Plan 9 = model is to give processes their own namespace and mount other services = into that. >=20 > So if you have an HTTP server domain, it might export a = /http/server/recoil.org directory, and clients wanting to read a URL can = import that filesystem somewhere into their system and read files under = it. A HTTP proxy could then serialise that file into actual HTTP and = write it to a /net/tcp/555/data to respond to an external request. This = could all happen within the same kernel, or across multiple domains. >=20 > Xenstore will always require a globally privileged Xenstored to manage = the namespace, whereas the Plan 9 model is far better suited to multiple = intercommunicating processes (or stub domains). I'm just thinking = through the implications on consistency models across a cluster of = physical hosts at the moment though... >=20 > Anil >=20 > On 17 Oct 2011, at 07:57, Thomas Gazagnaire wrote: >=20 >> Basically you say we need Xenstore :-) >>=20 >> putting the plan9 paper on my to-read list. >>=20 >> -- >> Thomas >>=20 >> On Oct 17, 2011, at 1:45 PM, Anil Madhavapeddy wrote: >>=20 >>> Mirage now has a number of protocols implemented as libraries, as >>> well as device drivers. What's missing is an effective control stack = to >>> glue all this together into a proper OS. So far, we are just wiring >>> together applications manually from the libraries, which is fine for >>> development but not for any real deployment. >>>=20 >>> I've been re-reading the Plan 9 papers [1] for inspiration, and many = of >>> the ideas there are highly applicable to us. To realise the Mirage = goal of >>> synthesising microkernels that are 'minimal for purpose', we need = to: >>>=20 >>> - have multiple intercommunicating components, separated by process >>> boundaries (on UNIX) or VM isolation (on Xen), or simply a function >>> call compiled as part of the same kernel. >>>=20 >>> - minimise information flow between components, so they can be >>> dynamically split up ('self scaling') or combined more easily. >>>=20 >>> - deal with the full lifecycle of all these VMs and processes, and = not=20 >>> just spawning them. >>>=20 >>> Plan 9 was built on very similar principles: instead of a big = monolithic >>> kernel, the system is built on many processes that communicate via a >>> well-defined wire protocol (9P), and per-process namespaces and = filesystem >>> abstractions for almost every service. For example, instead of = 'ifconfig', >>> the network is simply exposed as a /net filesystem and configured = through >>> filesystem calls rather than an alternative command line. = Crucially, the >>> 9P protocol can be remotely called, or directly via a simple = function call >>> (for direct in-kernel operations). >>>=20 >>> In contrast, modern cloud stacks are just terribly designed: they = consist >>> of a huge amount of static specification of VM and network state, = with >>> little attention paid to simple UNIX/Plan9 principles that can be = used to >>> build the more complicated abstractions. >>>=20 >>> So, this leaves us with an interesting opportunity: to implement the >>> Mirage control interface using similar principles: >>>=20 >>> - a per-deployment global hierarchial tree (i.e. a filesystem), with = ways >>> to synchronise on entries (i.e. blocking I/O, or a select/poll >>> equivalent). Our consistency model may vary somewhat, as we could = be >>> strongly consistent between VMs when running on the same physical = host, >>> and more loose cluster-wide. >>>=20 >>> - every library exposes a set of keys and values, as well as a = mechanism >>> for session setup, authentication and teardown (the lifecycle of the >>> process. Plan 9 used ASCII for everything, whereas Mirage would = layer >>> a well-typed API on top of it (e.g. just write a record to a file = rather >>> than manually serialising it). >>>=20 >>> - extend the Xen Cloud Platform to support delegation, so that = microVMs >>> can be monitored or killed by supervisors. Unlike Plan9, this also >>> includes operations across physical hosts (e.g. live relocation), or >>> across cloud providers. >>>=20 >>> There are some nice implications of this work that goes beyond = Mirage: >>>=20 >>> - it generally applies to all of the exokernel libraries out there, >>> including HalVM (Haskell) or GuestVM (Java), as they all have this >>> control problem that makes manpulating raw kernels such a pain to = do. >>>=20 >>> - it can easily be extended to support existing applications on a >>> monolithic guest kernel, and in make it easier to manage them too. >>>=20 >>> - application synthesis becomes much more viable: this approach = could let >>> me build a HTTP microkernel without a TCP stack, and simply receive = a >>> typed RPC from a HTTP proxy (which has done all the work of parsing = the >>> TCP and HTTP bits, so why repeat it?). If my HTTP server = microkernel >>> later live migrates away, then it could swap back to a network = connection. >>>=20 >>> Modern cloudy applications (especialy Hadoop or CIEL) use HTTP very >>> heavily to talk between components, so optimising this part of the = stack >>> is worthwhile (numbers needed!) >>>=20 >>> - Even if components are compiled up in the same binary and use = function >>> calls, they still have to establish and authenticate connections to = each >>> others. This makes monitoring and scaling hugely easier, since the=20= >>> control filesystem operations provide a natural logging and = introspection >>> point, even for large clusters. If we had a = hardware-capability-aware >>> CPU in the future, it could use this information too :-) >>>=20 >>> I highly recommend that anyone interested in this area read the Plan = 9 >>> paper, as it's a really good read anyway [1]. Also the Scout OS and >>> x-kernel stack are good. Our main difference from this work is the >>> heavy emphasis on type-safe components, as well as realistic = deployment >>> due to the use of Xen cloud providers as a stable hardware = interface. >>>=20 >>> In the very short-term, Mort and I have an OpenFlow tutorial coming = up in >>> mid-November, so I'll lash up the network stack to have a manual = version >>> of this as soon as possible, so that you can configure all the tap >>> interfaces and such much more quickly. Meanwhile, all and any = thoughts >>> are most welcome! >>>=20 >>> [1] Plan 9 papers: http://cm.bell-labs.com/sys/doc/ >>>=20 >>> --=20 >>> Anil Madhavapeddy = http://anil.recoil.org >>>=20 >>=20 >>=20 >=20 >=20 >=20 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1831 / Virus Database: 2090/4557 - Release Date: = 10/17/11 >=20 From anil@recoil.org Mon Oct 17 14:26:35 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RFnD9-0001x5-1i (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 14:26:35 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:34748 helo=dark.recoil.org) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with smtp (csa=unknown) id 1RFnD8-0006sW-qp (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Mon, 17 Oct 2011 14:26:35 +0100 Received: (qmail 32123 invoked by uid 634); 17 Oct 2011 13:26:33 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.4 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from Unknown (HELO [172.17.29.71]) (12.238.56.2) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.83) with ESMTPA; Mon, 17 Oct 2011 14:26:32 +0100 Subject: Re: Thoughts on cloud control APIs for Mirage Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Anil Madhavapeddy In-Reply-To: Date: Mon, 17 Oct 2011 09:26:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5420C1E7-4B58-4D94-B4BC-E7D17AE5786B@recoil.org> References: <20111017114531.GA8005@dark.recoil.org> <72561A3D-2CE3-4098-9F85-4FF63DA1CF58@gmail.com> <921B1832-6164-4929-B8D8-596B3E502021@recoil.org> <7749CD9FB4CE5940A68F1DF96D34A66401FF4514A3CA@paddington.ad.cl.cam.ac.uk> To: Steven Hand X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: "cl-mirage@lists.cam.ac.uk List" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:26:35 -0000 X-Keywords: X-UID: 112 Status: O Content-Length: 336 Lines: 12 On 17 Oct 2011, at 09:03, Anil Madhavapeddy wrote: > I've got the 'Life and times of a Zookeeper' paper on my iPad for = reading next, in fact! :-) Sorry, this was just an abstract as Jon points out. The full USENIX ATC = Zookeeper (best paper) from last year is: http://www.usenix.org/event/atc10/tech/full_papers/Hunt.pdf -anil= From anil@recoil.org Wed Oct 19 12:19:22 2011 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RGUB8-0004Jz-Pu (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 12:19:22 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:39380 helo=dark.recoil.org) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with smtp (csa=unknown) id 1RGUB8-0006q6-DI (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 12:19:22 +0100 Received: (qmail 22164 invoked by uid 634); 19 Oct 2011 11:19:21 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.4 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from c-68-39-180-43.hsd1.nj.comcast.net (HELO [192.168.1.9]) (68.39.180.43) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.83) with ESMTPA; Wed, 19 Oct 2011 12:19:21 +0100 From: Anil Madhavapeddy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Mirage: the action movie! Date: Wed, 19 Oct 2011 07:19:19 -0400 Message-Id: To: "cl-mirage@lists.cam.ac.uk List" , NetOS List Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: Michael Dales , Andrew Peace , Eiko Yoneki , Rolf Neugebauer X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 11:19:22 -0000 X-Keywords: X-UID: 113 Status: O Content-Length: 509 Lines: 15 The Verisign Internet Symposium is now done, and I wanted to share two = of the funny videos starring Mirage with you all! Vint Cerf introducing the projects: http://www.youtube.com/watch?v=3DiaoZEdExIEw#t=3D17s The four researchers, with us second (starting at about 1:20) http://www.youtube.com/watch?v=3D5-4lbyD_Fvw#t=3D75s Hilarious cameos from Andy Peace "doing old skool debugging" and Michael = Dales (go Massarros coffee!), and Jon, Rolf and Eiko "captured in the = wild" at the Kingston. -anil= From rolf@fastmail.us Wed Oct 19 13:27:11 2011 Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RGVEl-0007HU-IU (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:27:11 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -2.7 from SpamAssassin-3.3.2-1162027 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [66.111.4.29 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (rolf[at]fastmail.us) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from out5.smtp.messagingengine.com ([66.111.4.29]:43436) by ppsw-50.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.147]:25) with esmtp (csa=ok) id 1RGVEk-0006eT-rK (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:27:11 +0100 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 075102075B; Wed, 19 Oct 2011 08:27:10 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 19 Oct 2011 08:27:10 -0400 X-Sasl-enc: blpDfTkOY4oErj7R90jmWAvzVgnRWWezboQ6UAfVL/2d 1319027229 Received: from [10.11.210.24] (unknown [212.183.140.45]) by mail.messagingengine.com (Postfix) with ESMTPSA id 580F148343B; Wed, 19 Oct 2011 08:27:09 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9A334) From: Rolf Neugebauer Subject: Re: Mirage: the action movie! Date: Wed, 19 Oct 2011 13:27:03 +0100 To: Anil Madhavapeddy Cc: NetOS List , Andrew Peace , Michael Dales , Eiko Yoneki , "cl-mirage@lists.cam.ac.uk List" , Rolf Neugebauer X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:27:11 -0000 X-Keywords: X-UID: 114 Status: O Content-Length: 689 Lines: 26 On 19 Oct 2011, at 12:19, Anil Madhavapeddy wrote: > The Verisign Internet Symposium is now done, and I wanted to share two of t= he funny videos starring Mirage with you all! >=20 > Vint Cerf introducing the projects: > http://www.youtube.com/watch?v=3DiaoZEdExIEw#t=3D17s >=20 > The four researchers, with us second (starting at about 1:20) > http://www.youtube.com/watch?v=3D5-4lbyD_Fvw#t=3D75s >=20 > Hilarious cameos from Andy Peace "doing old skool debugging" and Michael D= ales (go Massarros coffee!), and Jon, Rolf and Eiko "captured in the wild" a= t the Kingston. I expect royalty payments for being in a verisign promotional video. Rolf >=20 > -anil From anil@recoil.org Wed Oct 19 13:33:29 2011 Received: from ppsw-41.csi.cam.ac.uk ([131.111.8.141]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RGVKr-0007b0-2a (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:33:29 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:18445 helo=dark.recoil.org) by ppsw-41.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with smtp (csa=unknown) id 1RGVKp-0008KK-Sv (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:33:28 +0100 Received: (qmail 26250 invoked by uid 634); 19 Oct 2011 12:33:27 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.4 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from c-68-39-180-43.hsd1.nj.comcast.net (HELO [192.168.1.9]) (68.39.180.43) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.83) with ESMTPA; Wed, 19 Oct 2011 13:33:27 +0100 Subject: Re: Mirage: the action movie! Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Anil Madhavapeddy In-Reply-To: Date: Wed, 19 Oct 2011 08:33:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <396C764D-8AFA-487D-8227-C87EBB08ADA0@recoil.org> References: To: Rolf Neugebauer X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: NetOS List , Andrew Peace , Michael Dales , Eiko Yoneki , "cl-mirage@lists.cam.ac.uk List" , Rolf Neugebauer X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:33:29 -0000 X-Keywords: X-UID: 115 Status: O Content-Length: 886 Lines: 25 On 19 Oct 2011, at 08:27, Rolf Neugebauer wrote: >=20 > On 19 Oct 2011, at 12:19, Anil Madhavapeddy wrote: >=20 >> The Verisign Internet Symposium is now done, and I wanted to share = two of the funny videos starring Mirage with you all! >>=20 >> Vint Cerf introducing the projects: >> http://www.youtube.com/watch?v=3DiaoZEdExIEw#t=3D17s >>=20 >> The four researchers, with us second (starting at about 1:20) >> http://www.youtube.com/watch?v=3D5-4lbyD_Fvw#t=3D75s >>=20 >> Hilarious cameos from Andy Peace "doing old skool debugging" and = Michael Dales (go Massarros coffee!), and Jon, Rolf and Eiko "captured = in the wild" at the Kingston. >=20 > I expect royalty payments for being in a verisign promotional video. Get in line behind Andy Peace -- I think the dumps of paper he was = poring over were tracing lost Linux guest interrupts or something ... -a= From jac22@cl.cam.ac.uk Wed Oct 19 13:35:14 2011 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RGVMY-0007hI-J1 (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:35:14 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -3.4 from SpamAssassin-3.3.2-1162027 * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay * domain * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mta1.cl.cam.ac.uk ([128.232.25.21]:49458) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp id 1RGVMY-0000ym-Cz (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:35:14 +0100 Received: from ramsey.cl.cam.ac.uk ([128.232.1.219] helo=cl.cam.ac.uk) by mta1.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1RGVLO-0004aq-1m; Wed, 19 Oct 2011 13:34:02 +0100 To: Rolf Neugebauer Subject: Re: Mirage: the action movie! In-reply-to: References: Comments: In-reply-to Rolf Neugebauer message dated "Wed, 19 Oct 2011 13:27:03 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7223.1319027638.1@cl.cam.ac.uk> Date: Wed, 19 Oct 2011 13:33:58 +0100 From: Jon Crowcroft Message-Id: Cc: Anil Madhavapeddy , NetOS List , Jon.Crowcroft@cl.cam.ac.uk, Andrew Peace , Michael Dales , Eiko Yoneki , "cl-mirage@lists.cam.ac.uk List" , Rolf Neugebauer X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:35:14 -0000 X-Keywords: X-UID: 116 Status: O Content-Length: 984 Lines: 40 I expect to see "rolf image" click analytics in your invoice:) Is payment in Kingston B-Tokens acceptable? In missive , Rolf Neugebauer typed: >> >> >> >> >>On 19 Oct 2011, at 12:19, Anil Madhavapeddy wrote: >> >>> The Verisign Internet Symposium is now done, and I wanted to share two of t= >>he funny videos starring Mirage with you all! >>>=20 >>> Vint Cerf introducing the projects: >>> http://www.youtube.com/watch?v=3DiaoZEdExIEw#t=3D17s >>>=20 >>> The four researchers, with us second (starting at about 1:20) >>> http://www.youtube.com/watch?v=3D5-4lbyD_Fvw#t=3D75s >>>=20 >>> Hilarious cameos from Andy Peace "doing old skool debugging" and Michael D= >>ales (go Massarros coffee!), and Jon, Rolf and Eiko "captured in the wild" a= >>t the Kingston. >> >>I expect royalty payments for being in a verisign promotional video. >> >>Rolf >> >>>=20 >>> -anil >> cheers jon From rolf.neugebauer@gmail.com Wed Oct 19 13:39:32 2011 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RGVQi-0000Dh-Rj (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:39:32 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -2.7 from SpamAssassin-3.3.2-1162027 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.220.179 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (rolf.neugebauer[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail-vx0-f179.google.com ([209.85.220.179]:48472) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp (csa=unknown) id 1RGVQi-0002ro-DP (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Wed, 19 Oct 2011 13:39:32 +0100 Received: by vcbfl13 with SMTP id fl13so1570189vcb.38 for ; Wed, 19 Oct 2011 05:39:31 -0700 (PDT) Received: by 10.52.24.34 with SMTP id r2mr6609521vdf.44.1319027971389; Wed, 19 Oct 2011 05:39:31 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) From: Rolf Neugebauer Date: Wed, 19 Oct 2011 13:39:28 +0100 Message-ID: <5225145326229457398@unknownmsgid> Subject: Re: Mirage: the action movie! To: Jon Crowcroft Content-Type: text/plain; charset=ISO-8859-1 Cc: Anil Madhavapeddy , Rolf Neugebauer , NetOS List , Andrew Peace , Michael Dales , Eiko Yoneki , "cl-mirage@lists.cam.ac.uk List" , Rolf Neugebauer X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:39:32 -0000 X-Keywords: X-UID: 117 Status: O Content-Length: 1127 Lines: 47 On 19 Oct 2011, at 13:34, Jon Crowcroft wrote: > I expect to see "rolf image" click analytics in your invoice:) > > Is payment in Kingston B-Tokens acceptable? (JH)B-Tokens are an acceptable. Rolf > > > In missive , Rolf Neugebauer > typed: > >>> >>> >>> >>> >>> On 19 Oct 2011, at 12:19, Anil Madhavapeddy wrote: >>> >>>> The Verisign Internet Symposium is now done, and I wanted to share two of t= >>> he funny videos starring Mirage with you all! >>>> =20 >>>> Vint Cerf introducing the projects: >>>> http://www.youtube.com/watch?v=3DiaoZEdExIEw#t=3D17s >>>> =20 >>>> The four researchers, with us second (starting at about 1:20) >>>> http://www.youtube.com/watch?v=3D5-4lbyD_Fvw#t=3D75s >>>> =20 >>>> Hilarious cameos from Andy Peace "doing old skool debugging" and Michael D= >>> ales (go Massarros coffee!), and Jon, Rolf and Eiko "captured in the wild" a= >>> t the Kingston. >>> >>> I expect royalty payments for being in a verisign promotional video. >>> >>> Rolf >>> >>>> =20 >>>> -anil >>> > > cheers > > jon > From Richard.Mortier@nottingham.ac.uk Sun Oct 23 08:26:34 2011 Received: from ppsw-41.csi.cam.ac.uk ([131.111.8.141]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RHsS2-00038D-5r (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 23 Oct 2011 08:26:34 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.2 from SpamAssassin-3.3.2-1162027 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from thb-mta-19-tx.emailfiltering.com ([194.116.199.150]:43645 helo=thb-mta-19.emailfiltering.com) by ppsw-41.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (csa=unknown) id 1RHsRw-0001ZK-RN (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 23 Oct 2011 08:26:34 +0100 Received: from smtp1.nottingham.ac.uk ([128.243.44.4]) by thb-mta-19.emailfiltering.com with emfmta (version 4.8.5.33) vanilla id 2161670462 for cl-mirage@lists.cam.ac.uk; f8631ea60fc828c5; Sun, 23 Oct 2011 08:26:08 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp1.nottingham.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1RHsRa-00009v-9U for cl-mirage@lists.cam.ac.uk; Sun, 23 Oct 2011 08:26:06 +0100 Received: from EXCHANGE1.ad.nottingham.ac.uk ([fe80::7962:f868:e6ee:6267]) by UIWEXHUB02.ad.nottingham.ac.uk ([2002:80f3:f84::80f3:f84]) with mapi; Sun, 23 Oct 2011 08:26:44 +0100 From: Richard Mortier To: Mirage List Date: Sun, 23 Oct 2011 08:25:32 +0100 Subject: openflow on mirage Thread-Topic: openflow on mirage Thread-Index: AcyRVR1q35g4uJ/yRy2jDBoEzutYug== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 07:26:34 -0000 X-Keywords: X-UID: 118 Status: O Content-Length: 5184 Lines: 73 hi all;

have p= ushed-

* some tweaks to the parser library and har= is' controller;
* a skeleton (builds, does nothing, has some huge= holes) of an OF switch;
* some very crude and untested regressio= ns ported from tests/ ;
* docs of all the above in README.md; and=
* an outline of the best i can manage for a test setup on OSX in= TESTING.md

could anyone on the list with openflow experience take a look and see = what's missing/wrong?

also, there're a couple = of questions at the end of the README.md which might be challenges for the = new device model as applied to networking- the last question in partic= ular describes what i think we should aim for.  but, as i've no feel f= or how feasible/how much work it is given the current state of the code and= the capabilities of the device and network demux model, some input from th= ose who's ocaml's better than mine would be appreciated.  (and indeed,= anyone who's likely to use mirage to write networking stuff might want to = comment whether what i'm suggesting "feels right".)

code = in my fork, https://github.= com/mor1/mirage, branch "openflow", under ./lib/openflow/ with the= ported but as-yet-untested-in-this-tree regression tests under ./regress/o= penflow/.
-- 
Cheers,
R.

=
=0D=0A

=0D=0AThis message and any attachment are intended solely= for the addressee and may=20=0D=0Acontain confidential information. If= you have received this message in error,=20=0D=0Aplease send it back t= o me, and immediately delete it. Please do not use,=20=0D=0Acopy or d= isclose the information contained in this message or in any attachment.= =20=0D=0AAny views or opinions expressed by the author of this email d= o not necessarily=20=0D=0Areflect the views of the University of Nottin= gham.=0D=0A

=0D=0A

=0D=0AThis message has been checked for viruses= but the contents of an attachment=0D=0Amay still contain software viru= ses which could damage your computer system:=0D=0Ayou are advised to pe= rform your own checks. Email communications with the=0D=0AUniversity of= Nottingham may be monitored as permitted by UK legislation.=0D=0A

= = From fam40@cam.ac.uk Thu Oct 27 21:02:38 2011 Received: from ppsw-41.csi.cam.ac.uk ([131.111.8.141]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RJW9t-0005zQ-VG (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 27 Oct 2011 21:02:37 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [62.49.66.12] (port=50557 helo=Farhan.local) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:465) with esmtpsa (PLAIN:fam40) (TLSv1:DHE-RSA-AES256-SHA:256) id 1RJW9t-0002Nr-SX (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Thu, 27 Oct 2011 21:02:37 +0100 Date: Thu, 27 Oct 2011 21:02:38 +0100 From: Farhan Mannan To: Mirage List Message-ID: Subject: Installing libraries X-Mailer: sparrow 1.4 (build 904) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4ea9b8de_431bd7b7_ac" X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 20:02:38 -0000 X-Keywords: X-UID: 119 Status: O Content-Length: 1617 Lines: 47 --4ea9b8de_431bd7b7_ac Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline So for my XMPP stuff I'm trying to get this bot working (http://github.com/ermine/sulci (https://github.com/ermine/sulci)) I've installed all of the required libraries and now it doesn't complain about THAT BUT NOW when I run ./configure, make or sudo make install, it hangs on: Finished, 0 targets (0 cached) in 00:00:00. 00:00:21 99 (98 ) plugin_cerberus.cmo (I quit that one early but the timer just runs indefinitely) What is cerberus? What's going on here? Thanks, Farhan --4ea9b8de_431bd7b7_ac Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
So for my XMPP stuff I'm trying to get this bot worki= ng


I've installed all of the required libraries and now it doesn't com= plain about THAT

BUT NOW when I run ./configure,= make or sudo make install, it hangs on:

=46= inished, 0 targets (0 cached) in 00:00:00.
00:00:21 99   (= 98  ) plugin=5Fcerberus.cmo  

(I quit = that one early but the timer just runs indefinitely)

=
What is cerberus=3F What's going on here=3F

Thanks,
=46arhan

--4ea9b8de_431bd7b7_ac-- From raphlalou@gmail.com Fri Oct 28 09:07:41 2011 Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RJhTZ-0006Xe-DZ (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 28 Oct 2011 09:07:41 +0100 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -2.7 from SpamAssassin-3.3.2-1162027 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.210.179 listed in list.dnswl.dnsbl.ja.net] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (raphlalou[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail-iy0-f179.google.com ([209.85.210.179]:48261) by ppsw-52.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.149]:25) with esmtp (csa=unknown) id 1RJhTY-0003Ql-FM (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Fri, 28 Oct 2011 09:07:41 +0100 Received: by iajr24 with SMTP id r24so4541399iaj.38 for ; Fri, 28 Oct 2011 01:07:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.159.1 with SMTP id j1mr2930966icx.20.1319789259736; Fri, 28 Oct 2011 01:07:39 -0700 (PDT) Received: by 10.42.175.132 with HTTP; Fri, 28 Oct 2011 01:07:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 09:07:39 +0100 Message-ID: Subject: Re: Installing libraries From: Raphael Proust To: Farhan Mannan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mirage List X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 08:07:41 -0000 X-Keywords: X-UID: 120 Status: O Content-Length: 757 Lines: 21 On Thu, Oct 27, 2011 at 9:02 PM, Farhan Mannan wrote: > So for my XMPP stuff I'm trying to get this bot working > (http://github.com/ermine/sulci) > I've installed all of the required libraries and now it doesn't complain > about THAT > BUT NOW when I run ./configure, make or sudo make install, it hangs on: > Finished, 0 targets (0 cached) in 00:00:00. > 00:00:21 99 =C2=A0 (98 =C2=A0) plugin_cerberus.cmo > (I quit that one early but the timer just runs indefinitely) > What is cerberus? What's going on here? https://github.com/ermine/sulci/blob/master/plugin_cerberus.ml seems to be some sort of Cyrillic kick-ban bot module=E2=80=A6 Has anything weird/unusual happened during the install process of Sulci? --=20 _______ Raphael From avsm@dark.recoil.org Sun Oct 30 12:33:19 2011 Received: from ppsw-51.csi.cam.ac.uk ([131.111.8.151]) by lists-2.csi.cam.ac.uk (lists.cam.ac.uk [131.111.8.15]:25) with esmtp id 1RKUZj-0006HH-6m (Exim 4.70) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 30 Oct 2011 12:33:19 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: score -1.9 from SpamAssassin-3.3.2-1190771 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from recoil.dh.bytemark.co.uk ([89.16.177.154]:12418 helo=dark.recoil.org) by ppsw-51.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25) with smtp (csa=unknown) id 1RKUZi-0000bl-Xv (Exim 4.72) for cl-mirage@lists.cam.ac.uk (return-path ); Sun, 30 Oct 2011 12:33:19 +0000 Received: (qmail 932 invoked by uid 10000); 30 Oct 2011 12:33:18 -0000 Date: Sun, 30 Oct 2011 12:33:18 +0000 From: Anil Madhavapeddy To: Raphael Proust Subject: Re: Installing libraries Message-ID: <20111030123318.GM24862@dark.recoil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mirage List , Farhan Mannan X-BeenThere: cl-mirage@lists.cam.ac.uk X-Mailman-Version: 2.1.8 Precedence: list List-Id: MirageOS development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 12:33:19 -0000 X-Keywords: X-UID: 121 Status: O Content-Length: 1218 Lines: 25 On Fri, Oct 28, 2011 at 09:07:39AM +0100, Raphael Proust wrote: > On Thu, Oct 27, 2011 at 9:02 PM, Farhan Mannan wrote: > > So for my XMPP stuff I'm trying to get this bot working > > (http://github.com/ermine/sulci) > > I've installed all of the required libraries and now it doesn't complain > > about THAT > > BUT NOW when I run ./configure, make or sudo make install, it hangs on: > > Finished, 0 targets (0 cached) in 00:00:00. > > 00:00:21 99 ?? (98 ??) plugin_cerberus.cmo > > (I quit that one early but the timer just runs indefinitely) > > What is cerberus? What's going on here? > > https://github.com/ermine/sulci/blob/master/plugin_cerberus.ml seems > to be some sort of Cyrillic kick-ban bot module??? > Has anything weird/unusual happened during the install process of Sulci? It might be something to do with internationalisation indeed. I'll try to get the various bits installed and see if it happens on my Mac. Meanwhile, you can edit the Makefile to add 'ocamlbuild -classic-display' to the command line instead of just 'ocamlbuild', and it will display more information. Could you try that, Farhan? -- Anil Madhavapeddy http://anil.recoil.org