From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 11:04:14 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 11:04:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvOm0-00024B-Ii; Mon, 01 Dec 2014 11:04:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvOly-00023z-O5 for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:04:06 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id F8/48-25276-62B4C745; Mon, 01 Dec 2014 11:04:06 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1417431844!9102998!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13440 invoked from network); 1 Dec 2014 11:04:05 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 11:04:05 -0000 Received: by mail-vc0-f171.google.com with SMTP id hy4so4462960vcb.16 for ; Mon, 01 Dec 2014 03:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nEfKpfOdX6fBWlgvo4XhOO8cDP92NaHgWHJY+B10jj0=; b=JtOuoHYNH1d4zVJAn+vVTi+/iIncp3ErO5E63X/YgAMW9Sh11sO3r0Tf2hgKn7I/y4 d/+Tm9ERQJoMrkVzr8yafXk++htUYjpDeB5jiPyJyZTJY/yDps1oFhJOQHpEh/gSwSRp o1/ellq7daidNFUbp5dvb8tgkkgHxMr19JK3FimLidPZWoBCCRx0sj/wOixpT0YZTD7d GTg2ig1x0u6mlaUtekzK50gYb6DYoDjsP22KNGwOMIuquy8USHQuVpTTr4Bh+ArAbLzw FjYv9CcO6jB28XLl3YVhoam9AlbClO4Un5o35IBiJoi+IKdrXITtle2qCZjhrMykvTGt ewCw== MIME-Version: 1.0 X-Received: by 10.52.186.69 with SMTP id fi5mr22218121vdc.46.1417431844586; Mon, 01 Dec 2014 03:04:04 -0800 (PST) Received: by 10.31.183.134 with HTTP; Mon, 1 Dec 2014 03:04:04 -0800 (PST) Date: Mon, 1 Dec 2014 11:04:04 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is taking a bit longer than expected... here's the current status. I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by compiling in an OPAM switch with the right CFLAGS for Mini-OS. However, we don't want to do it this way because dealing with OPAM switches is annoying. Instead, I'm adding an ocamlfind variable which packages can use to indicate the C stubs to link against under Xen. e.g. tcpip would put this in its META file: xen_linkopts = "-ltcpip_xen_stubs" No libraries will be linked without this option, so we won't accidentally link Unix libraries. This is important on x86_64, where linking Unix libraries creates subtle race conditions due to the "red zone" not being available in kernel mode. When testing this, I realised we compile openlibm for Unix, so I updated that to get the CFLAGS from Mini-OS, but it turned out that didn't work because Mini-OS doesn't provide sys/types.h (just types.h), and also openlibm used some legacy type names that Mini-OS doesn't provide. sys/types.h is currently provided by mirage-platform. Options: 1. Make openlibm depend on mirage-platform to get sys/types.h. 2. Rename Mini-OS's types.h to sys/types.h and put everything there. 3. Modify openlibm to use only stdint.h. I'm leaning towards option (3) at the moment (assuming it's possible), but shout if you have a better idea! After that, I'll update mirage-profile and tcpip to the new linking system and make a pull request for the updated mirage tool. You'll probably need to update several things at once when this happens. Then we'll be in a position to add the tls libraries. That might require a little extra work if we want to add Xen C stubs to 3rd-party packages (e.g. zarith). Anil has suggested using OPAM depexts for this. Finally, we could really use some pkg-config support in OASIS. Otherwise, getting the necessary CFLAGS is unreasonably difficult... -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 11:04:14 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 11:04:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvOm0-00024B-Ii; Mon, 01 Dec 2014 11:04:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvOly-00023z-O5 for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 11:04:06 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id F8/48-25276-62B4C745; Mon, 01 Dec 2014 11:04:06 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1417431844!9102998!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13440 invoked from network); 1 Dec 2014 11:04:05 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 11:04:05 -0000 Received: by mail-vc0-f171.google.com with SMTP id hy4so4462960vcb.16 for ; Mon, 01 Dec 2014 03:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nEfKpfOdX6fBWlgvo4XhOO8cDP92NaHgWHJY+B10jj0=; b=JtOuoHYNH1d4zVJAn+vVTi+/iIncp3ErO5E63X/YgAMW9Sh11sO3r0Tf2hgKn7I/y4 d/+Tm9ERQJoMrkVzr8yafXk++htUYjpDeB5jiPyJyZTJY/yDps1oFhJOQHpEh/gSwSRp o1/ellq7daidNFUbp5dvb8tgkkgHxMr19JK3FimLidPZWoBCCRx0sj/wOixpT0YZTD7d GTg2ig1x0u6mlaUtekzK50gYb6DYoDjsP22KNGwOMIuquy8USHQuVpTTr4Bh+ArAbLzw FjYv9CcO6jB28XLl3YVhoam9AlbClO4Un5o35IBiJoi+IKdrXITtle2qCZjhrMykvTGt ewCw== MIME-Version: 1.0 X-Received: by 10.52.186.69 with SMTP id fi5mr22218121vdc.46.1417431844586; Mon, 01 Dec 2014 03:04:04 -0800 (PST) Received: by 10.31.183.134 with HTTP; Mon, 1 Dec 2014 03:04:04 -0800 (PST) Date: Mon, 1 Dec 2014 11:04:04 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is taking a bit longer than expected... here's the current status. I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by compiling in an OPAM switch with the right CFLAGS for Mini-OS. However, we don't want to do it this way because dealing with OPAM switches is annoying. Instead, I'm adding an ocamlfind variable which packages can use to indicate the C stubs to link against under Xen. e.g. tcpip would put this in its META file: xen_linkopts = "-ltcpip_xen_stubs" No libraries will be linked without this option, so we won't accidentally link Unix libraries. This is important on x86_64, where linking Unix libraries creates subtle race conditions due to the "red zone" not being available in kernel mode. When testing this, I realised we compile openlibm for Unix, so I updated that to get the CFLAGS from Mini-OS, but it turned out that didn't work because Mini-OS doesn't provide sys/types.h (just types.h), and also openlibm used some legacy type names that Mini-OS doesn't provide. sys/types.h is currently provided by mirage-platform. Options: 1. Make openlibm depend on mirage-platform to get sys/types.h. 2. Rename Mini-OS's types.h to sys/types.h and put everything there. 3. Modify openlibm to use only stdint.h. I'm leaning towards option (3) at the moment (assuming it's possible), but shout if you have a better idea! After that, I'll update mirage-profile and tcpip to the new linking system and make a pull request for the updated mirage tool. You'll probably need to update several things at once when this happens. Then we'll be in a position to add the tls libraries. That might require a little extra work if we want to add Xen C stubs to 3rd-party packages (e.g. zarith). Anil has suggested using OPAM depexts for this. Finally, we could really use some pkg-config support in OASIS. Otherwise, getting the necessary CFLAGS is unreasonably difficult... -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 12:40:10 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 12:40:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvQGp-0006V1-09; Mon, 01 Dec 2014 12:40:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvQGn-0006Us-DI for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 12:40:01 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id DB/3B-15461-0A16C745; Mon, 01 Dec 2014 12:40:00 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1417437599!12548579!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20707 invoked from network); 1 Dec 2014 12:39:59 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 12:39:59 -0000 Received: by mail-wi0-f178.google.com with SMTP id hi2so17109970wib.17 for ; Mon, 01 Dec 2014 04:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WbGJwtT8I88NaVGmzf/BC3m+QstFGFmm0LjhP/fvDFo=; b=xp3lOzqbN366po1jjDsQYRGRstBH54/mldUSnbynLpNLVRRqWv7QD0S5y+P8p9ezzW nYl0m2Y8G3ch2HaCQjgwhE8akOuvpwnAy1HgQy7m3+n2KnUmjKZR9UyiD7bMZx8QUtjs 9ec4fHlfWtMm6mcjbEUp3t/S7f5UZtryShLlZFUkJ8tAhtUkFmgfQDQMgLIDQ1pMSv/t Vbg3Gykifx7tjij7q//jmZZMJIrySOWWofG0uOlgsmgOv4AwwKqrN9JAW+43eu3+Xom7 XeJcWBsqd7sl0sn7QewIskJdwpReBLL2MGwTBsRPOliL6gyfsZ+ibV+JuoB0LgzY5kJc ROmw== MIME-Version: 1.0 X-Received: by 10.180.23.98 with SMTP id l2mr83377278wif.51.1417437599418; Mon, 01 Dec 2014 04:39:59 -0800 (PST) Received: by 10.27.171.146 with HTTP; Mon, 1 Dec 2014 04:39:59 -0800 (PST) In-Reply-To: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> Date: Mon, 1 Dec 2014 12:39:59 +0000 X-Google-Sender-Auth: oH24DDYr9cSbpAbb8bufd12WMCc Message-ID: From: Nicolas Ojeda Bar To: Richard Mortier Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgbGlzdCwKCkkgaGF2ZSBhIHdvcmtpbmcgdmVyc2lvbiBvZiB0aGUgYG1pcmFnZSBjb25maWd1 cmVgIHRvb2wgdGhhdCBhbGxvd3MgdGhlCmluZGl2aWR1YWwgQ09ORklHVVJBQkxFcyB0byBkZWNs YXJlIGEgbGlzdCBvZiBwYXJhbWV0ZXIgdGhhdCBpdCB1c2VzLgpUaGUgc2V0IG9mIGFsbCB0aGUK cGFyYW1ldGVycyB1c2VkIGJ5IHRoZSB1bmlrZXJuZWwgY2FuIHRoZW4gYmUgc2V0IHVzaW5nIENt ZGxpbmVyIHRlcm1zIGFuZAp0aGV5IGFyZSBzaG93biBpbiBgbWlyYWdlIGNvbmZpZ3VyZSAtLWhl bHBgLgoKRXhhbXBsZToKClRoZSBJUFY0OiBDT05GSUdVUkFCTEUgZGVjbGFyZXMgcGFyYW1ldGVy cyAiaXAiLCAibmV0bWFzayIsICJnYXRld2F5cyIgdGhlbgpvbmUgY2FuIHNldCB0aGVtIGFzIGZv bGxvd3M6CgokIG1pcmFnZSBjb25maWd1cmUgLS1pcCAxMC4wLjAuMiAtLW5ldG1hc2sgMjU1LjI1 NS4yNTUuMCAtLWdhdGV3YXlzPTEwLjAuMC4xCgpJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIHVzZSBl bnZpcm9ubWVudCB2YXJpYWJsZXMgb2YgdGhlIHNhbWUgbmFtZSBhbmQKaXQgd2lsbCBiZSBwb3Nz aWJsZSB0byBvdmVycmlkZSB0aGUgcGFyYW1ldGVyIHZhbHVlcyBhdCBydW4tdGltZSBzbwp0aGF0 IG9uZSBkb2VzIG5vdCBuZWVkIHRvIHJlY29tcGlsZSB0aGUgdW5pa2VybmVsIGVhY2ggdGltZSAo dGhpcwptaWdodCBtYWtlIHRoZSB1bmlrZXJuZWwgZGVwZW5kIG9uIENtZGxpbmVyLCB0aG91Z2gp LgoKSSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBiZXN0IHdheSB0byBoYW5kbGUgcGFy YW1ldGVyIG5hbWVzLgpPYnZpb3VzbHkgcGFyYW1ldGVyIG5hbWVzIG11c3QgYmUgdW5pcXVlLiBC dXQgaWYgb25lIGluc3RhbnRpYXRlcyBhCkNPTkZJR1VSQUJMRSBtb3JlIHRoYW4gb25jZSB0aGVu IHRob3NlIENPTkZJR1VSQUJMRXMgbWF5IGJlCmluc3RhbnRpYXRpbmcgcGFyYW1ldGVycyBvZiB0 aGUgc2FtZSBuYW1lLiBGb3IgZXhhbXBsZSBvbmUgY2FuIGltYWdpbmUKaW5zdGFudGlhdGluZyBJ UFY0IHR3aWNlIGFuZCB0aGVuIGJvdGggb2YgdGhlbSB3aWxsIGhhdmUgYSBwYXJhbWV0ZXJzCiJp cCIsICJuZXRtYXNrIiwgZXRjLgoKT25lIGNhbiBvZiBjb3Vyc2UsIG1ha2UgdGhlIG5hbWVzIHVu aXF1ZSBieSBjb21iaW5pbmcgdGhlIG5hbWUgb2YgdGhlCnBhcmFtZXRlciB3aXRoIHRoZSBuYW1l IG9mIHRoZSBDT05GSUdVUkFCTEUgKGN1cnJlbnRseQpzZW1pLWFsZ29yaXRobWljYWxseSBnZW5l cmF0ZWQgdG8ga2VlcCB0aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90CnNlZW0gdmVyeSB1 c2VyIGZyaWVuZGx5LgoKVGhvdWdodHMgPwoKQ2hlZXJzLApOaWNvbGFzCgpQUzogRm9yIHRob3Nl IHRoYXQgd2FudCB0byBsb29rIGF0IHRoZSBjb2RlICh3aGljaCBpcyB2ZXJ5IHJvdWdoKQphbmQv b3IgdHJ5IGl0IG91dCwgeW91IGNhbiBwaW4KCm9wYW0gcGluIGFkZCBtaXJhZ2UgaHR0cHM6Ly9n aXRodWIuY29tL25vamIvbWlyYWdlI2JldHRlci1wYXJhbXMKCmFuZCB5b3UgY2FuIHRyeSBpdCBv dXQgYnkgY2xvbmluZwpodHRwczovL2dpdGh1Yi5jb20vbm9qYi9taXJhZ2UtYmV0dGVyLXBhcmFt cy1leCBhbmQgcnVubmluZwpgbWlyYWdlIGNvbmZpZ3VyZSAtLWhlbHBgLgoKT24gU3VuLCBOb3Yg MzAsIDIwMTQgYXQgMTA6NDkgUE0sIFJpY2hhcmQgTW9ydGllcgo8UmljaGFyZC5Nb3J0aWVyQG5v dHRpbmdoYW0uYWMudWs+IHdyb3RlOgo+Cj4gT24gMzAgTm92IDIwMTQsIGF0IDIyOjQwLCBEYW5p ZWwgQsO8bnpsaSA8ZGFuaWVsLmJ1ZW56bGlAZXJyYXRpcXVlLmNoPiB3cm90ZToKPgo+Pgo+Pgo+ PiBMZSBkaW1hbmNoZSwgMzAgbm92ZW1icmUgMjAxNCDDoCAyMzowMywgUmljaGFyZCBNb3J0aWVy IGEgw6ljcml0IDoKPj4KPj4+IHJlIDEtLSBpJ20gcXVpdGUgKGluZGVlZCwgdmVyeSkgaGFwcHkg dG8gaGF2ZSB0aGlzIGF2YWlsYWJsZSB0byBtZSwgdGhvdWdoIGkgZG9uJ3QgdGhpbmsgaSdkIGFn cmVlIHdpdGggcXVpdGUgdGhlIHN0cmVuZ3RoIG9mIHlvdXIgc3RhdGVtZW50cyBhYm91dCBleHBv c2luZyBjb25maWd1cmF0aW9uIG9wdGlvbnMgdGhhdCBhcmVuJ3QgdXNlZCAoIm1pc2xlYWRpbmci LCAibm8gcG9pbnQiKS4gaSBkb24ndCBrbm93IHRoZSBhc3NlbWJsYWdlIGNvbmZpZ3VyYXRpb24g Zm9ybWF0IGF0IGFsbCwgYnV0IGlmIHRoZXJlIGFyZSAoYXMgc2VlbXMgY29tbW9uIHdpdGggb3Ro ZXIgZm9ybWF0cykgb3B0aW9ucyB0aGF0IGNhbiBvdmVycmlkZSBvciBpbnRlcmFjdCB3aXRoIGVh Y2ggb3RoZXIsIHRoZW4gc2VlaW5nIHdoYXRldmVyIGFyZSB0aGUgZGVmYXVsdCB2YWx1ZXMgcHJv dmlkZWQgZm9yIHRob3NlIG9wdGlvbnMgd2hlbiB0aGV5J3JlIG5vdCBleHBsaWNpdGx5IHVzZWQg aXMgcmF0aGVyIHVzZWZ1bC4gKHBhcnRpY3VsYXJseSBpZiB0aG9zZSBkZWZhdWx0cyBldmVyIGNo YW5nZS4pCj4+Cj4+IEFueXRoaW5nIHRoYXQgZXZlbnR1YWxseSBoYXMgYW4gaW1wYWN0IChlaXRo ZXIgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgd2lsbCBiZSBkb2N1bWVudGVkLiBEZXBlbmRlbmNp ZXMgYW1vbmcgY29uZmlndXJhdGlvbiBrZXlzIGFyZSB0cmFja2VkLgo+Cj4gb2ssIHRoYXQgc291 bmRzIGZhaXIuCj4KPj4+IHJlIDItLSB0aGlzIHNlZW1zIG1vcmUgb2YgYSB3b3JrZmxvdyB0aGlu ZyAoYW5kIHJlbWVtYmVyLCB0aGUgdXNlciBpcyBhbHdheXMgcmlnaHQgOykgLS0gY29tcGFyZSB0 aGUgdXRpbGl0eSBvZiAibWFuIGJhc2giIHRvICJtYW4gbWFrZSIgd2hlbiB3cml0aW5nIHNoZWxs IHNjcmlwdHMgdnMgbWFrZWZpbGVzLiAoYXQgbGVhc3Qgb24gYWxsIHN5c3RlbXMgaSd2ZSB1c2Vk IHJlY2VudGx5LikgaGF2aW5nIHRvIGdldCBob2xkIG9mIGEgYnJvd3NlciwgZ29vZ2xlIGZvciBn bnVtYWtlLCBmaW5kIHRoZSByaWdodCBnbnUub3JnIChodHRwOi8vZ251Lm9yZykgcGFnZSBhbmQg dGhlbiBzZWFyY2ggdGhyb3VnaCBpdCBpcyBhIHJveWFsIHBhaW4gKGV2ZW4gaWYgdGhlIGJhc2gg bWFuIHBhZ2UgaXMgaGFyZGx5IGFuIGV4ZW1wbGFyIG9mIGNsYXJpdHkgb3Igb3JnYW5pc2F0aW9u KS4KPj4gSW4gdGhpcyBjYXNlIHNpbmNlIHlvdSBhcmUgd3JpdGluZyBpbiBPQ2FtbCBhZ2FpbnN0 IGFuIE9DYW1sIEFQSSBzbyB5b3UgYXJlIGxlc3MgbGlrZWx5IHRvIGxvb2sgZm9yIGluZm9ybWF0 aW9uIGluIGEgbWFuIHBhZ2UgdGhhbiBpbiBvY2FtbGRvYyBnZW5lcmF0ZWQgZG9jdW1lbnRhdGlv biAodGhvdWdoIHN0cmljdGx5IHNwZWFraW5nIG9jYW1sZG9jIGhhcyBhLCBsaXR0bGUgdXNlZCwg bWFuIHBhZ2UgYmFja2VuZCkuIEFuZCBubyB0aGUgdXNlciBpcyBub3QgYWx3YXlzIHJpZ2h0LCB5 b3Ugc2hvdWxkIGNlcnRhaW5seSBuZXZlciBibGFtZSBpdCBmb3IgaXRzIGFjdGlvbnMgYnV0IHRo YXQgZG9lc24ndCBtZWFuIHRoYXQgaGUgaXMgYWx3YXlzIHJpZ2h0LCBpbiBmYWN0IGhlIGlzIG9m dGVuIHdyb25nIGVzcGVjaWFsbHkgaW4gd2hhdCBoZSB0aGlua3MgaGUgd2FudHMsIHRoYXQncyB0 aGUgcmVhc29uIHdoeSB3ZSBoYXZlIGRlc2lnbmVycy4KPgo+IHRoaXMgaXMgYSBwaGlsb3NvcGhp Y2FsIGRpc2N1c3Npb24gYmVzdCBoYWQgb3ZlciBhIHBpbnQgOikKPiAoaGFwcHkgZm9yIGRlc2ln bmVycyB0byBkZXNpZ24gdG9vbHM7IGJ1dCBteSB3b3JrZmxvd3MgYXJlIC0tIGdlbmVyYWxseSAt LSBteSBvd24uLi4pCj4KPiAtLQo+IENoZWVycywKPgo+IFIuCj4KPiBbIFRoaXMgYWRkcmVzcyBm YWlscyBvbiBEZWMzMS4gVXNlIHJpY2hhcmQubW9ydGllckBjbC5jYW0uYWMudWsgc3Vic2VxdWVu dGx5LiBdCj4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 12:40:10 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 12:40:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvQGp-0006V1-09; Mon, 01 Dec 2014 12:40:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvQGn-0006Us-DI for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 12:40:01 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id DB/3B-15461-0A16C745; Mon, 01 Dec 2014 12:40:00 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1417437599!12548579!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20707 invoked from network); 1 Dec 2014 12:39:59 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 12:39:59 -0000 Received: by mail-wi0-f178.google.com with SMTP id hi2so17109970wib.17 for ; Mon, 01 Dec 2014 04:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WbGJwtT8I88NaVGmzf/BC3m+QstFGFmm0LjhP/fvDFo=; b=xp3lOzqbN366po1jjDsQYRGRstBH54/mldUSnbynLpNLVRRqWv7QD0S5y+P8p9ezzW nYl0m2Y8G3ch2HaCQjgwhE8akOuvpwnAy1HgQy7m3+n2KnUmjKZR9UyiD7bMZx8QUtjs 9ec4fHlfWtMm6mcjbEUp3t/S7f5UZtryShLlZFUkJ8tAhtUkFmgfQDQMgLIDQ1pMSv/t Vbg3Gykifx7tjij7q//jmZZMJIrySOWWofG0uOlgsmgOv4AwwKqrN9JAW+43eu3+Xom7 XeJcWBsqd7sl0sn7QewIskJdwpReBLL2MGwTBsRPOliL6gyfsZ+ibV+JuoB0LgzY5kJc ROmw== MIME-Version: 1.0 X-Received: by 10.180.23.98 with SMTP id l2mr83377278wif.51.1417437599418; Mon, 01 Dec 2014 04:39:59 -0800 (PST) Received: by 10.27.171.146 with HTTP; Mon, 1 Dec 2014 04:39:59 -0800 (PST) In-Reply-To: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> Date: Mon, 1 Dec 2014 12:39:59 +0000 X-Google-Sender-Auth: oH24DDYr9cSbpAbb8bufd12WMCc Message-ID: From: Nicolas Ojeda Bar To: Richard Mortier Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgbGlzdCwKCkkgaGF2ZSBhIHdvcmtpbmcgdmVyc2lvbiBvZiB0aGUgYG1pcmFnZSBjb25maWd1 cmVgIHRvb2wgdGhhdCBhbGxvd3MgdGhlCmluZGl2aWR1YWwgQ09ORklHVVJBQkxFcyB0byBkZWNs YXJlIGEgbGlzdCBvZiBwYXJhbWV0ZXIgdGhhdCBpdCB1c2VzLgpUaGUgc2V0IG9mIGFsbCB0aGUK cGFyYW1ldGVycyB1c2VkIGJ5IHRoZSB1bmlrZXJuZWwgY2FuIHRoZW4gYmUgc2V0IHVzaW5nIENt ZGxpbmVyIHRlcm1zIGFuZAp0aGV5IGFyZSBzaG93biBpbiBgbWlyYWdlIGNvbmZpZ3VyZSAtLWhl bHBgLgoKRXhhbXBsZToKClRoZSBJUFY0OiBDT05GSUdVUkFCTEUgZGVjbGFyZXMgcGFyYW1ldGVy cyAiaXAiLCAibmV0bWFzayIsICJnYXRld2F5cyIgdGhlbgpvbmUgY2FuIHNldCB0aGVtIGFzIGZv bGxvd3M6CgokIG1pcmFnZSBjb25maWd1cmUgLS1pcCAxMC4wLjAuMiAtLW5ldG1hc2sgMjU1LjI1 NS4yNTUuMCAtLWdhdGV3YXlzPTEwLjAuMC4xCgpJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIHVzZSBl bnZpcm9ubWVudCB2YXJpYWJsZXMgb2YgdGhlIHNhbWUgbmFtZSBhbmQKaXQgd2lsbCBiZSBwb3Nz aWJsZSB0byBvdmVycmlkZSB0aGUgcGFyYW1ldGVyIHZhbHVlcyBhdCBydW4tdGltZSBzbwp0aGF0 IG9uZSBkb2VzIG5vdCBuZWVkIHRvIHJlY29tcGlsZSB0aGUgdW5pa2VybmVsIGVhY2ggdGltZSAo dGhpcwptaWdodCBtYWtlIHRoZSB1bmlrZXJuZWwgZGVwZW5kIG9uIENtZGxpbmVyLCB0aG91Z2gp LgoKSSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBiZXN0IHdheSB0byBoYW5kbGUgcGFy YW1ldGVyIG5hbWVzLgpPYnZpb3VzbHkgcGFyYW1ldGVyIG5hbWVzIG11c3QgYmUgdW5pcXVlLiBC dXQgaWYgb25lIGluc3RhbnRpYXRlcyBhCkNPTkZJR1VSQUJMRSBtb3JlIHRoYW4gb25jZSB0aGVu IHRob3NlIENPTkZJR1VSQUJMRXMgbWF5IGJlCmluc3RhbnRpYXRpbmcgcGFyYW1ldGVycyBvZiB0 aGUgc2FtZSBuYW1lLiBGb3IgZXhhbXBsZSBvbmUgY2FuIGltYWdpbmUKaW5zdGFudGlhdGluZyBJ UFY0IHR3aWNlIGFuZCB0aGVuIGJvdGggb2YgdGhlbSB3aWxsIGhhdmUgYSBwYXJhbWV0ZXJzCiJp cCIsICJuZXRtYXNrIiwgZXRjLgoKT25lIGNhbiBvZiBjb3Vyc2UsIG1ha2UgdGhlIG5hbWVzIHVu aXF1ZSBieSBjb21iaW5pbmcgdGhlIG5hbWUgb2YgdGhlCnBhcmFtZXRlciB3aXRoIHRoZSBuYW1l IG9mIHRoZSBDT05GSUdVUkFCTEUgKGN1cnJlbnRseQpzZW1pLWFsZ29yaXRobWljYWxseSBnZW5l cmF0ZWQgdG8ga2VlcCB0aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90CnNlZW0gdmVyeSB1 c2VyIGZyaWVuZGx5LgoKVGhvdWdodHMgPwoKQ2hlZXJzLApOaWNvbGFzCgpQUzogRm9yIHRob3Nl IHRoYXQgd2FudCB0byBsb29rIGF0IHRoZSBjb2RlICh3aGljaCBpcyB2ZXJ5IHJvdWdoKQphbmQv b3IgdHJ5IGl0IG91dCwgeW91IGNhbiBwaW4KCm9wYW0gcGluIGFkZCBtaXJhZ2UgaHR0cHM6Ly9n aXRodWIuY29tL25vamIvbWlyYWdlI2JldHRlci1wYXJhbXMKCmFuZCB5b3UgY2FuIHRyeSBpdCBv dXQgYnkgY2xvbmluZwpodHRwczovL2dpdGh1Yi5jb20vbm9qYi9taXJhZ2UtYmV0dGVyLXBhcmFt cy1leCBhbmQgcnVubmluZwpgbWlyYWdlIGNvbmZpZ3VyZSAtLWhlbHBgLgoKT24gU3VuLCBOb3Yg MzAsIDIwMTQgYXQgMTA6NDkgUE0sIFJpY2hhcmQgTW9ydGllcgo8UmljaGFyZC5Nb3J0aWVyQG5v dHRpbmdoYW0uYWMudWs+IHdyb3RlOgo+Cj4gT24gMzAgTm92IDIwMTQsIGF0IDIyOjQwLCBEYW5p ZWwgQsO8bnpsaSA8ZGFuaWVsLmJ1ZW56bGlAZXJyYXRpcXVlLmNoPiB3cm90ZToKPgo+Pgo+Pgo+ PiBMZSBkaW1hbmNoZSwgMzAgbm92ZW1icmUgMjAxNCDDoCAyMzowMywgUmljaGFyZCBNb3J0aWVy IGEgw6ljcml0IDoKPj4KPj4+IHJlIDEtLSBpJ20gcXVpdGUgKGluZGVlZCwgdmVyeSkgaGFwcHkg dG8gaGF2ZSB0aGlzIGF2YWlsYWJsZSB0byBtZSwgdGhvdWdoIGkgZG9uJ3QgdGhpbmsgaSdkIGFn cmVlIHdpdGggcXVpdGUgdGhlIHN0cmVuZ3RoIG9mIHlvdXIgc3RhdGVtZW50cyBhYm91dCBleHBv c2luZyBjb25maWd1cmF0aW9uIG9wdGlvbnMgdGhhdCBhcmVuJ3QgdXNlZCAoIm1pc2xlYWRpbmci LCAibm8gcG9pbnQiKS4gaSBkb24ndCBrbm93IHRoZSBhc3NlbWJsYWdlIGNvbmZpZ3VyYXRpb24g Zm9ybWF0IGF0IGFsbCwgYnV0IGlmIHRoZXJlIGFyZSAoYXMgc2VlbXMgY29tbW9uIHdpdGggb3Ro ZXIgZm9ybWF0cykgb3B0aW9ucyB0aGF0IGNhbiBvdmVycmlkZSBvciBpbnRlcmFjdCB3aXRoIGVh Y2ggb3RoZXIsIHRoZW4gc2VlaW5nIHdoYXRldmVyIGFyZSB0aGUgZGVmYXVsdCB2YWx1ZXMgcHJv dmlkZWQgZm9yIHRob3NlIG9wdGlvbnMgd2hlbiB0aGV5J3JlIG5vdCBleHBsaWNpdGx5IHVzZWQg aXMgcmF0aGVyIHVzZWZ1bC4gKHBhcnRpY3VsYXJseSBpZiB0aG9zZSBkZWZhdWx0cyBldmVyIGNo YW5nZS4pCj4+Cj4+IEFueXRoaW5nIHRoYXQgZXZlbnR1YWxseSBoYXMgYW4gaW1wYWN0IChlaXRo ZXIgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgd2lsbCBiZSBkb2N1bWVudGVkLiBEZXBlbmRlbmNp ZXMgYW1vbmcgY29uZmlndXJhdGlvbiBrZXlzIGFyZSB0cmFja2VkLgo+Cj4gb2ssIHRoYXQgc291 bmRzIGZhaXIuCj4KPj4+IHJlIDItLSB0aGlzIHNlZW1zIG1vcmUgb2YgYSB3b3JrZmxvdyB0aGlu ZyAoYW5kIHJlbWVtYmVyLCB0aGUgdXNlciBpcyBhbHdheXMgcmlnaHQgOykgLS0gY29tcGFyZSB0 aGUgdXRpbGl0eSBvZiAibWFuIGJhc2giIHRvICJtYW4gbWFrZSIgd2hlbiB3cml0aW5nIHNoZWxs IHNjcmlwdHMgdnMgbWFrZWZpbGVzLiAoYXQgbGVhc3Qgb24gYWxsIHN5c3RlbXMgaSd2ZSB1c2Vk IHJlY2VudGx5LikgaGF2aW5nIHRvIGdldCBob2xkIG9mIGEgYnJvd3NlciwgZ29vZ2xlIGZvciBn bnVtYWtlLCBmaW5kIHRoZSByaWdodCBnbnUub3JnIChodHRwOi8vZ251Lm9yZykgcGFnZSBhbmQg dGhlbiBzZWFyY2ggdGhyb3VnaCBpdCBpcyBhIHJveWFsIHBhaW4gKGV2ZW4gaWYgdGhlIGJhc2gg bWFuIHBhZ2UgaXMgaGFyZGx5IGFuIGV4ZW1wbGFyIG9mIGNsYXJpdHkgb3Igb3JnYW5pc2F0aW9u KS4KPj4gSW4gdGhpcyBjYXNlIHNpbmNlIHlvdSBhcmUgd3JpdGluZyBpbiBPQ2FtbCBhZ2FpbnN0 IGFuIE9DYW1sIEFQSSBzbyB5b3UgYXJlIGxlc3MgbGlrZWx5IHRvIGxvb2sgZm9yIGluZm9ybWF0 aW9uIGluIGEgbWFuIHBhZ2UgdGhhbiBpbiBvY2FtbGRvYyBnZW5lcmF0ZWQgZG9jdW1lbnRhdGlv biAodGhvdWdoIHN0cmljdGx5IHNwZWFraW5nIG9jYW1sZG9jIGhhcyBhLCBsaXR0bGUgdXNlZCwg bWFuIHBhZ2UgYmFja2VuZCkuIEFuZCBubyB0aGUgdXNlciBpcyBub3QgYWx3YXlzIHJpZ2h0LCB5 b3Ugc2hvdWxkIGNlcnRhaW5seSBuZXZlciBibGFtZSBpdCBmb3IgaXRzIGFjdGlvbnMgYnV0IHRo YXQgZG9lc24ndCBtZWFuIHRoYXQgaGUgaXMgYWx3YXlzIHJpZ2h0LCBpbiBmYWN0IGhlIGlzIG9m dGVuIHdyb25nIGVzcGVjaWFsbHkgaW4gd2hhdCBoZSB0aGlua3MgaGUgd2FudHMsIHRoYXQncyB0 aGUgcmVhc29uIHdoeSB3ZSBoYXZlIGRlc2lnbmVycy4KPgo+IHRoaXMgaXMgYSBwaGlsb3NvcGhp Y2FsIGRpc2N1c3Npb24gYmVzdCBoYWQgb3ZlciBhIHBpbnQgOikKPiAoaGFwcHkgZm9yIGRlc2ln bmVycyB0byBkZXNpZ24gdG9vbHM7IGJ1dCBteSB3b3JrZmxvd3MgYXJlIC0tIGdlbmVyYWxseSAt LSBteSBvd24uLi4pCj4KPiAtLQo+IENoZWVycywKPgo+IFIuCj4KPiBbIFRoaXMgYWRkcmVzcyBm YWlscyBvbiBEZWMzMS4gVXNlIHJpY2hhcmQubW9ydGllckBjbC5jYW0uYWMudWsgc3Vic2VxdWVu dGx5LiBdCj4KPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 14:05:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 14:05:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvRbc-0004ID-Eg; Mon, 01 Dec 2014 14:05:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvRba-0004I8-HJ for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:05:34 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id DD/4E-02954-DA57C745; Mon, 01 Dec 2014 14:05:33 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1417442732!12219479!1 X-Originating-IP: [209.85.212.181] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8042 invoked from network); 1 Dec 2014 14:05:32 -0000 Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com) (209.85.212.181) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 14:05:32 -0000 Received: by mail-wi0-f181.google.com with SMTP id r20so17478891wiv.2 for ; Mon, 01 Dec 2014 06:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vM6kHACa4bv3bFVV71G1eqxLKCd82wM1sWgSxjJZOZA=; b=WDvkc+RiDskNWettB8c6izttqPlKXojHfnnV/xCT2a2K6c0FSy3q/xD0evvWH4BS5a lWCPL96a8o380TnGWmgwOWQp+E5ocWeSDBhXT+LGvCtJBC/4KRyguSpXig0Af1Et8K1C zv7ewXsyrBDq6Ziji1V686tDbgIJtKJlcLIEQWmMF4VhnFGnBn2q/TAVvlQfwFVXsape SxYyjP6ZSGhTQkO0mLDkrra2IEjgLBK9/rpKchG65LB6ucwJPN/FYmOtfqhLm3EjkQVc d0Cp7Mqp3p50eC8qVaovHAVLUsD4ViQ24/8j3n8ddYBXRSy68XzZ86gBIyZJFFpEoEgb jhvQ== X-Received: by 10.194.174.40 with SMTP id bp8mr92104983wjc.104.1417442732622; Mon, 01 Dec 2014 06:05:32 -0800 (PST) Received: from ?IPv6:2001:630:212:248:4ef:3cf3:1c8b:2e9? ([2001:630:212:248:4ef:3cf3:1c8b:2e9]) by mx.google.com with ESMTPSA id rx8sm27719932wjb.30.2014.12.01.06.05.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 06:05:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Mon, 1 Dec 2014 14:05:26 +0000 Message-Id: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org PiBPbmUgY2FuIG9mIGNvdXJzZSwgbWFrZSB0aGUgbmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0 aGUgbmFtZSBvZiB0aGUKPiBwYXJhbWV0ZXIgd2l0aCB0aGUgbmFtZSBvZiB0aGUgQ09ORklHVVJB QkxFIChjdXJyZW50bHkKPiBzZW1pLWFsZ29yaXRobWljYWxseSBnZW5lcmF0ZWQgdG8ga2VlcCB0 aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90Cj4gc2VlbSB2ZXJ5IHVzZXIgZnJpZW5kbHku CgpNYXliZSBleHBvc2UgYSA/bmFtZSBwYXJhbWF0ZXIgdG8gYWxsIHRoZSBjb21iaW5hdG9ycyB3 aGljaCB3aWxsIGJlIHByZWZpeGVkIHRvIHBhcmFtZXRlciBhcmd1bWVudHMgaWYgbmVlZGVkLgoK VGhvbWFzCgoKPiAKPiBUaG91Z2h0cyA/Cj4gCj4gQ2hlZXJzLAo+IE5pY29sYXMKPiAKPiBQUzog Rm9yIHRob3NlIHRoYXQgd2FudCB0byBsb29rIGF0IHRoZSBjb2RlICh3aGljaCBpcyB2ZXJ5IHJv dWdoKQo+IGFuZC9vciB0cnkgaXQgb3V0LCB5b3UgY2FuIHBpbgo+IAo+IG9wYW0gcGluIGFkZCBt aXJhZ2UgaHR0cHM6Ly9naXRodWIuY29tL25vamIvbWlyYWdlI2JldHRlci1wYXJhbXMKPiAKPiBh bmQgeW91IGNhbiB0cnkgaXQgb3V0IGJ5IGNsb25pbmcKPiBodHRwczovL2dpdGh1Yi5jb20vbm9q Yi9taXJhZ2UtYmV0dGVyLXBhcmFtcy1leCBhbmQgcnVubmluZwo+IGBtaXJhZ2UgY29uZmlndXJl IC0taGVscGAuCj4gCj4gT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgMTA6NDkgUE0sIFJpY2hhcmQg TW9ydGllcgo+IDxSaWNoYXJkLk1vcnRpZXJAbm90dGluZ2hhbS5hYy51az4gd3JvdGU6Cj4+IAo+ PiBPbiAzMCBOb3YgMjAxNCwgYXQgMjI6NDAsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnps aUBlcnJhdGlxdWUuY2g+IHdyb3RlOgo+PiAKPj4+IAo+Pj4gCj4+PiBMZSBkaW1hbmNoZSwgMzAg bm92ZW1icmUgMjAxNCDDoCAyMzowMywgUmljaGFyZCBNb3J0aWVyIGEgw6ljcml0IDoKPj4+IAo+ Pj4+IHJlIDEtLSBpJ20gcXVpdGUgKGluZGVlZCwgdmVyeSkgaGFwcHkgdG8gaGF2ZSB0aGlzIGF2 YWlsYWJsZSB0byBtZSwgdGhvdWdoIGkgZG9uJ3QgdGhpbmsgaSdkIGFncmVlIHdpdGggcXVpdGUg dGhlIHN0cmVuZ3RoIG9mIHlvdXIgc3RhdGVtZW50cyBhYm91dCBleHBvc2luZyBjb25maWd1cmF0 aW9uIG9wdGlvbnMgdGhhdCBhcmVuJ3QgdXNlZCAoIm1pc2xlYWRpbmciLCAibm8gcG9pbnQiKS4g aSBkb24ndCBrbm93IHRoZSBhc3NlbWJsYWdlIGNvbmZpZ3VyYXRpb24gZm9ybWF0IGF0IGFsbCwg YnV0IGlmIHRoZXJlIGFyZSAoYXMgc2VlbXMgY29tbW9uIHdpdGggb3RoZXIgZm9ybWF0cykgb3B0 aW9ucyB0aGF0IGNhbiBvdmVycmlkZSBvciBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIsIHRoZW4g c2VlaW5nIHdoYXRldmVyIGFyZSB0aGUgZGVmYXVsdCB2YWx1ZXMgcHJvdmlkZWQgZm9yIHRob3Nl IG9wdGlvbnMgd2hlbiB0aGV5J3JlIG5vdCBleHBsaWNpdGx5IHVzZWQgaXMgcmF0aGVyIHVzZWZ1 bC4gKHBhcnRpY3VsYXJseSBpZiB0aG9zZSBkZWZhdWx0cyBldmVyIGNoYW5nZS4pCj4+PiAKPj4+ IEFueXRoaW5nIHRoYXQgZXZlbnR1YWxseSBoYXMgYW4gaW1wYWN0IChlaXRoZXIgZGlyZWN0bHkg b3IgaW5kaXJlY3RseSkgd2lsbCBiZSBkb2N1bWVudGVkLiBEZXBlbmRlbmNpZXMgYW1vbmcgY29u ZmlndXJhdGlvbiBrZXlzIGFyZSB0cmFja2VkLgo+PiAKPj4gb2ssIHRoYXQgc291bmRzIGZhaXIu Cj4+IAo+Pj4+IHJlIDItLSB0aGlzIHNlZW1zIG1vcmUgb2YgYSB3b3JrZmxvdyB0aGluZyAoYW5k IHJlbWVtYmVyLCB0aGUgdXNlciBpcyBhbHdheXMgcmlnaHQgOykgLS0gY29tcGFyZSB0aGUgdXRp bGl0eSBvZiAibWFuIGJhc2giIHRvICJtYW4gbWFrZSIgd2hlbiB3cml0aW5nIHNoZWxsIHNjcmlw dHMgdnMgbWFrZWZpbGVzLiAoYXQgbGVhc3Qgb24gYWxsIHN5c3RlbXMgaSd2ZSB1c2VkIHJlY2Vu dGx5LikgaGF2aW5nIHRvIGdldCBob2xkIG9mIGEgYnJvd3NlciwgZ29vZ2xlIGZvciBnbnVtYWtl LCBmaW5kIHRoZSByaWdodCBnbnUub3JnIChodHRwOi8vZ251Lm9yZykgcGFnZSBhbmQgdGhlbiBz ZWFyY2ggdGhyb3VnaCBpdCBpcyBhIHJveWFsIHBhaW4gKGV2ZW4gaWYgdGhlIGJhc2ggbWFuIHBh Z2UgaXMgaGFyZGx5IGFuIGV4ZW1wbGFyIG9mIGNsYXJpdHkgb3Igb3JnYW5pc2F0aW9uKS4KPj4+ IEluIHRoaXMgY2FzZSBzaW5jZSB5b3UgYXJlIHdyaXRpbmcgaW4gT0NhbWwgYWdhaW5zdCBhbiBP Q2FtbCBBUEkgc28geW91IGFyZSBsZXNzIGxpa2VseSB0byBsb29rIGZvciBpbmZvcm1hdGlvbiBp biBhIG1hbiBwYWdlIHRoYW4gaW4gb2NhbWxkb2MgZ2VuZXJhdGVkIGRvY3VtZW50YXRpb24gKHRo b3VnaCBzdHJpY3RseSBzcGVha2luZyBvY2FtbGRvYyBoYXMgYSwgbGl0dGxlIHVzZWQsIG1hbiBw YWdlIGJhY2tlbmQpLiBBbmQgbm8gdGhlIHVzZXIgaXMgbm90IGFsd2F5cyByaWdodCwgeW91IHNo b3VsZCBjZXJ0YWlubHkgbmV2ZXIgYmxhbWUgaXQgZm9yIGl0cyBhY3Rpb25zIGJ1dCB0aGF0IGRv ZXNuJ3QgbWVhbiB0aGF0IGhlIGlzIGFsd2F5cyByaWdodCwgaW4gZmFjdCBoZSBpcyBvZnRlbiB3 cm9uZyBlc3BlY2lhbGx5IGluIHdoYXQgaGUgdGhpbmtzIGhlIHdhbnRzLCB0aGF0J3MgdGhlIHJl YXNvbiB3aHkgd2UgaGF2ZSBkZXNpZ25lcnMuCj4+IAo+PiB0aGlzIGlzIGEgcGhpbG9zb3BoaWNh bCBkaXNjdXNzaW9uIGJlc3QgaGFkIG92ZXIgYSBwaW50IDopCj4+IChoYXBweSBmb3IgZGVzaWdu ZXJzIHRvIGRlc2lnbiB0b29sczsgYnV0IG15IHdvcmtmbG93cyBhcmUgLS0gZ2VuZXJhbGx5IC0t IG15IG93bi4uLikKPj4gCj4+IC0tCj4+IENoZWVycywKPj4gCj4+IFIuCj4+IAo+PiBbIFRoaXMg YWRkcmVzcyBmYWlscyBvbiBEZWMzMS4gVXNlIHJpY2hhcmQubW9ydGllckBjbC5jYW0uYWMudWsg c3Vic2VxdWVudGx5LiBdCj4+IAo+PiAKPj4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9j Z2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 14:05:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 14:05:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvRbc-0004ID-Eg; Mon, 01 Dec 2014 14:05:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvRba-0004I8-HJ for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:05:34 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id DD/4E-02954-DA57C745; Mon, 01 Dec 2014 14:05:33 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1417442732!12219479!1 X-Originating-IP: [209.85.212.181] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8042 invoked from network); 1 Dec 2014 14:05:32 -0000 Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com) (209.85.212.181) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 14:05:32 -0000 Received: by mail-wi0-f181.google.com with SMTP id r20so17478891wiv.2 for ; Mon, 01 Dec 2014 06:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vM6kHACa4bv3bFVV71G1eqxLKCd82wM1sWgSxjJZOZA=; b=WDvkc+RiDskNWettB8c6izttqPlKXojHfnnV/xCT2a2K6c0FSy3q/xD0evvWH4BS5a lWCPL96a8o380TnGWmgwOWQp+E5ocWeSDBhXT+LGvCtJBC/4KRyguSpXig0Af1Et8K1C zv7ewXsyrBDq6Ziji1V686tDbgIJtKJlcLIEQWmMF4VhnFGnBn2q/TAVvlQfwFVXsape SxYyjP6ZSGhTQkO0mLDkrra2IEjgLBK9/rpKchG65LB6ucwJPN/FYmOtfqhLm3EjkQVc d0Cp7Mqp3p50eC8qVaovHAVLUsD4ViQ24/8j3n8ddYBXRSy68XzZ86gBIyZJFFpEoEgb jhvQ== X-Received: by 10.194.174.40 with SMTP id bp8mr92104983wjc.104.1417442732622; Mon, 01 Dec 2014 06:05:32 -0800 (PST) Received: from ?IPv6:2001:630:212:248:4ef:3cf3:1c8b:2e9? ([2001:630:212:248:4ef:3cf3:1c8b:2e9]) by mx.google.com with ESMTPSA id rx8sm27719932wjb.30.2014.12.01.06.05.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 06:05:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Mon, 1 Dec 2014 14:05:26 +0000 Message-Id: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org PiBPbmUgY2FuIG9mIGNvdXJzZSwgbWFrZSB0aGUgbmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0 aGUgbmFtZSBvZiB0aGUKPiBwYXJhbWV0ZXIgd2l0aCB0aGUgbmFtZSBvZiB0aGUgQ09ORklHVVJB QkxFIChjdXJyZW50bHkKPiBzZW1pLWFsZ29yaXRobWljYWxseSBnZW5lcmF0ZWQgdG8ga2VlcCB0 aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90Cj4gc2VlbSB2ZXJ5IHVzZXIgZnJpZW5kbHku CgpNYXliZSBleHBvc2UgYSA/bmFtZSBwYXJhbWF0ZXIgdG8gYWxsIHRoZSBjb21iaW5hdG9ycyB3 aGljaCB3aWxsIGJlIHByZWZpeGVkIHRvIHBhcmFtZXRlciBhcmd1bWVudHMgaWYgbmVlZGVkLgoK VGhvbWFzCgoKPiAKPiBUaG91Z2h0cyA/Cj4gCj4gQ2hlZXJzLAo+IE5pY29sYXMKPiAKPiBQUzog Rm9yIHRob3NlIHRoYXQgd2FudCB0byBsb29rIGF0IHRoZSBjb2RlICh3aGljaCBpcyB2ZXJ5IHJv dWdoKQo+IGFuZC9vciB0cnkgaXQgb3V0LCB5b3UgY2FuIHBpbgo+IAo+IG9wYW0gcGluIGFkZCBt aXJhZ2UgaHR0cHM6Ly9naXRodWIuY29tL25vamIvbWlyYWdlI2JldHRlci1wYXJhbXMKPiAKPiBh bmQgeW91IGNhbiB0cnkgaXQgb3V0IGJ5IGNsb25pbmcKPiBodHRwczovL2dpdGh1Yi5jb20vbm9q Yi9taXJhZ2UtYmV0dGVyLXBhcmFtcy1leCBhbmQgcnVubmluZwo+IGBtaXJhZ2UgY29uZmlndXJl IC0taGVscGAuCj4gCj4gT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgMTA6NDkgUE0sIFJpY2hhcmQg TW9ydGllcgo+IDxSaWNoYXJkLk1vcnRpZXJAbm90dGluZ2hhbS5hYy51az4gd3JvdGU6Cj4+IAo+ PiBPbiAzMCBOb3YgMjAxNCwgYXQgMjI6NDAsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnps aUBlcnJhdGlxdWUuY2g+IHdyb3RlOgo+PiAKPj4+IAo+Pj4gCj4+PiBMZSBkaW1hbmNoZSwgMzAg bm92ZW1icmUgMjAxNCDDoCAyMzowMywgUmljaGFyZCBNb3J0aWVyIGEgw6ljcml0IDoKPj4+IAo+ Pj4+IHJlIDEtLSBpJ20gcXVpdGUgKGluZGVlZCwgdmVyeSkgaGFwcHkgdG8gaGF2ZSB0aGlzIGF2 YWlsYWJsZSB0byBtZSwgdGhvdWdoIGkgZG9uJ3QgdGhpbmsgaSdkIGFncmVlIHdpdGggcXVpdGUg dGhlIHN0cmVuZ3RoIG9mIHlvdXIgc3RhdGVtZW50cyBhYm91dCBleHBvc2luZyBjb25maWd1cmF0 aW9uIG9wdGlvbnMgdGhhdCBhcmVuJ3QgdXNlZCAoIm1pc2xlYWRpbmciLCAibm8gcG9pbnQiKS4g aSBkb24ndCBrbm93IHRoZSBhc3NlbWJsYWdlIGNvbmZpZ3VyYXRpb24gZm9ybWF0IGF0IGFsbCwg YnV0IGlmIHRoZXJlIGFyZSAoYXMgc2VlbXMgY29tbW9uIHdpdGggb3RoZXIgZm9ybWF0cykgb3B0 aW9ucyB0aGF0IGNhbiBvdmVycmlkZSBvciBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIsIHRoZW4g c2VlaW5nIHdoYXRldmVyIGFyZSB0aGUgZGVmYXVsdCB2YWx1ZXMgcHJvdmlkZWQgZm9yIHRob3Nl IG9wdGlvbnMgd2hlbiB0aGV5J3JlIG5vdCBleHBsaWNpdGx5IHVzZWQgaXMgcmF0aGVyIHVzZWZ1 bC4gKHBhcnRpY3VsYXJseSBpZiB0aG9zZSBkZWZhdWx0cyBldmVyIGNoYW5nZS4pCj4+PiAKPj4+ IEFueXRoaW5nIHRoYXQgZXZlbnR1YWxseSBoYXMgYW4gaW1wYWN0IChlaXRoZXIgZGlyZWN0bHkg b3IgaW5kaXJlY3RseSkgd2lsbCBiZSBkb2N1bWVudGVkLiBEZXBlbmRlbmNpZXMgYW1vbmcgY29u ZmlndXJhdGlvbiBrZXlzIGFyZSB0cmFja2VkLgo+PiAKPj4gb2ssIHRoYXQgc291bmRzIGZhaXIu Cj4+IAo+Pj4+IHJlIDItLSB0aGlzIHNlZW1zIG1vcmUgb2YgYSB3b3JrZmxvdyB0aGluZyAoYW5k IHJlbWVtYmVyLCB0aGUgdXNlciBpcyBhbHdheXMgcmlnaHQgOykgLS0gY29tcGFyZSB0aGUgdXRp bGl0eSBvZiAibWFuIGJhc2giIHRvICJtYW4gbWFrZSIgd2hlbiB3cml0aW5nIHNoZWxsIHNjcmlw dHMgdnMgbWFrZWZpbGVzLiAoYXQgbGVhc3Qgb24gYWxsIHN5c3RlbXMgaSd2ZSB1c2VkIHJlY2Vu dGx5LikgaGF2aW5nIHRvIGdldCBob2xkIG9mIGEgYnJvd3NlciwgZ29vZ2xlIGZvciBnbnVtYWtl LCBmaW5kIHRoZSByaWdodCBnbnUub3JnIChodHRwOi8vZ251Lm9yZykgcGFnZSBhbmQgdGhlbiBz ZWFyY2ggdGhyb3VnaCBpdCBpcyBhIHJveWFsIHBhaW4gKGV2ZW4gaWYgdGhlIGJhc2ggbWFuIHBh Z2UgaXMgaGFyZGx5IGFuIGV4ZW1wbGFyIG9mIGNsYXJpdHkgb3Igb3JnYW5pc2F0aW9uKS4KPj4+ IEluIHRoaXMgY2FzZSBzaW5jZSB5b3UgYXJlIHdyaXRpbmcgaW4gT0NhbWwgYWdhaW5zdCBhbiBP Q2FtbCBBUEkgc28geW91IGFyZSBsZXNzIGxpa2VseSB0byBsb29rIGZvciBpbmZvcm1hdGlvbiBp biBhIG1hbiBwYWdlIHRoYW4gaW4gb2NhbWxkb2MgZ2VuZXJhdGVkIGRvY3VtZW50YXRpb24gKHRo b3VnaCBzdHJpY3RseSBzcGVha2luZyBvY2FtbGRvYyBoYXMgYSwgbGl0dGxlIHVzZWQsIG1hbiBw YWdlIGJhY2tlbmQpLiBBbmQgbm8gdGhlIHVzZXIgaXMgbm90IGFsd2F5cyByaWdodCwgeW91IHNo b3VsZCBjZXJ0YWlubHkgbmV2ZXIgYmxhbWUgaXQgZm9yIGl0cyBhY3Rpb25zIGJ1dCB0aGF0IGRv ZXNuJ3QgbWVhbiB0aGF0IGhlIGlzIGFsd2F5cyByaWdodCwgaW4gZmFjdCBoZSBpcyBvZnRlbiB3 cm9uZyBlc3BlY2lhbGx5IGluIHdoYXQgaGUgdGhpbmtzIGhlIHdhbnRzLCB0aGF0J3MgdGhlIHJl YXNvbiB3aHkgd2UgaGF2ZSBkZXNpZ25lcnMuCj4+IAo+PiB0aGlzIGlzIGEgcGhpbG9zb3BoaWNh bCBkaXNjdXNzaW9uIGJlc3QgaGFkIG92ZXIgYSBwaW50IDopCj4+IChoYXBweSBmb3IgZGVzaWdu ZXJzIHRvIGRlc2lnbiB0b29sczsgYnV0IG15IHdvcmtmbG93cyBhcmUgLS0gZ2VuZXJhbGx5IC0t IG15IG93bi4uLikKPj4gCj4+IC0tCj4+IENoZWVycywKPj4gCj4+IFIuCj4+IAo+PiBbIFRoaXMg YWRkcmVzcyBmYWlscyBvbiBEZWMzMS4gVXNlIHJpY2hhcmQubW9ydGllckBjbC5jYW0uYWMudWsg c3Vic2VxdWVudGx5LiBdCj4+IAo+PiAKPj4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9j Z2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 14:32:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 14:32:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvS1P-0005QX-HC; Mon, 01 Dec 2014 14:32:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvS1N-0005QS-TR for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:32:14 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 8A/F6-24859-DEB7C745; Mon, 01 Dec 2014 14:32:13 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-5.tower-31.messagelabs.com!1417444317!15068682!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20844 invoked from network); 1 Dec 2014 14:31:57 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-5.tower-31.messagelabs.com with SMTP; 1 Dec 2014 14:31:57 -0000 Received: from [172.20.10.2] (33-237.197-178.cust.bluewin.ch [178.197.237.33]) by smtp.webfaction.com (Postfix) with ESMTP id A37BD208F22D; Mon, 1 Dec 2014 14:31:55 +0000 (UTC) Date: Mon, 1 Dec 2014 15:31:54 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Gazagnaire Message-ID: In-Reply-To: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Nicolas Ojeda Bar , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org CgpMZSBsdW5kaSwgMSBkw6ljZW1icmUgMjAxNCDDoCAxNTowNSwgVGhvbWFzIEdhemFnbmFpcmUg YSDDqWNyaXQgOgoKPiA+IE9uZSBjYW4gb2YgY291cnNlLCBtYWtlIHRoZSBuYW1lcyB1bmlxdWUg YnkgY29tYmluaW5nIHRoZSBuYW1lIG9mIHRoZQo+ID4gcGFyYW1ldGVyIHdpdGggdGhlIG5hbWUg b2YgdGhlIENPTkZJR1VSQUJMRSAoY3VycmVudGx5Cj4gPiBzZW1pLWFsZ29yaXRobWljYWxseSBn ZW5lcmF0ZWQgdG8ga2VlcCB0aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90Cj4gPiBzZWVt IHZlcnkgdXNlciBmcmllbmRseS4KPiAgCj4gTWF5YmUgZXhwb3NlIGEgP25hbWUgcGFyYW1hdGVy IHRvIGFsbCB0aGUgY29tYmluYXRvcnMgd2hpY2ggd2lsbCBiZSBwcmVmaXhlZCB0byBwYXJhbWV0 ZXIgYXJndW1lbnRzIGlmIG5lZWRlZC4KCkknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0u IElmIEkgdW5kZXJzdG9vZCB3ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBk b2VzIGdlbmVyYXRlIG5ldyBjb25maWd1cmF0aW9uIHZhbHVlcy4gIAoKT2YgY291cnNlIGlmIHRo ZXkgYXJlIG1lYW50IHRvIGJlIHNoYXJlZCBhbW9uZyBpbnN0YW5jZXMgaXQgbWVhbnMgdGhhdCB5 b3UgYXJlIGRlY2xhcmluZyB0aGVtIGF0IHRoZSB3cm9uZyBwbGFjZS4gQmVzdCB3b3VsZCBiZSB0 byBkZWZpbmUgYSBtb2R1bGUgd2l0aCAic3RhbmRhcmQiIGNvbmZpZ3VyYXRpb24ga2V5cyAoZS5n LiBpcCBhZGRyZXNzKSB0byBiZSB1c2VkIHRvIGJlIHVzZWQgdGhyb3VnaG91dCB0aGUgc3lzdGVt IGFuZCB0ZWxsaW5nIHVzZXJzIHRvIGZpcnN0IHRyeSB0byB1c2UgdGhlIHN0YW5kYXJkIGNvbmZp Z3VyYXRpb24ga2V5cyBiZWZvcmUgdHJ5aW5nIHRvIGRlZmluZSBuZXcgb25lcy4gIAoKTm93IHRo ZSBxdWVzdGlvbiBhbmQgcHJvYmxlbSByZW1haW5zIHdoZXRoZXIgdGhlcmUgd291bGQgYmUgdGhl IG5lZWQgZm9yIHBlciBtb2R1bGUgaW5zdGFuY2lhdGlvbiBjb25maWd1cmF0aW9uIGtleXMuIElu IHRoYXQgY2FzZSBpdCBzZWVtcyB0aGF0IHdoYXQgVGhvbWFzIGlzIHByb3Bvc2luZyBpcyB0aGUg Z29vZCBhbnN3ZXIsIHRoZSBtb2R1bGUgcGFyYW1ldGVyIHNob3VsZCB0aGVuIHByb3ZpZGUgYSBg dmFsIG5hbWUgOiBzdHJpbmdgIGluIHRoZSBzaWduYXR1cmUgdGhhdCB5b3UgdGhyZWFkIGluIHRo ZSByZXN1bHRpbmcgbW9kdWxlIHVzaW5nIHRoYXQgYD9uYW1lYCBwYXJhbWV0ZXIgd2hlbiBpdCBj cmVhdGVzIGl0cyBvd24ga2V5cy4KCkJlc3QsCgpEYW5pZWwKClAuUy4gSXQgd291bGQgYmUgbmlj ZSB0byBwcm92aWRlIG1vcmUgc3BlY2lmaWMgbGlua3Mgd2hlbiB5b3UgYXNrIGZvciBmZWVkYmFj aywgb2YgaW50ZXJlc3QgaGVyZSB3b3VsZCBiZSB0aGUgQVBJIGFuZCB0aGUgd2F5IGl0IGdldHMg dXNlZCBpbiB0aGUgY29kZS4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxp c3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21h aWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 14:32:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 14:32:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvS1P-0005QX-HC; Mon, 01 Dec 2014 14:32:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvS1N-0005QS-TR for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 14:32:14 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 8A/F6-24859-DEB7C745; Mon, 01 Dec 2014 14:32:13 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-5.tower-31.messagelabs.com!1417444317!15068682!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20844 invoked from network); 1 Dec 2014 14:31:57 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-5.tower-31.messagelabs.com with SMTP; 1 Dec 2014 14:31:57 -0000 Received: from [172.20.10.2] (33-237.197-178.cust.bluewin.ch [178.197.237.33]) by smtp.webfaction.com (Postfix) with ESMTP id A37BD208F22D; Mon, 1 Dec 2014 14:31:55 +0000 (UTC) Date: Mon, 1 Dec 2014 15:31:54 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Gazagnaire Message-ID: In-Reply-To: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Nicolas Ojeda Bar , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org CgpMZSBsdW5kaSwgMSBkw6ljZW1icmUgMjAxNCDDoCAxNTowNSwgVGhvbWFzIEdhemFnbmFpcmUg YSDDqWNyaXQgOgoKPiA+IE9uZSBjYW4gb2YgY291cnNlLCBtYWtlIHRoZSBuYW1lcyB1bmlxdWUg YnkgY29tYmluaW5nIHRoZSBuYW1lIG9mIHRoZQo+ID4gcGFyYW1ldGVyIHdpdGggdGhlIG5hbWUg b2YgdGhlIENPTkZJR1VSQUJMRSAoY3VycmVudGx5Cj4gPiBzZW1pLWFsZ29yaXRobWljYWxseSBn ZW5lcmF0ZWQgdG8ga2VlcCB0aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90Cj4gPiBzZWVt IHZlcnkgdXNlciBmcmllbmRseS4KPiAgCj4gTWF5YmUgZXhwb3NlIGEgP25hbWUgcGFyYW1hdGVy IHRvIGFsbCB0aGUgY29tYmluYXRvcnMgd2hpY2ggd2lsbCBiZSBwcmVmaXhlZCB0byBwYXJhbWV0 ZXIgYXJndW1lbnRzIGlmIG5lZWRlZC4KCkknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0u IElmIEkgdW5kZXJzdG9vZCB3ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBk b2VzIGdlbmVyYXRlIG5ldyBjb25maWd1cmF0aW9uIHZhbHVlcy4gIAoKT2YgY291cnNlIGlmIHRo ZXkgYXJlIG1lYW50IHRvIGJlIHNoYXJlZCBhbW9uZyBpbnN0YW5jZXMgaXQgbWVhbnMgdGhhdCB5 b3UgYXJlIGRlY2xhcmluZyB0aGVtIGF0IHRoZSB3cm9uZyBwbGFjZS4gQmVzdCB3b3VsZCBiZSB0 byBkZWZpbmUgYSBtb2R1bGUgd2l0aCAic3RhbmRhcmQiIGNvbmZpZ3VyYXRpb24ga2V5cyAoZS5n LiBpcCBhZGRyZXNzKSB0byBiZSB1c2VkIHRvIGJlIHVzZWQgdGhyb3VnaG91dCB0aGUgc3lzdGVt IGFuZCB0ZWxsaW5nIHVzZXJzIHRvIGZpcnN0IHRyeSB0byB1c2UgdGhlIHN0YW5kYXJkIGNvbmZp Z3VyYXRpb24ga2V5cyBiZWZvcmUgdHJ5aW5nIHRvIGRlZmluZSBuZXcgb25lcy4gIAoKTm93IHRo ZSBxdWVzdGlvbiBhbmQgcHJvYmxlbSByZW1haW5zIHdoZXRoZXIgdGhlcmUgd291bGQgYmUgdGhl IG5lZWQgZm9yIHBlciBtb2R1bGUgaW5zdGFuY2lhdGlvbiBjb25maWd1cmF0aW9uIGtleXMuIElu IHRoYXQgY2FzZSBpdCBzZWVtcyB0aGF0IHdoYXQgVGhvbWFzIGlzIHByb3Bvc2luZyBpcyB0aGUg Z29vZCBhbnN3ZXIsIHRoZSBtb2R1bGUgcGFyYW1ldGVyIHNob3VsZCB0aGVuIHByb3ZpZGUgYSBg dmFsIG5hbWUgOiBzdHJpbmdgIGluIHRoZSBzaWduYXR1cmUgdGhhdCB5b3UgdGhyZWFkIGluIHRo ZSByZXN1bHRpbmcgbW9kdWxlIHVzaW5nIHRoYXQgYD9uYW1lYCBwYXJhbWV0ZXIgd2hlbiBpdCBj cmVhdGVzIGl0cyBvd24ga2V5cy4KCkJlc3QsCgpEYW5pZWwKClAuUy4gSXQgd291bGQgYmUgbmlj ZSB0byBwcm92aWRlIG1vcmUgc3BlY2lmaWMgbGlua3Mgd2hlbiB5b3UgYXNrIGZvciBmZWVkYmFj aywgb2YgaW50ZXJlc3QgaGVyZSB3b3VsZCBiZSB0aGUgQVBJIGFuZCB0aGUgd2F5IGl0IGdldHMg dXNlZCBpbiB0aGUgY29kZS4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxp c3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21h aWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 21:06:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 21:06:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYAe-0003dT-MF; Mon, 01 Dec 2014 21:06:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYAd-0003dO-G1 for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 21:06:11 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 61/8E-25714-248DC745; Mon, 01 Dec 2014 21:06:10 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-206.messagelabs.com!1417467969!6796274!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25898 invoked from network); 1 Dec 2014 21:06:10 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Dec 2014 21:06:10 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id eb0dcc4e; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Mon, 1 Dec 2014 21:11:11 +0000 (GMT) From: Anil Madhavapeddy Message-Id: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> Date: Mon, 1 Dec 2014 21:06:07 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi, One annoyance to using Mirage on MacOS X has always been the lack of network bridging, which means that the network stack couldn't communicate with the outside world. In Yosemite, a mysterious `vmnet` framework appeared that does support bridging, and so I've created an alternative to the tuntap module which works great. Using it, I can easily spawn network applications that can make external Internet queries using the OCaml network stack from Unix. I could use a sanity test from someone else running Yosemite first before I release this. If you are on an older MacOS X, then you will need to pass `--no-macosx` to the Mirage CLI to not use the new packages and use the old tuntap module. - `opam update` so you have the `vmnet` and `mirage-net-macos` packages (merged upstream today) - `opam pin add mirage git://github.com/mirage/mirage` to get the 2.0.2 working tree. - Try this mirage-skeleton example https://github.com/mirage/mirage-skeleton/pull/58 (using `DHCP=1 mirage configure`) - Report back to this thread :) For CHANGES in Mirage 2.0.2 see: https://github.com/mirage/mirage/blob/master/CHANGES -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 21:06:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 21:06:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYAe-0003dT-MF; Mon, 01 Dec 2014 21:06:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYAd-0003dO-G1 for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 21:06:11 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 61/8E-25714-248DC745; Mon, 01 Dec 2014 21:06:10 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-206.messagelabs.com!1417467969!6796274!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25898 invoked from network); 1 Dec 2014 21:06:10 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Dec 2014 21:06:10 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id eb0dcc4e; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Mon, 1 Dec 2014 21:11:11 +0000 (GMT) From: Anil Madhavapeddy Message-Id: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> Date: Mon, 1 Dec 2014 21:06:07 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi, One annoyance to using Mirage on MacOS X has always been the lack of network bridging, which means that the network stack couldn't communicate with the outside world. In Yosemite, a mysterious `vmnet` framework appeared that does support bridging, and so I've created an alternative to the tuntap module which works great. Using it, I can easily spawn network applications that can make external Internet queries using the OCaml network stack from Unix. I could use a sanity test from someone else running Yosemite first before I release this. If you are on an older MacOS X, then you will need to pass `--no-macosx` to the Mirage CLI to not use the new packages and use the old tuntap module. - `opam update` so you have the `vmnet` and `mirage-net-macos` packages (merged upstream today) - `opam pin add mirage git://github.com/mirage/mirage` to get the 2.0.2 working tree. - Try this mirage-skeleton example https://github.com/mirage/mirage-skeleton/pull/58 (using `DHCP=1 mirage configure`) - Report back to this thread :) For CHANGES in Mirage 2.0.2 see: https://github.com/mirage/mirage/blob/master/CHANGES -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 21:42:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 21:42:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYjx-0004KP-G2; Mon, 01 Dec 2014 21:42:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYjv-0004KK-Nz for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 21:42:39 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 91/C1-28296-DC0EC745; Mon, 01 Dec 2014 21:42:37 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1417470157!15076658!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12267 invoked from network); 1 Dec 2014 21:42:37 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 21:42:37 -0000 Received: by mail-wi0-f171.google.com with SMTP id bs8so26055243wib.16 for ; Mon, 01 Dec 2014 13:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=eLb91R/Ly1Db1Ern0we/oomN/3BMl693IMrHcIhdLAs=; b=crkArsY52SsucyzrXNqcyOZIhyPS/mpogODbds0zUc1IuTQu5eP/ometMZFmpP/v5j IpedWb/igP5cNrVQJjw5vcqtCmPkh3peT/BnHvL8oD+YhttN7wr996MiOVPJJQJKKWU7 0zWWoIrMyS4J2Na7Pan4rTrz5VAcwpMuRNc/OBOKZPNzbvN/qKkaKoi2UbQMwsL16QTJ 6ppU/n5KzuTzJ1zkZnZCltj54wXFeGSax4TLN3CGuMItDwT17t301XuqQyExZdN5Ydqf KZpTqrHEwPUb8/4bR9bne1z0VDNyupALH/0u2Bj3VLZG1pYaml1MLJPqdNIzxX+WEHvA +ang== MIME-Version: 1.0 X-Received: by 10.180.23.98 with SMTP id l2mr87035664wif.51.1417470156758; Mon, 01 Dec 2014 13:42:36 -0800 (PST) Received: by 10.27.171.146 with HTTP; Mon, 1 Dec 2014 13:42:36 -0800 (PST) In-Reply-To: References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> Date: Mon, 1 Dec 2014 21:42:36 +0000 X-Google-Sender-Auth: ivskw2at5__OYblysy95RQSFgvE Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Fwd: MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org ---------- Forwarded message ---------- From: Nicolas Ojeda Bar Date: Mon, Dec 1, 2014 at 9:42 PM Subject: Re: [MirageOS-devel] MacOS X vmnet support To: Anil Madhavapeddy Yes, it works! Just a couple of remarks: - `vmnet` and `mirage-net-macosx` (not the x at the end) do not seem to have trickled in to the default http opam repo yet. - make sure to run the example under sudo, otherwise the unikernel just seems to hang without any output Thanks for this, it's great. Best wishes, Nicolas On Mon, Dec 1, 2014 at 9:06 PM, Anil Madhavapeddy wrote: > Hi, > > One annoyance to using Mirage on MacOS X has always been the lack of network bridging, which means that the network stack couldn't communicate with the outside world. > > In Yosemite, a mysterious `vmnet` framework appeared that does support bridging, and so I've created an alternative to the tuntap module which works great. Using it, I can easily spawn network applications that can make external Internet queries using the OCaml network stack from Unix. > > I could use a sanity test from someone else running Yosemite first before I release this. If you are on an older MacOS X, then you will need to pass `--no-macosx` to the Mirage CLI to not use the new packages and use the old tuntap module. > > - `opam update` so you have the `vmnet` and `mirage-net-macos` packages (merged upstream today) > - `opam pin add mirage git://github.com/mirage/mirage` to get the 2.0.2 working tree. > - Try this mirage-skeleton example https://github.com/mirage/mirage-skeleton/pull/58 (using `DHCP=1 mirage configure`) > - Report back to this thread :) > > For CHANGES in Mirage 2.0.2 see: https://github.com/mirage/mirage/blob/master/CHANGES > > -anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 01 21:42:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 01 Dec 2014 21:42:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYjx-0004KP-G2; Mon, 01 Dec 2014 21:42:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvYjv-0004KK-Nz for mirageos-devel@lists.xenproject.org; Mon, 01 Dec 2014 21:42:39 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 91/C1-28296-DC0EC745; Mon, 01 Dec 2014 21:42:37 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1417470157!15076658!1 X-Originating-IP: [209.85.212.171] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12267 invoked from network); 1 Dec 2014 21:42:37 -0000 Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2014 21:42:37 -0000 Received: by mail-wi0-f171.google.com with SMTP id bs8so26055243wib.16 for ; Mon, 01 Dec 2014 13:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=eLb91R/Ly1Db1Ern0we/oomN/3BMl693IMrHcIhdLAs=; b=crkArsY52SsucyzrXNqcyOZIhyPS/mpogODbds0zUc1IuTQu5eP/ometMZFmpP/v5j IpedWb/igP5cNrVQJjw5vcqtCmPkh3peT/BnHvL8oD+YhttN7wr996MiOVPJJQJKKWU7 0zWWoIrMyS4J2Na7Pan4rTrz5VAcwpMuRNc/OBOKZPNzbvN/qKkaKoi2UbQMwsL16QTJ 6ppU/n5KzuTzJ1zkZnZCltj54wXFeGSax4TLN3CGuMItDwT17t301XuqQyExZdN5Ydqf KZpTqrHEwPUb8/4bR9bne1z0VDNyupALH/0u2Bj3VLZG1pYaml1MLJPqdNIzxX+WEHvA +ang== MIME-Version: 1.0 X-Received: by 10.180.23.98 with SMTP id l2mr87035664wif.51.1417470156758; Mon, 01 Dec 2014 13:42:36 -0800 (PST) Received: by 10.27.171.146 with HTTP; Mon, 1 Dec 2014 13:42:36 -0800 (PST) In-Reply-To: References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> Date: Mon, 1 Dec 2014 21:42:36 +0000 X-Google-Sender-Auth: ivskw2at5__OYblysy95RQSFgvE Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Fwd: MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org ---------- Forwarded message ---------- From: Nicolas Ojeda Bar Date: Mon, Dec 1, 2014 at 9:42 PM Subject: Re: [MirageOS-devel] MacOS X vmnet support To: Anil Madhavapeddy Yes, it works! Just a couple of remarks: - `vmnet` and `mirage-net-macosx` (not the x at the end) do not seem to have trickled in to the default http opam repo yet. - make sure to run the example under sudo, otherwise the unikernel just seems to hang without any output Thanks for this, it's great. Best wishes, Nicolas On Mon, Dec 1, 2014 at 9:06 PM, Anil Madhavapeddy wrote: > Hi, > > One annoyance to using Mirage on MacOS X has always been the lack of network bridging, which means that the network stack couldn't communicate with the outside world. > > In Yosemite, a mysterious `vmnet` framework appeared that does support bridging, and so I've created an alternative to the tuntap module which works great. Using it, I can easily spawn network applications that can make external Internet queries using the OCaml network stack from Unix. > > I could use a sanity test from someone else running Yosemite first before I release this. If you are on an older MacOS X, then you will need to pass `--no-macosx` to the Mirage CLI to not use the new packages and use the old tuntap module. > > - `opam update` so you have the `vmnet` and `mirage-net-macos` packages (merged upstream today) > - `opam pin add mirage git://github.com/mirage/mirage` to get the 2.0.2 working tree. > - Try this mirage-skeleton example https://github.com/mirage/mirage-skeleton/pull/58 (using `DHCP=1 mirage configure`) > - Report back to this thread :) > > For CHANGES in Mirage 2.0.2 see: https://github.com/mirage/mirage/blob/master/CHANGES > > -anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 12:35:18 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 12:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmfg-0000xr-3y; Tue, 02 Dec 2014 12:35:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmff-0000xm-GD for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 12:35:11 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 50/E1-17958-EF1BD745; Tue, 02 Dec 2014 12:35:10 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-31.messagelabs.com!1417523709!15274578!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1125 invoked from network); 2 Dec 2014 12:35:10 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 12:35:10 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id d0eed533; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 12:40:13 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 12:35:07 +0000 Message-Id: <41540447-E5B3-48D2-AF61-B19F6366897C@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks for the report! > > - `vmnet` and `mirage-net-macosx` (not the x at the end) do not seem > to have trickled in to the default http opam repo yet. The OPAM HTTP remote temporarily hung; now restarted. > - make sure to run the example under sudo, otherwise the unikernel > just seems to hang without any output I'm fixing this in vmnet.1.0.1: https://github.com/mirage/ocaml-vmnet/pull/1 > > Thanks for this, it's great. I'm most curious -- does the NAT also work with IPv6? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 12:35:18 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 12:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmfg-0000xr-3y; Tue, 02 Dec 2014 12:35:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmff-0000xm-GD for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 12:35:11 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 50/E1-17958-EF1BD745; Tue, 02 Dec 2014 12:35:10 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-31.messagelabs.com!1417523709!15274578!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1125 invoked from network); 2 Dec 2014 12:35:10 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-8.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 12:35:10 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id d0eed533; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 12:40:13 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 12:35:07 +0000 Message-Id: <41540447-E5B3-48D2-AF61-B19F6366897C@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks for the report! > > - `vmnet` and `mirage-net-macosx` (not the x at the end) do not seem > to have trickled in to the default http opam repo yet. The OPAM HTTP remote temporarily hung; now restarted. > - make sure to run the example under sudo, otherwise the unikernel > just seems to hang without any output I'm fixing this in vmnet.1.0.1: https://github.com/mirage/ocaml-vmnet/pull/1 > > Thanks for this, it's great. I'm most curious -- does the NAT also work with IPv6? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 12:53:08 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 12:53:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmx0-0001ZR-3S; Tue, 02 Dec 2014 12:53:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmwz-0001ZM-8X for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 12:53:05 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 6B/DF-02712-036BD745; Tue, 02 Dec 2014 12:53:04 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-8.tower-27.messagelabs.com!1417524783!12469474!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12258 invoked from network); 2 Dec 2014 12:53:03 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-8.tower-27.messagelabs.com with SMTP; 2 Dec 2014 12:53:03 -0000 Received: from [172.20.10.2] (33-237.197-178.cust.bluewin.ch [178.197.237.33]) by smtp.webfaction.com (Postfix) with ESMTP id 2168159A3640; Tue, 2 Dec 2014 12:53:01 +0000 (UTC) Date: Tue, 2 Dec 2014 13:53:00 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: In-Reply-To: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbHVuZGksIDEgZMOpY2VtYnJlIDIwMTQgw6AgMjI6MDYsIEFuaWwgTWFkaGF2YXBlZGR5IGEg w6ljcml0IDoKPiBJIGNvdWxkIHVzZSBhIHNhbml0eSB0ZXN0IGZyb20gc29tZW9uZSBlbHNlIHJ1 bm5pbmcgWW9zZW1pdGUgZmlyc3QgYmVmb3JlIEkgcmVsZWFzZSB0aGlzLiBJZiB5b3UgYXJlIG9u IGFuIG9sZGVyIE1hY09TIFgsIHRoZW4geW91IHdpbGwgbmVlZCB0byBwYXNzIGAtLW5vLW1hY29z eGAgdG8gdGhlIE1pcmFnZSBDTEkgdG8gbm90IHVzZSB0aGUgbmV3IHBhY2thZ2VzIGFuZCB1c2Ug dGhlIG9sZCB0dW50YXAgbW9kdWxlLgoKV291bGRuJ3QgYmUg4oCUbm8tdm1uZXQgb3Ig4oCUbm8t bWFjb3N4LXZtbmV0IG9yIOKAlHVzZS10dW50YXAgKEkgdXN1YWxseSBwcmVmZXIgcG9zaXRpdmUg ZmxhZ3MpIG1vcmUgYWNjdXJhdGUgPyBQYXNzaW5nIOKAlG5vLW1hY29zeCBvbiBtYWNvc3ggZmVl bHMgYSBsaXR0bGUgYml0IGFic3VyZC4gIAoKRGFuaWVsCgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApN aXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVj dC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 12:53:08 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 12:53:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmx0-0001ZR-3S; Tue, 02 Dec 2014 12:53:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmwz-0001ZM-8X for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 12:53:05 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 6B/DF-02712-036BD745; Tue, 02 Dec 2014 12:53:04 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-8.tower-27.messagelabs.com!1417524783!12469474!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12258 invoked from network); 2 Dec 2014 12:53:03 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-8.tower-27.messagelabs.com with SMTP; 2 Dec 2014 12:53:03 -0000 Received: from [172.20.10.2] (33-237.197-178.cust.bluewin.ch [178.197.237.33]) by smtp.webfaction.com (Postfix) with ESMTP id 2168159A3640; Tue, 2 Dec 2014 12:53:01 +0000 (UTC) Date: Tue, 2 Dec 2014 13:53:00 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: In-Reply-To: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbHVuZGksIDEgZMOpY2VtYnJlIDIwMTQgw6AgMjI6MDYsIEFuaWwgTWFkaGF2YXBlZGR5IGEg w6ljcml0IDoKPiBJIGNvdWxkIHVzZSBhIHNhbml0eSB0ZXN0IGZyb20gc29tZW9uZSBlbHNlIHJ1 bm5pbmcgWW9zZW1pdGUgZmlyc3QgYmVmb3JlIEkgcmVsZWFzZSB0aGlzLiBJZiB5b3UgYXJlIG9u IGFuIG9sZGVyIE1hY09TIFgsIHRoZW4geW91IHdpbGwgbmVlZCB0byBwYXNzIGAtLW5vLW1hY29z eGAgdG8gdGhlIE1pcmFnZSBDTEkgdG8gbm90IHVzZSB0aGUgbmV3IHBhY2thZ2VzIGFuZCB1c2Ug dGhlIG9sZCB0dW50YXAgbW9kdWxlLgoKV291bGRuJ3QgYmUg4oCUbm8tdm1uZXQgb3Ig4oCUbm8t bWFjb3N4LXZtbmV0IG9yIOKAlHVzZS10dW50YXAgKEkgdXN1YWxseSBwcmVmZXIgcG9zaXRpdmUg ZmxhZ3MpIG1vcmUgYWNjdXJhdGUgPyBQYXNzaW5nIOKAlG5vLW1hY29zeCBvbiBtYWNvc3ggZmVl bHMgYSBsaXR0bGUgYml0IGFic3VyZC4gIAoKRGFuaWVsCgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApN aXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVj dC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:06:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:06:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnAB-00025T-U2; Tue, 02 Dec 2014 13:06:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnAB-00025K-5C for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:06:43 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id D8/95-15461-269BD745; Tue, 02 Dec 2014 13:06:42 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-21.messagelabs.com!1417525601!12827142!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 458 invoked from network); 2 Dec 2014 13:06:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 13:06:42 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id b02a0207; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 13:11:45 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 13:06:39 +0000 Message-Id: <856AE95E-CC32-4232-BD99-0A891E7185EE@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMiBEZWMgMjAxNCwgYXQgMTI6NTMsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBl cnJhdGlxdWUuY2g+IHdyb3RlOgo+IAo+IExlIGx1bmRpLCAxIGTDqWNlbWJyZSAyMDE0IMOgIDIy OjA2LCBBbmlsIE1hZGhhdmFwZWRkeSBhIMOpY3JpdCA6Cj4+IEkgY291bGQgdXNlIGEgc2FuaXR5 IHRlc3QgZnJvbSBzb21lb25lIGVsc2UgcnVubmluZyBZb3NlbWl0ZSBmaXJzdCBiZWZvcmUgSSBy ZWxlYXNlIHRoaXMuIElmIHlvdSBhcmUgb24gYW4gb2xkZXIgTWFjT1MgWCwgdGhlbiB5b3Ugd2ls bCBuZWVkIHRvIHBhc3MgYC0tbm8tbWFjb3N4YCB0byB0aGUgTWlyYWdlIENMSSB0byBub3QgdXNl IHRoZSBuZXcgcGFja2FnZXMgYW5kIHVzZSB0aGUgb2xkIHR1bnRhcCBtb2R1bGUuCj4gCj4gV291 bGRuJ3QgYmUg4oCUbm8tdm1uZXQgb3Ig4oCUbm8tbWFjb3N4LXZtbmV0IG9yIOKAlHVzZS10dW50 YXAgKEkgdXN1YWxseSBwcmVmZXIgcG9zaXRpdmUgZmxhZ3MpIG1vcmUgYWNjdXJhdGUgPyBQYXNz aW5nIOKAlG5vLW1hY29zeCBvbiBtYWNvc3ggZmVlbHMgYSBsaXR0bGUgYml0IGFic3VyZC4gIAoK V2VsbCwgaXQncyBvdmVycmlkaW5nIHRoZSBhY3R1YWwgcGxhdGZvcm0gZmxhZyAod2hpY2ggY291 bGQgaW52b2x2ZSB0aGluZ3MgYmV5b25kIFZtbmV0IGluIHRoZSBmdXR1cmUsIHN1Y2ggYXMgYSBm YW5jeSBjb25zb2xlIG9yIGJpbmFyeSBzYW5kYm94aW5nKS4gIFdlIGhhdmU6Cgo6IC0tdW5peAo6 IC0teGVuCjogLS1uby1tYWNvc3gKClRoZSBvdGhlciBhbHRlcm5hdGl2ZSBpcyB0byBnZXQgcmlk IG9mIHRoZSB3aG9sZSBmbGFnc2V0IGFuZCByZXBsYWNlIGl0IHdpdGggJy0tcGxhdGZvcm09W3Vu aXh8eGVufG1hY29zeF0gaW5zdGVhZCwgbGVhdmluZyAtLXhlbiBhbmQgLS11bml4IGFzIGNvbXBh dGliaWxpdHkgc2hpbXMuCgotYW5pbAoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRl dmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2kt YmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:06:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:06:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnAB-00025T-U2; Tue, 02 Dec 2014 13:06:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnAB-00025K-5C for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:06:43 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id D8/95-15461-269BD745; Tue, 02 Dec 2014 13:06:42 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-21.messagelabs.com!1417525601!12827142!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 458 invoked from network); 2 Dec 2014 13:06:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 13:06:42 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id b02a0207; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 13:11:45 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 13:06:39 +0000 Message-Id: <856AE95E-CC32-4232-BD99-0A891E7185EE@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMiBEZWMgMjAxNCwgYXQgMTI6NTMsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBl cnJhdGlxdWUuY2g+IHdyb3RlOgo+IAo+IExlIGx1bmRpLCAxIGTDqWNlbWJyZSAyMDE0IMOgIDIy OjA2LCBBbmlsIE1hZGhhdmFwZWRkeSBhIMOpY3JpdCA6Cj4+IEkgY291bGQgdXNlIGEgc2FuaXR5 IHRlc3QgZnJvbSBzb21lb25lIGVsc2UgcnVubmluZyBZb3NlbWl0ZSBmaXJzdCBiZWZvcmUgSSBy ZWxlYXNlIHRoaXMuIElmIHlvdSBhcmUgb24gYW4gb2xkZXIgTWFjT1MgWCwgdGhlbiB5b3Ugd2ls bCBuZWVkIHRvIHBhc3MgYC0tbm8tbWFjb3N4YCB0byB0aGUgTWlyYWdlIENMSSB0byBub3QgdXNl IHRoZSBuZXcgcGFja2FnZXMgYW5kIHVzZSB0aGUgb2xkIHR1bnRhcCBtb2R1bGUuCj4gCj4gV291 bGRuJ3QgYmUg4oCUbm8tdm1uZXQgb3Ig4oCUbm8tbWFjb3N4LXZtbmV0IG9yIOKAlHVzZS10dW50 YXAgKEkgdXN1YWxseSBwcmVmZXIgcG9zaXRpdmUgZmxhZ3MpIG1vcmUgYWNjdXJhdGUgPyBQYXNz aW5nIOKAlG5vLW1hY29zeCBvbiBtYWNvc3ggZmVlbHMgYSBsaXR0bGUgYml0IGFic3VyZC4gIAoK V2VsbCwgaXQncyBvdmVycmlkaW5nIHRoZSBhY3R1YWwgcGxhdGZvcm0gZmxhZyAod2hpY2ggY291 bGQgaW52b2x2ZSB0aGluZ3MgYmV5b25kIFZtbmV0IGluIHRoZSBmdXR1cmUsIHN1Y2ggYXMgYSBm YW5jeSBjb25zb2xlIG9yIGJpbmFyeSBzYW5kYm94aW5nKS4gIFdlIGhhdmU6Cgo6IC0tdW5peAo6 IC0teGVuCjogLS1uby1tYWNvc3gKClRoZSBvdGhlciBhbHRlcm5hdGl2ZSBpcyB0byBnZXQgcmlk IG9mIHRoZSB3aG9sZSBmbGFnc2V0IGFuZCByZXBsYWNlIGl0IHdpdGggJy0tcGxhdGZvcm09W3Vu aXh8eGVufG1hY29zeF0gaW5zdGVhZCwgbGVhdmluZyAtLXhlbiBhbmQgLS11bml4IGFzIGNvbXBh dGliaWxpdHkgc2hpbXMuCgotYW5pbAoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRl dmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2kt YmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:08:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:08:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnBx-00029M-Fr; Tue, 02 Dec 2014 13:08:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmh2-00016C-JN for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 12:36:36 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C9/75-25727-352BD745; Tue, 02 Dec 2014 12:36:35 +0000 X-Env-Sender: toby.moore.0@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1417523793!15171559!1 X-Originating-IP: [209.85.192.173] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24757 invoked from network); 2 Dec 2014 12:36:34 -0000 Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com) (209.85.192.173) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 12:36:34 -0000 Received: by mail-pd0-f173.google.com with SMTP id ft15so13044320pdb.18 for ; Tue, 02 Dec 2014 04:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=j5EwPgF6FlJG3jyDtv35iy2nwghy8c6j/MHOEctmlKw=; b=gpo2N5KHA+FBPRxHmxY82Wy9CQpOLCmDBJoZUqjcfmaat4MMeAEF1i0M6sdAISebVE E+dnA8V00+WReTkUAG4fYMmlYSHIBWUqkIcXQiiVAi4TFceYbSfw8IgMKLldBTAm50SS WTWoF/AHzoUnIP4JvhSc86n/E44EjH3O9a9h6arTOE4s0dL2b7jWNeXB5F45bqGyVQt1 1XmWHY6Hjb8b70j9TOl+L6mPYCMQNtTq6ptusEzAXYsYGROETxZeSZOS3r+YQZyTU/j5 hCw/cTwEHJx7OsvGFbmcdLE9bguwLSYTLxnc7yLT33fi4IQHwlN90oQvj6s4tURlNDBy lffw== X-Received: by 10.66.66.234 with SMTP id i10mr109753863pat.44.1417523792949; Tue, 02 Dec 2014 04:36:32 -0800 (PST) Received: from Tobys-MacBook-Pro.local (106-68-106-251.dyn.iinet.net.au. [106.68.106.251]) by mx.google.com with ESMTPSA id yp5sm19335941pbb.16.2014.12.02.04.36.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 04:36:32 -0800 (PST) Message-ID: <547DB24A.7050602@gmail.com> Date: Tue, 02 Dec 2014 20:36:26 +0800 From: Toby Moore User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org X-Mailman-Approved-At: Tue, 02 Dec 2014 13:08:32 +0000 Subject: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi everyone, I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: Unsupported function gmtime called in Mini-OS kernel Do_exit called! base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 Page fault in pagetable walk (access to invalid memory?). This is built with OCaml 4.01.0 with these OPAM packages: io-page 1.1.1 Allocate memory pages suitable for aligned I/O mirage 2.0.1 The Mirage library operating system mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo mirage-console 2.0.0 A Mirage-compatible Console library for Xen an mirage-dns 2.0.0 Virtual package for the Mirage DNS transports mirage-http 2.0.0 Mirage HTTP client and server driver for Unix mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen mirage-types 2.0.1 Module type definitions for Mirage-compatible mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati mirage-unix 2.0.0 Mirage OS library for Unix compilation mirage-xen 2.0.0 Mirage OS library for Xen compilation mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library I'm not directly passing a clock device, my config.ml has these bits in it: let main = foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) let unix_libs = match get_mode () with | `Unix -> ["mirage-clock-unix"] | _ -> [] let () = add_to_ocamlfind_libraries unix_libs; ... This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? Thanks, Toby _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:08:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:08:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnBx-00029M-Fr; Tue, 02 Dec 2014 13:08:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvmh2-00016C-JN for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 12:36:36 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C9/75-25727-352BD745; Tue, 02 Dec 2014 12:36:35 +0000 X-Env-Sender: toby.moore.0@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1417523793!15171559!1 X-Originating-IP: [209.85.192.173] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24757 invoked from network); 2 Dec 2014 12:36:34 -0000 Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com) (209.85.192.173) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 12:36:34 -0000 Received: by mail-pd0-f173.google.com with SMTP id ft15so13044320pdb.18 for ; Tue, 02 Dec 2014 04:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=j5EwPgF6FlJG3jyDtv35iy2nwghy8c6j/MHOEctmlKw=; b=gpo2N5KHA+FBPRxHmxY82Wy9CQpOLCmDBJoZUqjcfmaat4MMeAEF1i0M6sdAISebVE E+dnA8V00+WReTkUAG4fYMmlYSHIBWUqkIcXQiiVAi4TFceYbSfw8IgMKLldBTAm50SS WTWoF/AHzoUnIP4JvhSc86n/E44EjH3O9a9h6arTOE4s0dL2b7jWNeXB5F45bqGyVQt1 1XmWHY6Hjb8b70j9TOl+L6mPYCMQNtTq6ptusEzAXYsYGROETxZeSZOS3r+YQZyTU/j5 hCw/cTwEHJx7OsvGFbmcdLE9bguwLSYTLxnc7yLT33fi4IQHwlN90oQvj6s4tURlNDBy lffw== X-Received: by 10.66.66.234 with SMTP id i10mr109753863pat.44.1417523792949; Tue, 02 Dec 2014 04:36:32 -0800 (PST) Received: from Tobys-MacBook-Pro.local (106-68-106-251.dyn.iinet.net.au. [106.68.106.251]) by mx.google.com with ESMTPSA id yp5sm19335941pbb.16.2014.12.02.04.36.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 04:36:32 -0800 (PST) Message-ID: <547DB24A.7050602@gmail.com> Date: Tue, 02 Dec 2014 20:36:26 +0800 From: Toby Moore User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org X-Mailman-Approved-At: Tue, 02 Dec 2014 13:08:32 +0000 Subject: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi everyone, I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: Unsupported function gmtime called in Mini-OS kernel Do_exit called! base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 Page fault in pagetable walk (access to invalid memory?). This is built with OCaml 4.01.0 with these OPAM packages: io-page 1.1.1 Allocate memory pages suitable for aligned I/O mirage 2.0.1 The Mirage library operating system mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo mirage-console 2.0.0 A Mirage-compatible Console library for Xen an mirage-dns 2.0.0 Virtual package for the Mirage DNS transports mirage-http 2.0.0 Mirage HTTP client and server driver for Unix mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen mirage-types 2.0.1 Module type definitions for Mirage-compatible mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati mirage-unix 2.0.0 Mirage OS library for Unix compilation mirage-xen 2.0.0 Mirage OS library for Xen compilation mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library I'm not directly passing a clock device, my config.ml has these bits in it: let main = foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) let unix_libs = match get_mode () with | `Unix -> ["mirage-clock-unix"] | _ -> [] let () = add_to_ocamlfind_libraries unix_libs; ... This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? Thanks, Toby _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:12:09 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:12:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnFQ-0002Iz-Qz; Tue, 02 Dec 2014 13:12:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnFP-0002Ir-19 for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:12:07 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 31/74-09842-6AABD745; Tue, 02 Dec 2014 13:12:06 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-21.messagelabs.com!1417525925!12866698!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29370 invoked from network); 2 Dec 2014 13:12:05 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 13:12:05 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 4f242a78; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 13:17:09 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <547DB24A.7050602@gmail.com> Date: Tue, 2 Dec 2014 13:12:03 +0000 Message-Id: <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> References: <547DB24A.7050602@gmail.com> To: Toby Moore X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 12:36, Toby Moore wrote: > > Hi everyone, > > I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) > One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: > > Unsupported function gmtime called in Mini-OS kernel > Do_exit called! > base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 > Page fault in pagetable walk (access to invalid memory?). That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? > > This is built with OCaml 4.01.0 with these OPAM packages: > io-page 1.1.1 Allocate memory pages suitable for aligned I/O > mirage 2.0.1 The Mirage library operating system > mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix > mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen > mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo > mirage-console 2.0.0 A Mirage-compatible Console library for Xen an > mirage-dns 2.0.0 Virtual package for the Mirage DNS transports > mirage-http 2.0.0 Mirage HTTP client and server driver for Unix > mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt > mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen > mirage-types 2.0.1 Module type definitions for Mirage-compatible > mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati > mirage-unix 2.0.0 Mirage OS library for Unix compilation > mirage-xen 2.0.0 Mirage OS library for Xen compilation > mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library > > I'm not directly passing a clock device, my config.ml has these bits in it: > > let main = > foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) > > let unix_libs = > match get_mode () with > | `Unix -> ["mirage-clock-unix"] > | _ -> [] > > let () = > add_to_ocamlfind_libraries unix_libs; > ... > > This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:12:09 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:12:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnFQ-0002Iz-Qz; Tue, 02 Dec 2014 13:12:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnFP-0002Ir-19 for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:12:07 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 31/74-09842-6AABD745; Tue, 02 Dec 2014 13:12:06 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-21.messagelabs.com!1417525925!12866698!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29370 invoked from network); 2 Dec 2014 13:12:05 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 13:12:05 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 4f242a78; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 13:17:09 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <547DB24A.7050602@gmail.com> Date: Tue, 2 Dec 2014 13:12:03 +0000 Message-Id: <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> References: <547DB24A.7050602@gmail.com> To: Toby Moore X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 12:36, Toby Moore wrote: > > Hi everyone, > > I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) > One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: > > Unsupported function gmtime called in Mini-OS kernel > Do_exit called! > base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 > Page fault in pagetable walk (access to invalid memory?). That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? > > This is built with OCaml 4.01.0 with these OPAM packages: > io-page 1.1.1 Allocate memory pages suitable for aligned I/O > mirage 2.0.1 The Mirage library operating system > mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix > mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen > mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo > mirage-console 2.0.0 A Mirage-compatible Console library for Xen an > mirage-dns 2.0.0 Virtual package for the Mirage DNS transports > mirage-http 2.0.0 Mirage HTTP client and server driver for Unix > mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt > mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen > mirage-types 2.0.1 Module type definitions for Mirage-compatible > mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati > mirage-unix 2.0.0 Mirage OS library for Unix compilation > mirage-xen 2.0.0 Mirage OS library for Xen compilation > mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library > > I'm not directly passing a clock device, my config.ml has these bits in it: > > let main = > foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) > > let unix_libs = > match get_mode () with > | `Unix -> ["mirage-clock-unix"] > | _ -> [] > > let () = > add_to_ocamlfind_libraries unix_libs; > ... > > This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:22:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:22:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnPg-0002jA-Dc; Tue, 02 Dec 2014 13:22:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnPf-0002j1-OW for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:22:43 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C2/56-25727-32DBD745; Tue, 02 Dec 2014 13:22:43 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-8.tower-31.messagelabs.com!1417526562!15288542!1 X-Originating-IP: [128.243.43.110] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15586 invoked from network); 2 Dec 2014 13:22:42 -0000 Received: from uidappmx02.nottingham.ac.uk (HELO uidappmx02.nottingham.ac.uk) (128.243.43.110) by server-8.tower-31.messagelabs.com with SMTP; 2 Dec 2014 13:22:42 -0000 Received: from uidappmx02.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A9CE92EAA18_47DBD21B for ; Tue, 2 Dec 2014 13:22:41 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx02.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 57E175B8109_47DBD21F for ; Tue, 2 Dec 2014 13:22:41 +0000 (GMT) Received: from uiwexhub01.ad.nottingham.ac.uk ([128.243.15.133]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1XvnPd-0006qZ-1U; Tue, 02 Dec 2014 13:22:41 +0000 From: Richard Mortier To: Anil Madhavapeddy Date: Tue, 2 Dec 2014 13:22:38 +0000 Thread-Topic: [MirageOS-devel] Passing tap devices to the main module Thread-Index: AdAOMwsxypwDLnMqQoCYj7xoiH6HoA== Message-ID: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7254809933263901773==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7254809933263901773== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > On 6 Oct 2014, at 11:43, Richard Mortier wrote: >> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>=20 >>> Block devices have another Xenstore numbering scheme that seems far mor= e Linux-specific (and afaict, one that only Dave and Mort understand :-) >>=20 >> pshaw. it's in the code. plain for all to see. somewhere. >> (just don't ask me to remember it... :) >>=20 >> in a spirit of functorisation, it seems like one should be able to pass = in a function that would generate the next device id as part of the configu= ration of a unikernel, rather than embedding it in some backend library (or= even frontend tool). or perhaps that's what providing a device tree would = do? >=20 > Yes, but what does 'next' mean here? What happens if you have three devi= ces simultaneously hotplugged? They are mostly independent devices with th= e only connection being the unique identifier that Xenstore gives then (via= the backend toolchain), so it seems odd that one device would be required = to give the next one (which is potentially running in a completely separate= domain) it's identifier. hm-- yes.=20 tbh i think i had several misunderstandings, notably that i was assuming th= at it was the guest's job to register an id for the device in xenstore (und= er a domain prefix) when the device gets hot plugged into the guest, rather= than xenstore's job to give each device an id that's unique inside the gue= st. --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUfYkKAAoJEOLF27JWwSg3QG8QAIRkdJn6yUfYQqAum+yV2dMZ 1wtCnj8fdkLPTNRbug9aM/LYnMon8gkVA7IhJjZarOOfKZBUFTq8+b4MxbeI9v4y ZLSL3/EPdwl7TB/Ov7WiyLF3ZsMqrEIBNLorAzUYSuM9/twvakksClbTtkY+AMap TKCogPToiffvt+2t2S0r+qcjoG9Fx06J32uQHxTGKAyPozuk2S/bagTExrgnuwrN 8BQ0Pbw9G2Lpg+14bV4cL46cDH92aPc+0sV1xAxtlcNnrxiGhi0dTce+gRVC2ciy /l8rzH8r2/xVCC3o2jhmVZMjZfI6YzbbOVb8lkfVvu6tvwZV8WNjCSMInHZGBwGa 2ZZgDBHSTZzwFO9E9+iSsX/uicd/bMZTFA9s4E/MZXXCBiMVYX59xOisqi9kWB/s kdNFsKk2rwJKnJYlSaKAW8dqX2sRI6alYkK0bIXP0mJSCSHdL4gpC7YMrd/UeGrS l/en6BPqFOusxqoEnx6sC13QNG6/ukwi1CaBZLVsMdc7IooTmgk0wH8H5Ap9cchL dQ69jpLgqqSn1dp8dyU7GV6nyXRRV4eblq+0fTZi4DmOslM6ix6qhvWj7Wz+7mVJ mSj7h3bFOySIaCcuWyH8mz8F1br0yjEMu/0hvBhiNh31w3wn1q8Nm8gts0FGQQCq /81WVFFeH0F+SNQMfSgP =7B57 -----END PGP SIGNATURE----- --Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B-- --===============7254809933263901773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7254809933263901773==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:22:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:22:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnPg-0002jA-Dc; Tue, 02 Dec 2014 13:22:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnPf-0002j1-OW for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:22:43 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C2/56-25727-32DBD745; Tue, 02 Dec 2014 13:22:43 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-8.tower-31.messagelabs.com!1417526562!15288542!1 X-Originating-IP: [128.243.43.110] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15586 invoked from network); 2 Dec 2014 13:22:42 -0000 Received: from uidappmx02.nottingham.ac.uk (HELO uidappmx02.nottingham.ac.uk) (128.243.43.110) by server-8.tower-31.messagelabs.com with SMTP; 2 Dec 2014 13:22:42 -0000 Received: from uidappmx02.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A9CE92EAA18_47DBD21B for ; Tue, 2 Dec 2014 13:22:41 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx02.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 57E175B8109_47DBD21F for ; Tue, 2 Dec 2014 13:22:41 +0000 (GMT) Received: from uiwexhub01.ad.nottingham.ac.uk ([128.243.15.133]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1XvnPd-0006qZ-1U; Tue, 02 Dec 2014 13:22:41 +0000 From: Richard Mortier To: Anil Madhavapeddy Date: Tue, 2 Dec 2014 13:22:38 +0000 Thread-Topic: [MirageOS-devel] Passing tap devices to the main module Thread-Index: AdAOMwsxypwDLnMqQoCYj7xoiH6HoA== Message-ID: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7254809933263901773==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7254809933263901773== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > On 6 Oct 2014, at 11:43, Richard Mortier wrote: >> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>=20 >>> Block devices have another Xenstore numbering scheme that seems far mor= e Linux-specific (and afaict, one that only Dave and Mort understand :-) >>=20 >> pshaw. it's in the code. plain for all to see. somewhere. >> (just don't ask me to remember it... :) >>=20 >> in a spirit of functorisation, it seems like one should be able to pass = in a function that would generate the next device id as part of the configu= ration of a unikernel, rather than embedding it in some backend library (or= even frontend tool). or perhaps that's what providing a device tree would = do? >=20 > Yes, but what does 'next' mean here? What happens if you have three devi= ces simultaneously hotplugged? They are mostly independent devices with th= e only connection being the unique identifier that Xenstore gives then (via= the backend toolchain), so it seems odd that one device would be required = to give the next one (which is potentially running in a completely separate= domain) it's identifier. hm-- yes.=20 tbh i think i had several misunderstandings, notably that i was assuming th= at it was the guest's job to register an id for the device in xenstore (und= er a domain prefix) when the device gets hot plugged into the guest, rather= than xenstore's job to give each device an id that's unique inside the gue= st. --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUfYkKAAoJEOLF27JWwSg3QG8QAIRkdJn6yUfYQqAum+yV2dMZ 1wtCnj8fdkLPTNRbug9aM/LYnMon8gkVA7IhJjZarOOfKZBUFTq8+b4MxbeI9v4y ZLSL3/EPdwl7TB/Ov7WiyLF3ZsMqrEIBNLorAzUYSuM9/twvakksClbTtkY+AMap TKCogPToiffvt+2t2S0r+qcjoG9Fx06J32uQHxTGKAyPozuk2S/bagTExrgnuwrN 8BQ0Pbw9G2Lpg+14bV4cL46cDH92aPc+0sV1xAxtlcNnrxiGhi0dTce+gRVC2ciy /l8rzH8r2/xVCC3o2jhmVZMjZfI6YzbbOVb8lkfVvu6tvwZV8WNjCSMInHZGBwGa 2ZZgDBHSTZzwFO9E9+iSsX/uicd/bMZTFA9s4E/MZXXCBiMVYX59xOisqi9kWB/s kdNFsKk2rwJKnJYlSaKAW8dqX2sRI6alYkK0bIXP0mJSCSHdL4gpC7YMrd/UeGrS l/en6BPqFOusxqoEnx6sC13QNG6/ukwi1CaBZLVsMdc7IooTmgk0wH8H5Ap9cchL dQ69jpLgqqSn1dp8dyU7GV6nyXRRV4eblq+0fTZi4DmOslM6ix6qhvWj7Wz+7mVJ mSj7h3bFOySIaCcuWyH8mz8F1br0yjEMu/0hvBhiNh31w3wn1q8Nm8gts0FGQQCq /81WVFFeH0F+SNQMfSgP =7B57 -----END PGP SIGNATURE----- --Apple-Mail=_0D908395-D12D-4C60-817D-859533875C2B-- --===============7254809933263901773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7254809933263901773==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:37:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:37:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvne4-0002rw-K9; Tue, 02 Dec 2014 13:37:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvne3-0002rr-HM for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:37:35 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id EA/F9-02953-E90CD745; Tue, 02 Dec 2014 13:37:34 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-13.tower-27.messagelabs.com!1417527453!12478285!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26612 invoked from network); 2 Dec 2014 13:37:33 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-13.tower-27.messagelabs.com with SMTP; 2 Dec 2014 13:37:33 -0000 Received: from [172.20.10.2] (33-237.197-178.cust.bluewin.ch [178.197.237.33]) by smtp.webfaction.com (Postfix) with ESMTP id D31D026EA2E4; Tue, 2 Dec 2014 13:37:31 +0000 (UTC) Date: Tue, 2 Dec 2014 14:37:29 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: <28EAFEFF744D43A1B7F29A07D67005EC@erratique.ch> In-Reply-To: <856AE95E-CC32-4232-BD99-0A891E7185EE@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> <856AE95E-CC32-4232-BD99-0A891E7185EE@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org CgpMZSBtYXJkaSwgMiBkw6ljZW1icmUgMjAxNCDDoCAxNDowNiwgQW5pbCBNYWRoYXZhcGVkZHkg YSDDqWNyaXQgOgoKPiBXZWxsLCBpdCdzIG92ZXJyaWRpbmcgdGhlIGFjdHVhbCBwbGF0Zm9ybSBm bGFnICh3aGljaCBjb3VsZCBpbnZvbHZlIHRoaW5ncyBiZXlvbmQgVm1uZXQgaW4gdGhlIGZ1dHVy ZSwgc3VjaCBhcyBhIGZhbmN5IGNvbnNvbGUgb3IgYmluYXJ5IHNhbmRib3hpbmcpLiBXZSBoYXZl Ogo+ICAKPiA6IC0tdW5peAo+IDogLS14ZW4KPiA6IC0tbm8tbWFjb3N4CgpBaCBpdCBtYWtlcyBl dmVuIGxlc3Mgc2Vuc2Ugd2hlbiBzZWVuIHRoYXQgd2F5ICAhICAKCj4gVGhlIG90aGVyIGFsdGVy bmF0aXZlIGlzIHRvIGdldCByaWQgb2YgdGhlIHdob2xlIGZsYWdzZXQgYW5kIHJlcGxhY2UgaXQg d2l0aCAnLS1wbGF0Zm9ybT1bdW5peHx4ZW58bWFjb3N4XSBpbnN0ZWFkLCBsZWF2aW5nIC0teGVu IGFuZCAtLXVuaXggYXMgY29tcGF0aWJpbGl0eSBzaGltcy4KU2VlbXMgbW9yZSB1bmRlcnN0YW5k YWJsZS9hbmQgc2NhbGFibGUgaW4gdGhlIGxvbmcgdGVybSAodGhvdWdoIEkgc3VzcGVjdCBwcmUg MTAuMTAgb3N4IHVzZXJzIHdpbGwgc3RpbGwgYmUgdGVtcHRlZCBieSB1c2luZyBwbGF0Zm9ybT1t YWNvc3gpICAKCkRhbmllbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlz dHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFp bG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:37:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:37:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvne4-0002rw-K9; Tue, 02 Dec 2014 13:37:36 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvne3-0002rr-HM for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:37:35 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id EA/F9-02953-E90CD745; Tue, 02 Dec 2014 13:37:34 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-13.tower-27.messagelabs.com!1417527453!12478285!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26612 invoked from network); 2 Dec 2014 13:37:33 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-13.tower-27.messagelabs.com with SMTP; 2 Dec 2014 13:37:33 -0000 Received: from [172.20.10.2] (33-237.197-178.cust.bluewin.ch [178.197.237.33]) by smtp.webfaction.com (Postfix) with ESMTP id D31D026EA2E4; Tue, 2 Dec 2014 13:37:31 +0000 (UTC) Date: Tue, 2 Dec 2014 14:37:29 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: <28EAFEFF744D43A1B7F29A07D67005EC@erratique.ch> In-Reply-To: <856AE95E-CC32-4232-BD99-0A891E7185EE@recoil.org> References: <7FBB38C2-FE8D-44F2-86FD-4C4E43865427@recoil.org> <856AE95E-CC32-4232-BD99-0A891E7185EE@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org CgpMZSBtYXJkaSwgMiBkw6ljZW1icmUgMjAxNCDDoCAxNDowNiwgQW5pbCBNYWRoYXZhcGVkZHkg YSDDqWNyaXQgOgoKPiBXZWxsLCBpdCdzIG92ZXJyaWRpbmcgdGhlIGFjdHVhbCBwbGF0Zm9ybSBm bGFnICh3aGljaCBjb3VsZCBpbnZvbHZlIHRoaW5ncyBiZXlvbmQgVm1uZXQgaW4gdGhlIGZ1dHVy ZSwgc3VjaCBhcyBhIGZhbmN5IGNvbnNvbGUgb3IgYmluYXJ5IHNhbmRib3hpbmcpLiBXZSBoYXZl Ogo+ICAKPiA6IC0tdW5peAo+IDogLS14ZW4KPiA6IC0tbm8tbWFjb3N4CgpBaCBpdCBtYWtlcyBl dmVuIGxlc3Mgc2Vuc2Ugd2hlbiBzZWVuIHRoYXQgd2F5ICAhICAKCj4gVGhlIG90aGVyIGFsdGVy bmF0aXZlIGlzIHRvIGdldCByaWQgb2YgdGhlIHdob2xlIGZsYWdzZXQgYW5kIHJlcGxhY2UgaXQg d2l0aCAnLS1wbGF0Zm9ybT1bdW5peHx4ZW58bWFjb3N4XSBpbnN0ZWFkLCBsZWF2aW5nIC0teGVu IGFuZCAtLXVuaXggYXMgY29tcGF0aWJpbGl0eSBzaGltcy4KU2VlbXMgbW9yZSB1bmRlcnN0YW5k YWJsZS9hbmQgc2NhbGFibGUgaW4gdGhlIGxvbmcgdGVybSAodGhvdWdoIEkgc3VzcGVjdCBwcmUg MTAuMTAgb3N4IHVzZXJzIHdpbGwgc3RpbGwgYmUgdGVtcHRlZCBieSB1c2luZyBwbGF0Zm9ybT1t YWNvc3gpICAKCkRhbmllbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlz dHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFp bG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:38:44 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:38:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnfA-0002te-Q9; Tue, 02 Dec 2014 13:38:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvnf9-0002tW-LB for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:38:43 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 7F/3A-27623-2E0CD745; Tue, 02 Dec 2014 13:38:42 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1417527522!15281133!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25477 invoked from network); 2 Dec 2014 13:38:42 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 13:38:42 -0000 Received: by mail-wi0-f182.google.com with SMTP id h11so20966832wiw.15 for ; Tue, 02 Dec 2014 05:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=07EGTuBFcEtcx3a+H3n5Gi3VmINX2A9Mx6M33tPAulE=; b=Pk5nEnn32wsIAjpzZ7Eb6JmqjmGf8XS7cLG53OPyKrDtEY0O0dUJ+/x+f+YP7Z/pGL +cr7XZi5FwPA8hhOePQqSCw/EfqnSBVCzba4NSSYvwGPKH0zs0lVwwoNvrd+CpEVP6um 20TrHThd1/JrCDscPakRIhEYZ5cw7pk6smgniGIYlTiiJjqU4QSNitCZ2npe2SlP2+fp dpaJoTLD65PF9BIo/FpukQm5judJtf8Sg/6UJIhR+sot3aeT7qwgAIk0+wwyypMxaLw9 fb6k/fQqyyCzAcJxzd5r5g4vX7JkKfZA9lVGXKMCGOAVm1ZHL3Gjr3babePBjIIGHhXh +Kpw== X-Received: by 10.194.95.196 with SMTP id dm4mr98606921wjb.41.1417527521828; Tue, 02 Dec 2014 05:38:41 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id a2sm32812718wiy.11.2014.12.02.05.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 05:38:41 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <547DB24A.7050602@gmail.com> Date: Tue, 2 Dec 2014 13:38:39 +0000 Message-Id: References: <547DB24A.7050602@gmail.com> To: Toby Moore X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > let unix_libs = > match get_mode () with > | `Unix -> ["mirage-clock-unix"] > | _ -> [] I think using `Xen -> ["mirage-clock-xen"] should be better. Not sure it will help with your problem, though ... (the relevant code in mirage/lib is https://github.com/mirage/mirage/blob/master/lib/mirage.ml#L384 Thomas > > let () = > add_to_ocamlfind_libraries unix_libs; > ... > > This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? > > Thanks, > Toby > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:38:44 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:38:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvnfA-0002te-Q9; Tue, 02 Dec 2014 13:38:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvnf9-0002tW-LB for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:38:43 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 7F/3A-27623-2E0CD745; Tue, 02 Dec 2014 13:38:42 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1417527522!15281133!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25477 invoked from network); 2 Dec 2014 13:38:42 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 13:38:42 -0000 Received: by mail-wi0-f182.google.com with SMTP id h11so20966832wiw.15 for ; Tue, 02 Dec 2014 05:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=07EGTuBFcEtcx3a+H3n5Gi3VmINX2A9Mx6M33tPAulE=; b=Pk5nEnn32wsIAjpzZ7Eb6JmqjmGf8XS7cLG53OPyKrDtEY0O0dUJ+/x+f+YP7Z/pGL +cr7XZi5FwPA8hhOePQqSCw/EfqnSBVCzba4NSSYvwGPKH0zs0lVwwoNvrd+CpEVP6um 20TrHThd1/JrCDscPakRIhEYZ5cw7pk6smgniGIYlTiiJjqU4QSNitCZ2npe2SlP2+fp dpaJoTLD65PF9BIo/FpukQm5judJtf8Sg/6UJIhR+sot3aeT7qwgAIk0+wwyypMxaLw9 fb6k/fQqyyCzAcJxzd5r5g4vX7JkKfZA9lVGXKMCGOAVm1ZHL3Gjr3babePBjIIGHhXh +Kpw== X-Received: by 10.194.95.196 with SMTP id dm4mr98606921wjb.41.1417527521828; Tue, 02 Dec 2014 05:38:41 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id a2sm32812718wiy.11.2014.12.02.05.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 05:38:41 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <547DB24A.7050602@gmail.com> Date: Tue, 2 Dec 2014 13:38:39 +0000 Message-Id: References: <547DB24A.7050602@gmail.com> To: Toby Moore X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > let unix_libs = > match get_mode () with > | `Unix -> ["mirage-clock-unix"] > | _ -> [] I think using `Xen -> ["mirage-clock-xen"] should be better. Not sure it will help with your problem, though ... (the relevant code in mirage/lib is https://github.com/mirage/mirage/blob/master/lib/mirage.ml#L384 Thomas > > let () = > add_to_ocamlfind_libraries unix_libs; > ... > > This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? > > Thanks, > Toby > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:42:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:42:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvnix-0002yt-5d; Tue, 02 Dec 2014 13:42:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvniv-0002ye-HS for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:42:37 +0000 Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id 27/C9-02699-CC1CD745; Tue, 02 Dec 2014 13:42:36 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1417527754!7826819!1 X-Originating-IP: [209.85.220.180] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17029 invoked from network); 2 Dec 2014 13:42:35 -0000 Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 13:42:35 -0000 Received: by mail-vc0-f180.google.com with SMTP id im6so5640890vcb.25 for ; Tue, 02 Dec 2014 05:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lMMEKTTRYq2dSv66i9u3/bdryINTAp0YqsYm0XVutAM=; b=IL5qtPAJnNOxAyZzJeMShme6ulKKnxRlsQXlAwGyKfM3S5BWjyHWpQC4KljEEjIWmo X2Hp6B1DD0Cq2o8jIYUqeVF1D0KjaurA2qoVaYyYv9mELV+qpqmUWxGQbYHrKxR4ND9/ pLaFZiNj9QQaA4qFCzeRswqjkXGIM+ne0sAWLC7MADZiUZv5/XUqYF+z3T36r1+rCEBM fbgBrgpkCy0x+pNE55BCwg4PrlEZRacsD2s6ibtQa0TOrgB5NNxwwNq6HtYyIf00nN4R XePOnzDU8+875UOk6LqpHpEqj+00wmlOxK+0w4nU/N3WJrAsxXzzvdb+RxXzugT3ScWJ +hzA== MIME-Version: 1.0 X-Received: by 10.52.27.10 with SMTP id p10mr26394111vdg.89.1417527753997; Tue, 02 Dec 2014 05:42:33 -0800 (PST) Received: by 10.31.183.134 with HTTP; Tue, 2 Dec 2014 05:42:33 -0800 (PST) In-Reply-To: <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> Date: Tue, 2 Dec 2014 13:42:33 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: Toby Moore , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 December 2014 at 13:12, Anil Madhavapeddy wrote: > On 2 Dec 2014, at 12:36, Toby Moore wrote: >> >> Hi everyone, >> >> I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. > > Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) > >> One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: >> >> Unsupported function gmtime called in Mini-OS kernel >> Do_exit called! >> base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 >> Page fault in pagetable walk (access to invalid memory?). You're using Clock.time () for this, I assume? I added this to the start of mirage-skeleton/ethifv4/unikernel.ml (which I guess is where you copied the code from): let start c net = C.log_s c (Printf.sprintf "Time is %f\n" @@ Clock.time ()) >>= fun () -> and it printed 1417522247.474221 (which is the correct time) when I ran it under Xen. I'm running Xen in VirtualBox for local testing, which seems to work well. Perhaps something else you're using has added a dependency on mirage-clock-unix somehow? > That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? > >> >> This is built with OCaml 4.01.0 with these OPAM packages: >> io-page 1.1.1 Allocate memory pages suitable for aligned I/O >> mirage 2.0.1 The Mirage library operating system >> mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix >> mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen >> mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo >> mirage-console 2.0.0 A Mirage-compatible Console library for Xen an >> mirage-dns 2.0.0 Virtual package for the Mirage DNS transports >> mirage-http 2.0.0 Mirage HTTP client and server driver for Unix >> mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt >> mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen >> mirage-types 2.0.1 Module type definitions for Mirage-compatible >> mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati >> mirage-unix 2.0.0 Mirage OS library for Unix compilation >> mirage-xen 2.0.0 Mirage OS library for Xen compilation >> mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library >> >> I'm not directly passing a clock device, my config.ml has these bits in it: >> >> let main = >> foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) >> >> let unix_libs = >> match get_mode () with >> | `Unix -> ["mirage-clock-unix"] >> | _ -> [] >> >> let () = >> add_to_ocamlfind_libraries unix_libs; >> ... >> >> This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? > > Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. > > -anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 13:42:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 13:42:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvnix-0002yt-5d; Tue, 02 Dec 2014 13:42:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvniv-0002ye-HS for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 13:42:37 +0000 Received: from [193.109.254.147] by server-13.bemta-14.messagelabs.com id 27/C9-02699-CC1CD745; Tue, 02 Dec 2014 13:42:36 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1417527754!7826819!1 X-Originating-IP: [209.85.220.180] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17029 invoked from network); 2 Dec 2014 13:42:35 -0000 Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 13:42:35 -0000 Received: by mail-vc0-f180.google.com with SMTP id im6so5640890vcb.25 for ; Tue, 02 Dec 2014 05:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lMMEKTTRYq2dSv66i9u3/bdryINTAp0YqsYm0XVutAM=; b=IL5qtPAJnNOxAyZzJeMShme6ulKKnxRlsQXlAwGyKfM3S5BWjyHWpQC4KljEEjIWmo X2Hp6B1DD0Cq2o8jIYUqeVF1D0KjaurA2qoVaYyYv9mELV+qpqmUWxGQbYHrKxR4ND9/ pLaFZiNj9QQaA4qFCzeRswqjkXGIM+ne0sAWLC7MADZiUZv5/XUqYF+z3T36r1+rCEBM fbgBrgpkCy0x+pNE55BCwg4PrlEZRacsD2s6ibtQa0TOrgB5NNxwwNq6HtYyIf00nN4R XePOnzDU8+875UOk6LqpHpEqj+00wmlOxK+0w4nU/N3WJrAsxXzzvdb+RxXzugT3ScWJ +hzA== MIME-Version: 1.0 X-Received: by 10.52.27.10 with SMTP id p10mr26394111vdg.89.1417527753997; Tue, 02 Dec 2014 05:42:33 -0800 (PST) Received: by 10.31.183.134 with HTTP; Tue, 2 Dec 2014 05:42:33 -0800 (PST) In-Reply-To: <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> Date: Tue, 2 Dec 2014 13:42:33 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: Toby Moore , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 December 2014 at 13:12, Anil Madhavapeddy wrote: > On 2 Dec 2014, at 12:36, Toby Moore wrote: >> >> Hi everyone, >> >> I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. > > Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) > >> One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: >> >> Unsupported function gmtime called in Mini-OS kernel >> Do_exit called! >> base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 >> Page fault in pagetable walk (access to invalid memory?). You're using Clock.time () for this, I assume? I added this to the start of mirage-skeleton/ethifv4/unikernel.ml (which I guess is where you copied the code from): let start c net = C.log_s c (Printf.sprintf "Time is %f\n" @@ Clock.time ()) >>= fun () -> and it printed 1417522247.474221 (which is the correct time) when I ran it under Xen. I'm running Xen in VirtualBox for local testing, which seems to work well. Perhaps something else you're using has added a dependency on mirage-clock-unix somehow? > That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? > >> >> This is built with OCaml 4.01.0 with these OPAM packages: >> io-page 1.1.1 Allocate memory pages suitable for aligned I/O >> mirage 2.0.1 The Mirage library operating system >> mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix >> mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen >> mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo >> mirage-console 2.0.0 A Mirage-compatible Console library for Xen an >> mirage-dns 2.0.0 Virtual package for the Mirage DNS transports >> mirage-http 2.0.0 Mirage HTTP client and server driver for Unix >> mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt >> mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen >> mirage-types 2.0.1 Module type definitions for Mirage-compatible >> mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati >> mirage-unix 2.0.0 Mirage OS library for Unix compilation >> mirage-xen 2.0.0 Mirage OS library for Xen compilation >> mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library >> >> I'm not directly passing a clock device, my config.ml has these bits in it: >> >> let main = >> foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) >> >> let unix_libs = >> match get_mode () with >> | `Unix -> ["mirage-clock-unix"] >> | _ -> [] >> >> let () = >> add_to_ocamlfind_libraries unix_libs; >> ... >> >> This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? > > Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. > > -anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 15:06:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 15:06:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvp2F-00071l-M3; Tue, 02 Dec 2014 15:06:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvp2D-00071R-Sm for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:06:38 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 1E/EB-09842-D75DD745; Tue, 02 Dec 2014 15:06:37 +0000 X-Env-Sender: toby.moore.0@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1417532793!12903486!1 X-Originating-IP: [209.85.192.170] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11918 invoked from network); 2 Dec 2014 15:06:34 -0000 Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 15:06:34 -0000 Received: by mail-pd0-f170.google.com with SMTP id fp1so13380873pdb.29 for ; Tue, 02 Dec 2014 07:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=yj/mTgxMEcWAPJYNAYTnxoZ9tgUJgxEWpBEHGjV/naM=; b=OoRrQ5Qr8Oak+az/eaQLCVR1jbzQ0AlmteUpSqVCtwZGpbzEykB/Tnt94Xj+WCpls5 g6JB/Cr9N6eQBGT7Pf4BPk636/9BalBPZiYR1gkHSf5h9uxcFEWvo1B3yDwapZ5PH3UT 0tJpsRdDZhaMqhaL8PyLWz1KJUYObIIE4wbR2DVOdDPJ85hhQTZ77iuHRtC3Nv3asiR5 n37rywekPqoNUHC0xo1j4m2dUuilEylS0s+rYmQZjwiWpYsWoH5o9iczQIwWYs21ci3u 5g+N/JdGGIQB4YTHPRGNZu4N3rXz8741BInFtSHaDgM/+lP3AFJRjdymXdqSXXdOoXKW Ys2g== X-Received: by 10.70.126.161 with SMTP id mz1mr34994378pdb.14.1417532792857; Tue, 02 Dec 2014 07:06:32 -0800 (PST) Received: from Tobys-MacBook-Pro.local (106-68-106-251.dyn.iinet.net.au. [106.68.106.251]) by mx.google.com with ESMTPSA id wi15sm9741776pac.21.2014.12.02.07.06.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 07:06:31 -0800 (PST) Message-ID: <547DD56E.8090104@gmail.com> Date: Tue, 02 Dec 2014 23:06:22 +0800 From: Toby Moore User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Thomas Leonard References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4441208983521181167==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============4441208983521181167== Content-Type: multipart/alternative; boundary="------------080505070005080604060106" This is a multi-part message in MIME format. --------------080505070005080604060106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I've just added a github issue (https://github.com/mirage/mirage/issues/333). I'm on a mac, doing my dev in a linux vm which won't support xen inside Parallels. If I get a chance this weekend I'll try out the OS X hosting that I've seen going past on here. I have just tried adding `Xen -> ["mirage-clock-xen"] for the ocamlfind stuff on AWS but it doesn't seem to make a difference, compiles fine but again fails at runtime. Looking more closely at the error and my code, possibly it's the not the time call or a missing dependency but the conversion? My code is doing `Clock.gmtime (Clock.time ())`. I've found this reference here: https://github.com/mirage/mirage-clock/blob/master/xen/clock.ml#L30 but I'm not sure what that gets linked to. > Thomas Leonard > 2 December 2014 9:42 pm > On 2 December 2014 at 13:12, Anil Madhavapeddy wrote: >> On 2 Dec 2014, at 12:36, Toby Moore wrote: >>> Hi everyone, >>> >>> I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. >> Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) >> >>> One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: >>> >>> Unsupported function gmtime called in Mini-OS kernel >>> Do_exit called! >>> base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 >>> Page fault in pagetable walk (access to invalid memory?). > > You're using Clock.time () for this, I assume? I added this to the > start of mirage-skeleton/ethifv4/unikernel.ml (which I guess is where > you copied the code from): > > let start c net = > C.log_s c (Printf.sprintf "Time is %f\n" @@ Clock.time ())>>= fun () -> > > and it printed 1417522247.474221 (which is the correct time) when I > ran it under Xen. I'm running Xen in VirtualBox for local testing, > which seems to work well. > > Perhaps something else you're using has added a dependency on > mirage-clock-unix somehow? > >> That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? >> >>> This is built with OCaml 4.01.0 with these OPAM packages: >>> io-page 1.1.1 Allocate memory pages suitable for aligned I/O >>> mirage 2.0.1 The Mirage library operating system >>> mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix >>> mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen >>> mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo >>> mirage-console 2.0.0 A Mirage-compatible Console library for Xen an >>> mirage-dns 2.0.0 Virtual package for the Mirage DNS transports >>> mirage-http 2.0.0 Mirage HTTP client and server driver for Unix >>> mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt >>> mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen >>> mirage-types 2.0.1 Module type definitions for Mirage-compatible >>> mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati >>> mirage-unix 2.0.0 Mirage OS library for Unix compilation >>> mirage-xen 2.0.0 Mirage OS library for Xen compilation >>> mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library >>> >>> I'm not directly passing a clock device, my config.ml has these bits in it: >>> >>> let main = >>> foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) >>> >>> let unix_libs = >>> match get_mode () with >>> | `Unix -> ["mirage-clock-unix"] >>> | _ -> [] >>> >>> let () = >>> add_to_ocamlfind_libraries unix_libs; >>> ... >>> >>> This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? >> Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. >> >> -anil >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > Anil Madhavapeddy > 2 December 2014 9:12 pm > On 2 Dec 2014, at 12:36, Toby Moore wrote: >> Hi everyone, >> >> I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. > > Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) > >> One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: >> >> Unsupported function gmtime called in Mini-OS kernel >> Do_exit called! >> base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 >> Page fault in pagetable walk (access to invalid memory?). > > That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? > >> This is built with OCaml 4.01.0 with these OPAM packages: >> io-page 1.1.1 Allocate memory pages suitable for aligned I/O >> mirage 2.0.1 The Mirage library operating system >> mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix >> mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen >> mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo >> mirage-console 2.0.0 A Mirage-compatible Console library for Xen an >> mirage-dns 2.0.0 Virtual package for the Mirage DNS transports >> mirage-http 2.0.0 Mirage HTTP client and server driver for Unix >> mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt >> mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen >> mirage-types 2.0.1 Module type definitions for Mirage-compatible >> mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati >> mirage-unix 2.0.0 Mirage OS library for Unix compilation >> mirage-xen 2.0.0 Mirage OS library for Xen compilation >> mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library >> >> I'm not directly passing a clock device, my config.ml has these bits in it: >> >> let main = >> foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) >> >> let unix_libs = >> match get_mode () with >> | `Unix -> ["mirage-clock-unix"] >> | _ -> [] >> >> let () = >> add_to_ocamlfind_libraries unix_libs; >> ... >> >> This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? > > Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. > > -anil > Toby Moore > 2 December 2014 8:36 pm > Hi everyone, > > I've been following this mailing list for a while now. I've finally > managed to get a simple blog running on Mirage and AWS. I've put up a > couple of posts of my experience (http://is-awesome.net) but I doubt > there'll be anything that's new or exciting to readers here. > > One outstanding issue is that I can't seem to get the CLOCK working > properly on AWS. It's fine for a unix build, but I don't have another > xen host available right now and the deploy test cycle to AWS is > pretty painful. Trying to get the current time on AWS gets me this: > > Unsupported function gmtime called in Mini-OS kernel > Do_exit called! > base is 0x0 Page fault at linear address 8, rip cb67, regs > 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 > Page fault in pagetable walk (access to invalid memory?). > > This is built with OCaml 4.01.0 with these OPAM packages: > io-page 1.1.1 Allocate memory pages suitable > for aligned I/O > mirage 2.0.1 The Mirage library operating system > mirage-clock-unix 1.0.0 A Mirage-compatible Clock > library for Unix > mirage-clock-xen 1.0.0 A Mirage-compatible Clock > library for Xen > mirage-conduit 2.0.0 Virtual package for the Mirage > Conduit transpo > mirage-console 2.0.0 A Mirage-compatible Console > library for Xen an > mirage-dns 2.0.0 Virtual package for the Mirage > DNS transports > mirage-http 2.0.0 Mirage HTTP client and server > driver for Unix > mirage-net-unix 1.1.1 Ethernet network driver for > Mirage, using tunt > mirage-net-xen 1.1.3 Ethernet network device driver > for Mirage/Xen > mirage-types 2.0.1 Module type definitions for > Mirage-compatible > mirage-types-lwt 2.0.1 Lwt module type definitions for > Mirage-compati > mirage-unix 2.0.0 Mirage OS library for Unix > compilation > mirage-xen 2.0.0 Mirage OS library for Xen > compilation > mirage-xen-minios 0.4.2 Xen MiniOS guest operating > system library > > I'm not directly passing a clock device, my config.ml has these bits > in it: > > let main = > foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro > @-> job) > > let unix_libs = > match get_mode () with > | `Unix -> ["mirage-clock-unix"] > | _ -> [] > > let () = > add_to_ocamlfind_libraries unix_libs; > ... > > This is mostly copied out of the skeleton examples. I know the clock > interface has been changing a bit recently but it works fine under > unix. My guess is that the clock driver is skipped because it's not > referenced (except in my code) but I'm not sure how to do that > properly. How can I force it to be included? > > Thanks, > Toby > --------------080505070005080604060106 Content-Type: multipart/related; boundary="------------020503000201060006070001" --------------020503000201060006070001 Content-Type: text/html; charset=UTF-8 Content-Length: 18308 Content-Transfer-Encoding: quoted-printable I've just added a github issue (https://github.com/mirage/mirage/issues/333).

I'm on a mac, doing my dev in a linux vm which won't support xen inside Parallels. If I get a chance this weekend I'll try out the OS X hosting that I've seen going past on here.

I have just tried adding `Xen -> ["mirage-clock-xen"] for the ocamlfind stuff on AWS but it doesn't seem to make a difference, compiles fine but again fails at runtime.

Looking more closely at the error and my code, possibly it's the not the time call or a missing dependency but the conversion=3F My code is doing `Clock.gmtime (Clock.time ())`. I've found this reference here: https://github.com/mirage/mirage-clock/blob/master/xen/clock.ml#L30 but I'm not sure what that gets linked to.
2 December 2014 9:42 pm
On 2 December 2014 at 13:12, Anil Madhavapeddy <anil@recoil.org> wrote:

On 2 Dec 2014, at 12:36, Toby Moore <toby.moore.0@gmail.com> wrote:

Hi everyone,

I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here.

Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-)


One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this:

   Unsupported function gmtime called in Mini-OS kernel
   Do_exit called!
   base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0
   Page fault in pagetable walk (access to invalid memory=3F).


You're using Clock.time () for this, I assume=3F I added this to the
start of mirage-skeleton/ethifv4/unikernel.ml (which I guess is where
you copied the code from):

  let start c net =3D
    C.log_s c (Printf.sprintf "Time is %f\n" @@ Clock.time ()) >>=3D fun () ->

and it printed 1417522247.474221 (which is the correct time) when I
ran it under Xen. I'm running Xen in VirtualBox for local testing,
which seems to work well.

Perhaps something else you're using has added a dependency on
mirage-clock-unix somehow=3F


That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library.  We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues =3F


This is built with OCaml 4.01.0 with these OPAM packages:
   io-page                    1.1.1  Allocate memory pages suitable for aligned I/O
   mirage                     2.0.1  The Mirage library operating system
   mirage-clock-unix          1.0.0  A Mirage-compatible Clock library for Unix
   mirage-clock-xen           1.0.0  A Mirage-compatible Clock library for Xen
   mirage-conduit             2.0.0  Virtual package for the Mirage Conduit transpo
   mirage-console             2.0.0  A Mirage-compatible Console library for Xen an
   mirage-dns                 2.0.0  Virtual package for the Mirage DNS transports
   mirage-http                2.0.0  Mirage HTTP client and server driver for Unix
   mirage-net-unix            1.1.1  Ethernet network driver for Mirage, using tunt
   mirage-net-xen             1.1.3  Ethernet network device driver for Mirage/Xen
   mirage-types               2.0.1  Module type definitions for Mirage-compatible
   mirage-types-lwt           2.0.1  Lwt module type definitions for Mirage-compati
   mirage-unix                2.0.0  Mirage OS library for Unix compilation
   mirage-xen                 2.0.0  Mirage OS library for Xen compilation
   mirage-xen-minios          0.4.2  Xen MiniOS guest operating system library

I'm not directly passing a clock device, my config.ml has these bits in it:

   let main =3D
     foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job)

   let unix_libs =3D
     match get_mode () with
     | `Unix -> ["mirage-clock-unix"]
     | _ -> []

   let () =3D
       add_to_ocamlfind_libraries unix_libs;
       ...

This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included=3F

Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once.

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
2 December 2014 9:12 pm
On 2 Dec 2014, at 12:36, Toby Moore <toby.moore.0@gmail.com> wrote:

Hi everyone,

I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here.


Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-)


One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this:

   Unsupported function gmtime called in Mini-OS kernel
   Do_exit called!
   base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0
   Page fault in pagetable walk (access to invalid memory=3F).


That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library.  We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues =3F


This is built with OCaml 4.01.0 with these OPAM packages:
   io-page                    1.1.1  Allocate memory pages suitable for aligned I/O
   mirage                     2.0.1  The Mirage library operating system
   mirage-clock-unix          1.0.0  A Mirage-compatible Clock library for Unix
   mirage-clock-xen           1.0.0  A Mirage-compatible Clock library for Xen
   mirage-conduit             2.0.0  Virtual package for the Mirage Conduit transpo
   mirage-console             2.0.0  A Mirage-compatible Console library for Xen an
   mirage-dns                 2.0.0  Virtual package for the Mirage DNS transports
   mirage-http                2.0.0  Mirage HTTP client and server driver for Unix
   mirage-net-unix            1.1.1  Ethernet network driver for Mirage, using tunt
   mirage-net-xen             1.1.3  Ethernet network device driver for Mirage/Xen
   mirage-types               2.0.1  Module type definitions for Mirage-compatible
   mirage-types-lwt           2.0.1  Lwt module type definitions for Mirage-compati
   mirage-unix                2.0.0  Mirage OS library for Unix compilation
   mirage-xen                 2.0.0  Mirage OS library for Xen compilation
   mirage-xen-minios          0.4.2  Xen MiniOS guest operating system library

I'm not directly passing a clock device, my config.ml has these bits in it:

   let main =3D
     foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job)

   let unix_libs =3D
     match get_mode () with
     | `Unix -> ["mirage-clock-unix"]
     | _ -> []

   let () =3D
       add_to_ocamlfind_libraries unix_libs;
       ...

This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included=3F


Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once.

-anil
2 December 2014 8:36 pm
Hi everyone,

I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here.

One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this:

=C2=A0=C2=A0=C2=A0 Unsupported function gmtime called in Mini-OS kernel
=C2=A0=C2=A0=C2=A0 Do_exit called!
=C2=A0=C2=A0=C2=A0 base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0
=C2=A0=C2=A0=C2=A0 Page fault in pagetable walk (access to invalid memory=3F).

This is built with OCaml 4.01.0 with these OPAM packages:
=C2=A0=C2=A0=C2=A0 io-page=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.1=C2=A0 Allocate memory pages suitable for aligned I/O
=C2=A0=C2=A0=C2=A0 mirage=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.1=C2=A0 The Mirage library operating system
=C2=A0=C2=A0=C2=A0 mirage-clock-unix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.0.0=C2=A0 A Mirage-compatible Clock library for Unix
=C2=A0=C2=A0=C2=A0 mirage-clock-xen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.0.0=C2=A0 A Mirage-compatible Clock library for Xen
=C2=A0=C2=A0=C2=A0 mirage-conduit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Virtual package for the Mirage Conduit transpo
=C2=A0=C2=A0=C2=A0 mirage-console=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 A Mirage-compatible Console library for Xen an
=C2=A0=C2=A0=C2=A0 mirage-dns=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Virtual package for the Mirage DNS transports
=C2=A0=C2=A0=C2=A0 mirage-http=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Mirage HTTP client and server driver for Unix
=C2=A0=C2=A0=C2=A0 mirage-net-unix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.1=C2=A0 Ethernet network driver for Mirage, using tunt
=C2=A0=C2=A0=C2=A0 mirage-net-xen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.3=C2=A0 Ethernet network device driver for Mirage/Xen
=C2=A0=C2=A0=C2=A0 mirage-types=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.1=C2=A0 Module type definitions for Mirage-compatible
=C2=A0=C2=A0=C2=A0 mirage-types-lwt=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.1=C2=A0 Lwt module type definitions for Mirage-compati
=C2=A0=C2=A0=C2=A0 mirage-unix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Mirage OS library for Unix compilation
=C2=A0=C2=A0=C2=A0 mirage-xen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Mirage OS library for Xen compilation
=C2=A0=C2=A0=C2=A0 mirage-xen-minios=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.4.2=C2=A0 Xen MiniOS guest operating system library

I'm not directly passing a clock device, my config.ml has these bits in it:

=C2=A0=C2=A0=C2=A0 let main =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job)

=C2=A0=C2=A0=C2=A0 let unix_libs =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 match get_mode () with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | `Unix -> ["mirage-clock-unix"]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | _ -> []

=C2=A0=C2=A0=C2=A0 let () =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add_to_ocamlfind_libraries unix_libs;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...

This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included=3F

Thanks,
Toby

--------------020503000201060006070001 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDv/BOp6hqvhG41qPUdN1HxJrVtFcC7urNJ 54k8qMzM7FO8j8DJAyAOBgfPYP8AeVHUi9Xv1/E2yuknTdSXU6nSfhB4cvNKTVPEqWr6gy7g IdPt0CuRy3EfJr6CVNcl2dyiovQ8TsfEejeGviLe/D2CSPUNXN15kE72cHmwRpyIkZEDKG45 ByCB0zmvm83jCy9nrJPbo/u/A4cXh3Je1W6/LsZH/DRf7TX/AEPJ/KD/AArzfrmN/lX4f5nL r3Oy8Dar4z0f4eTr4JbSry4g02xjE944b55Io2ZVwSoVAvTJbJbIBFezlPvuUvtdfLToehld KKo8sZX1f9fMvz638fvN01R4y8PyJcwCS4gtYgAmV5B3FssPwHPSvWnOT0Uj1XRT3RwT/CqX SPiInxS1TXLS71iWRIpNsZhjExwmY0Vs/MC3OTjGcGvCqScKkql1a/zM3SpuE1VfT0sfPH/C b6X/AHW/8CG/xr2PqMPL7j5v2S7M/Trxp8IfDWqfATR18E2UtnqenWtrdXKRwBHYpCEmUgAZ dTu+VucqR1reWFVOLnFW7ndgcRGhU5V1PkOyvfht4E+XT/F0d/qFzdLEbGxiBaU5OPMGN3GT wCAK8jE1aFGPPF/d1Pp61WVSNrWPoP4da38LPCfw41fxv8VrC1+1RTg20Rc+ZFCqbkRAOQzM TzwOOTxWuWUlOnKrXVnfRHmUsBis0xMcLhl8+nz8j4282z/6IH4t/wDAKX/43Xq88Tr/ANW5 f8/kfUv7SP8AyVXxh/13/wDaS10y+D5Hyq+Nep+ex/5Kfff9dz/6Ea+fl8a9T3Z7I9G03/ke dB/7Cmk/+lgr0I/Czryb/fP+3ZfkfrZWoz//2Q== --------------020503000201060006070001 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1P41+K9H+OfxGT4aX2r2Q8L6DaW39twTR wY1XU5I1kZZXkHzKm4KEyF3Z4OBgA4j4pQaB8BTY6Z8O9FfTNeuIjMh0nT7aNba3I4aWV1WE A9lJJOPSgD6y/ZC+J1h8cvhWNR8R6Ppa+J9Cum0zVXt7RIfOYKrxXKBR8nmRspIHCuHA6UAN /wCFneK/+g5N/wCO/wCFAHwR4m+EWrXv7Tup6L4fGl6ldX5s9XgTVbfzbZI7q1jkcKGGDIkh IJ9Ao45yAehXHhTRbOd7T4k6trOp2Wl38umaxLE4kgihQ5tmjYsQCMsCu3gDqMDIB7F8CrTT vBPxxstO+HOmySaV4ks4JhIF2n7DCCr7h0wpdCDntgZyKAF/tj/aoA0fix8G/FN3ofhX41eC YxfNoGi276rpECEXspSCOOYQ4GWdRGpMZIIMbAAlsUAeE/Brx9Y6le+L/BWij93eiW7tLiJi bicMMkynhsLwNqug7MCSaAHfst/GZdN/aM8Paf4julOn6Rptx4dkvJH2rC8zAxs5zgEsgB9N 1AHoX9leK/8AoWtV/wDAOT/4mgCx8d/+Su+JP+vtf/RaUAfm+3/JQPGP/Xzf/wDo00AW/wBm z/koPh3/ALGrTf8A0qioA/oHoA//2Q== --------------020503000201060006070001 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020503000201060006070001-- --------------080505070005080604060106-- --===============4441208983521181167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4441208983521181167==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 15:06:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 15:06:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvp2F-00071l-M3; Tue, 02 Dec 2014 15:06:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvp2D-00071R-Sm for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 15:06:38 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 1E/EB-09842-D75DD745; Tue, 02 Dec 2014 15:06:37 +0000 X-Env-Sender: toby.moore.0@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1417532793!12903486!1 X-Originating-IP: [209.85.192.170] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11918 invoked from network); 2 Dec 2014 15:06:34 -0000 Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 15:06:34 -0000 Received: by mail-pd0-f170.google.com with SMTP id fp1so13380873pdb.29 for ; Tue, 02 Dec 2014 07:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=yj/mTgxMEcWAPJYNAYTnxoZ9tgUJgxEWpBEHGjV/naM=; b=OoRrQ5Qr8Oak+az/eaQLCVR1jbzQ0AlmteUpSqVCtwZGpbzEykB/Tnt94Xj+WCpls5 g6JB/Cr9N6eQBGT7Pf4BPk636/9BalBPZiYR1gkHSf5h9uxcFEWvo1B3yDwapZ5PH3UT 0tJpsRdDZhaMqhaL8PyLWz1KJUYObIIE4wbR2DVOdDPJ85hhQTZ77iuHRtC3Nv3asiR5 n37rywekPqoNUHC0xo1j4m2dUuilEylS0s+rYmQZjwiWpYsWoH5o9iczQIwWYs21ci3u 5g+N/JdGGIQB4YTHPRGNZu4N3rXz8741BInFtSHaDgM/+lP3AFJRjdymXdqSXXdOoXKW Ys2g== X-Received: by 10.70.126.161 with SMTP id mz1mr34994378pdb.14.1417532792857; Tue, 02 Dec 2014 07:06:32 -0800 (PST) Received: from Tobys-MacBook-Pro.local (106-68-106-251.dyn.iinet.net.au. [106.68.106.251]) by mx.google.com with ESMTPSA id wi15sm9741776pac.21.2014.12.02.07.06.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 07:06:31 -0800 (PST) Message-ID: <547DD56E.8090104@gmail.com> Date: Tue, 02 Dec 2014 23:06:22 +0800 From: Toby Moore User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Thomas Leonard References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4441208983521181167==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============4441208983521181167== Content-Type: multipart/alternative; boundary="------------080505070005080604060106" This is a multi-part message in MIME format. --------------080505070005080604060106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I've just added a github issue (https://github.com/mirage/mirage/issues/333). I'm on a mac, doing my dev in a linux vm which won't support xen inside Parallels. If I get a chance this weekend I'll try out the OS X hosting that I've seen going past on here. I have just tried adding `Xen -> ["mirage-clock-xen"] for the ocamlfind stuff on AWS but it doesn't seem to make a difference, compiles fine but again fails at runtime. Looking more closely at the error and my code, possibly it's the not the time call or a missing dependency but the conversion? My code is doing `Clock.gmtime (Clock.time ())`. I've found this reference here: https://github.com/mirage/mirage-clock/blob/master/xen/clock.ml#L30 but I'm not sure what that gets linked to. > Thomas Leonard > 2 December 2014 9:42 pm > On 2 December 2014 at 13:12, Anil Madhavapeddy wrote: >> On 2 Dec 2014, at 12:36, Toby Moore wrote: >>> Hi everyone, >>> >>> I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. >> Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) >> >>> One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: >>> >>> Unsupported function gmtime called in Mini-OS kernel >>> Do_exit called! >>> base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 >>> Page fault in pagetable walk (access to invalid memory?). > > You're using Clock.time () for this, I assume? I added this to the > start of mirage-skeleton/ethifv4/unikernel.ml (which I guess is where > you copied the code from): > > let start c net = > C.log_s c (Printf.sprintf "Time is %f\n" @@ Clock.time ())>>= fun () -> > > and it printed 1417522247.474221 (which is the correct time) when I > ran it under Xen. I'm running Xen in VirtualBox for local testing, > which seems to work well. > > Perhaps something else you're using has added a dependency on > mirage-clock-unix somehow? > >> That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? >> >>> This is built with OCaml 4.01.0 with these OPAM packages: >>> io-page 1.1.1 Allocate memory pages suitable for aligned I/O >>> mirage 2.0.1 The Mirage library operating system >>> mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix >>> mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen >>> mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo >>> mirage-console 2.0.0 A Mirage-compatible Console library for Xen an >>> mirage-dns 2.0.0 Virtual package for the Mirage DNS transports >>> mirage-http 2.0.0 Mirage HTTP client and server driver for Unix >>> mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt >>> mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen >>> mirage-types 2.0.1 Module type definitions for Mirage-compatible >>> mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati >>> mirage-unix 2.0.0 Mirage OS library for Unix compilation >>> mirage-xen 2.0.0 Mirage OS library for Xen compilation >>> mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library >>> >>> I'm not directly passing a clock device, my config.ml has these bits in it: >>> >>> let main = >>> foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) >>> >>> let unix_libs = >>> match get_mode () with >>> | `Unix -> ["mirage-clock-unix"] >>> | _ -> [] >>> >>> let () = >>> add_to_ocamlfind_libraries unix_libs; >>> ... >>> >>> This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? >> Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. >> >> -anil >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > Anil Madhavapeddy > 2 December 2014 9:12 pm > On 2 Dec 2014, at 12:36, Toby Moore wrote: >> Hi everyone, >> >> I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here. > > Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-) > >> One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this: >> >> Unsupported function gmtime called in Mini-OS kernel >> Do_exit called! >> base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 >> Page fault in pagetable walk (access to invalid memory?). > > That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library. We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues ? > >> This is built with OCaml 4.01.0 with these OPAM packages: >> io-page 1.1.1 Allocate memory pages suitable for aligned I/O >> mirage 2.0.1 The Mirage library operating system >> mirage-clock-unix 1.0.0 A Mirage-compatible Clock library for Unix >> mirage-clock-xen 1.0.0 A Mirage-compatible Clock library for Xen >> mirage-conduit 2.0.0 Virtual package for the Mirage Conduit transpo >> mirage-console 2.0.0 A Mirage-compatible Console library for Xen an >> mirage-dns 2.0.0 Virtual package for the Mirage DNS transports >> mirage-http 2.0.0 Mirage HTTP client and server driver for Unix >> mirage-net-unix 1.1.1 Ethernet network driver for Mirage, using tunt >> mirage-net-xen 1.1.3 Ethernet network device driver for Mirage/Xen >> mirage-types 2.0.1 Module type definitions for Mirage-compatible >> mirage-types-lwt 2.0.1 Lwt module type definitions for Mirage-compati >> mirage-unix 2.0.0 Mirage OS library for Unix compilation >> mirage-xen 2.0.0 Mirage OS library for Xen compilation >> mirage-xen-minios 0.4.2 Xen MiniOS guest operating system library >> >> I'm not directly passing a clock device, my config.ml has these bits in it: >> >> let main = >> foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job) >> >> let unix_libs = >> match get_mode () with >> | `Unix -> ["mirage-clock-unix"] >> | _ -> [] >> >> let () = >> add_to_ocamlfind_libraries unix_libs; >> ... >> >> This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included? > > Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once. > > -anil > Toby Moore > 2 December 2014 8:36 pm > Hi everyone, > > I've been following this mailing list for a while now. I've finally > managed to get a simple blog running on Mirage and AWS. I've put up a > couple of posts of my experience (http://is-awesome.net) but I doubt > there'll be anything that's new or exciting to readers here. > > One outstanding issue is that I can't seem to get the CLOCK working > properly on AWS. It's fine for a unix build, but I don't have another > xen host available right now and the deploy test cycle to AWS is > pretty painful. Trying to get the current time on AWS gets me this: > > Unsupported function gmtime called in Mini-OS kernel > Do_exit called! > base is 0x0 Page fault at linear address 8, rip cb67, regs > 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0 > Page fault in pagetable walk (access to invalid memory?). > > This is built with OCaml 4.01.0 with these OPAM packages: > io-page 1.1.1 Allocate memory pages suitable > for aligned I/O > mirage 2.0.1 The Mirage library operating system > mirage-clock-unix 1.0.0 A Mirage-compatible Clock > library for Unix > mirage-clock-xen 1.0.0 A Mirage-compatible Clock > library for Xen > mirage-conduit 2.0.0 Virtual package for the Mirage > Conduit transpo > mirage-console 2.0.0 A Mirage-compatible Console > library for Xen an > mirage-dns 2.0.0 Virtual package for the Mirage > DNS transports > mirage-http 2.0.0 Mirage HTTP client and server > driver for Unix > mirage-net-unix 1.1.1 Ethernet network driver for > Mirage, using tunt > mirage-net-xen 1.1.3 Ethernet network device driver > for Mirage/Xen > mirage-types 2.0.1 Module type definitions for > Mirage-compatible > mirage-types-lwt 2.0.1 Lwt module type definitions for > Mirage-compati > mirage-unix 2.0.0 Mirage OS library for Unix > compilation > mirage-xen 2.0.0 Mirage OS library for Xen > compilation > mirage-xen-minios 0.4.2 Xen MiniOS guest operating > system library > > I'm not directly passing a clock device, my config.ml has these bits > in it: > > let main = > foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro > @-> job) > > let unix_libs = > match get_mode () with > | `Unix -> ["mirage-clock-unix"] > | _ -> [] > > let () = > add_to_ocamlfind_libraries unix_libs; > ... > > This is mostly copied out of the skeleton examples. I know the clock > interface has been changing a bit recently but it works fine under > unix. My guess is that the clock driver is skipped because it's not > referenced (except in my code) but I'm not sure how to do that > properly. How can I force it to be included? > > Thanks, > Toby > --------------080505070005080604060106 Content-Type: multipart/related; boundary="------------020503000201060006070001" --------------020503000201060006070001 Content-Type: text/html; charset=UTF-8 Content-Length: 18308 Content-Transfer-Encoding: quoted-printable I've just added a github issue (https://github.com/mirage/mirage/issues/333).

I'm on a mac, doing my dev in a linux vm which won't support xen inside Parallels. If I get a chance this weekend I'll try out the OS X hosting that I've seen going past on here.

I have just tried adding `Xen -> ["mirage-clock-xen"] for the ocamlfind stuff on AWS but it doesn't seem to make a difference, compiles fine but again fails at runtime.

Looking more closely at the error and my code, possibly it's the not the time call or a missing dependency but the conversion=3F My code is doing `Clock.gmtime (Clock.time ())`. I've found this reference here: https://github.com/mirage/mirage-clock/blob/master/xen/clock.ml#L30 but I'm not sure what that gets linked to.
2 December 2014 9:42 pm
On 2 December 2014 at 13:12, Anil Madhavapeddy <anil@recoil.org> wrote:

On 2 Dec 2014, at 12:36, Toby Moore <toby.moore.0@gmail.com> wrote:

Hi everyone,

I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here.

Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-)


One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this:

   Unsupported function gmtime called in Mini-OS kernel
   Do_exit called!
   base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0
   Page fault in pagetable walk (access to invalid memory=3F).


You're using Clock.time () for this, I assume=3F I added this to the
start of mirage-skeleton/ethifv4/unikernel.ml (which I guess is where
you copied the code from):

  let start c net =3D
    C.log_s c (Printf.sprintf "Time is %f\n" @@ Clock.time ()) >>=3D fun () ->

and it printed 1417522247.474221 (which is the correct time) when I
ran it under Xen. I'm running Xen in VirtualBox for local testing,
which seems to work well.

Perhaps something else you're using has added a dependency on
mirage-clock-unix somehow=3F


That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library.  We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues =3F


This is built with OCaml 4.01.0 with these OPAM packages:
   io-page                    1.1.1  Allocate memory pages suitable for aligned I/O
   mirage                     2.0.1  The Mirage library operating system
   mirage-clock-unix          1.0.0  A Mirage-compatible Clock library for Unix
   mirage-clock-xen           1.0.0  A Mirage-compatible Clock library for Xen
   mirage-conduit             2.0.0  Virtual package for the Mirage Conduit transpo
   mirage-console             2.0.0  A Mirage-compatible Console library for Xen an
   mirage-dns                 2.0.0  Virtual package for the Mirage DNS transports
   mirage-http                2.0.0  Mirage HTTP client and server driver for Unix
   mirage-net-unix            1.1.1  Ethernet network driver for Mirage, using tunt
   mirage-net-xen             1.1.3  Ethernet network device driver for Mirage/Xen
   mirage-types               2.0.1  Module type definitions for Mirage-compatible
   mirage-types-lwt           2.0.1  Lwt module type definitions for Mirage-compati
   mirage-unix                2.0.0  Mirage OS library for Unix compilation
   mirage-xen                 2.0.0  Mirage OS library for Xen compilation
   mirage-xen-minios          0.4.2  Xen MiniOS guest operating system library

I'm not directly passing a clock device, my config.ml has these bits in it:

   let main =3D
     foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job)

   let unix_libs =3D
     match get_mode () with
     | `Unix -> ["mirage-clock-unix"]
     | _ -> []

   let () =3D
       add_to_ocamlfind_libraries unix_libs;
       ...

This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included=3F

Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once.

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
2 December 2014 9:12 pm
On 2 Dec 2014, at 12:36, Toby Moore <toby.moore.0@gmail.com> wrote:

Hi everyone,

I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here.


Not at all -- I just discovered the Pure CSS framework from reading it -- I was just wondering what to do while converting my own blog :-)


One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this:

   Unsupported function gmtime called in Mini-OS kernel
   Do_exit called!
   base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0
   Page fault in pagetable walk (access to invalid memory=3F).


That's almost certainly some unexpected fallout due to the switch to MiniOS-as-a-library.  We'll definitely want this working on Amazon's Xen interface version! Any chance you could put this bug report up on https://github.com/mirage/mirage/issues =3F


This is built with OCaml 4.01.0 with these OPAM packages:
   io-page                    1.1.1  Allocate memory pages suitable for aligned I/O
   mirage                     2.0.1  The Mirage library operating system
   mirage-clock-unix          1.0.0  A Mirage-compatible Clock library for Unix
   mirage-clock-xen           1.0.0  A Mirage-compatible Clock library for Xen
   mirage-conduit             2.0.0  Virtual package for the Mirage Conduit transpo
   mirage-console             2.0.0  A Mirage-compatible Console library for Xen an
   mirage-dns                 2.0.0  Virtual package for the Mirage DNS transports
   mirage-http                2.0.0  Mirage HTTP client and server driver for Unix
   mirage-net-unix            1.1.1  Ethernet network driver for Mirage, using tunt
   mirage-net-xen             1.1.3  Ethernet network device driver for Mirage/Xen
   mirage-types               2.0.1  Module type definitions for Mirage-compatible
   mirage-types-lwt           2.0.1  Lwt module type definitions for Mirage-compati
   mirage-unix                2.0.0  Mirage OS library for Unix compilation
   mirage-xen                 2.0.0  Mirage OS library for Xen compilation
   mirage-xen-minios          0.4.2  Xen MiniOS guest operating system library

I'm not directly passing a clock device, my config.ml has these bits in it:

   let main =3D
     foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job)

   let unix_libs =3D
     match get_mode () with
     | `Unix -> ["mirage-clock-unix"]
     | _ -> []

   let () =3D
       add_to_ocamlfind_libraries unix_libs;
       ...

This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included=3F


Over to Thomas for this -- the CLOCK interface is a little special since it's only ever instantiated once.

-anil
2 December 2014 8:36 pm
Hi everyone,

I've been following this mailing list for a while now. I've finally managed to get a simple blog running on Mirage and AWS. I've put up a couple of posts of my experience (http://is-awesome.net) but I doubt there'll be anything that's new or exciting to readers here.

One outstanding issue is that I can't seem to get the CLOCK working properly on AWS. It's fine for a unix build, but I don't have another xen host available right now and the deploy test cycle to AWS is pretty painful. Trying to get the current time on AWS gets me this:

=C2=A0=C2=A0=C2=A0 Unsupported function gmtime called in Mini-OS kernel
=C2=A0=C2=A0=C2=A0 Do_exit called!
=C2=A0=C2=A0=C2=A0 base is 0x0 Page fault at linear address 8, rip cb67, regs 000000000034f908, sp 34f9b0, our_sp 000000000034f8c8, code 0
=C2=A0=C2=A0=C2=A0 Page fault in pagetable walk (access to invalid memory=3F).

This is built with OCaml 4.01.0 with these OPAM packages:
=C2=A0=C2=A0=C2=A0 io-page=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.1=C2=A0 Allocate memory pages suitable for aligned I/O
=C2=A0=C2=A0=C2=A0 mirage=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.1=C2=A0 The Mirage library operating system
=C2=A0=C2=A0=C2=A0 mirage-clock-unix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.0.0=C2=A0 A Mirage-compatible Clock library for Unix
=C2=A0=C2=A0=C2=A0 mirage-clock-xen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.0.0=C2=A0 A Mirage-compatible Clock library for Xen
=C2=A0=C2=A0=C2=A0 mirage-conduit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Virtual package for the Mirage Conduit transpo
=C2=A0=C2=A0=C2=A0 mirage-console=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 A Mirage-compatible Console library for Xen an
=C2=A0=C2=A0=C2=A0 mirage-dns=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Virtual package for the Mirage DNS transports
=C2=A0=C2=A0=C2=A0 mirage-http=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Mirage HTTP client and server driver for Unix
=C2=A0=C2=A0=C2=A0 mirage-net-unix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.1=C2=A0 Ethernet network driver for Mirage, using tunt
=C2=A0=C2=A0=C2=A0 mirage-net-xen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.3=C2=A0 Ethernet network device driver for Mirage/Xen
=C2=A0=C2=A0=C2=A0 mirage-types=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.1=C2=A0 Module type definitions for Mirage-compatible
=C2=A0=C2=A0=C2=A0 mirage-types-lwt=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.1=C2=A0 Lwt module type definitions for Mirage-compati
=C2=A0=C2=A0=C2=A0 mirage-unix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Mirage OS library for Unix compilation
=C2=A0=C2=A0=C2=A0 mirage-xen=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.0.0=C2=A0 Mirage OS library for Xen compilation
=C2=A0=C2=A0=C2=A0 mirage-xen-minios=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.4.2=C2=A0 Xen MiniOS guest operating system library

I'm not directly passing a clock device, my config.ml has these bits in it:

=C2=A0=C2=A0=C2=A0 let main =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 foreign "Unikernel.Main" (http @-> console @-> kv_ro @-> kv_ro @-> job)

=C2=A0=C2=A0=C2=A0 let unix_libs =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 match get_mode () with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | `Unix -> ["mirage-clock-unix"]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | _ -> []

=C2=A0=C2=A0=C2=A0 let () =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add_to_ocamlfind_libraries unix_libs;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...

This is mostly copied out of the skeleton examples. I know the clock interface has been changing a bit recently but it works fine under unix. My guess is that the clock driver is skipped because it's not referenced (except in my code) but I'm not sure how to do that properly. How can I force it to be included=3F

Thanks,
Toby

--------------020503000201060006070001 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDv/BOp6hqvhG41qPUdN1HxJrVtFcC7urNJ 54k8qMzM7FO8j8DJAyAOBgfPYP8AeVHUi9Xv1/E2yuknTdSXU6nSfhB4cvNKTVPEqWr6gy7g IdPt0CuRy3EfJr6CVNcl2dyiovQ8TsfEejeGviLe/D2CSPUNXN15kE72cHmwRpyIkZEDKG45 ByCB0zmvm83jCy9nrJPbo/u/A4cXh3Je1W6/LsZH/DRf7TX/AEPJ/KD/AArzfrmN/lX4f5nL r3Oy8Dar4z0f4eTr4JbSry4g02xjE944b55Io2ZVwSoVAvTJbJbIBFezlPvuUvtdfLToehld KKo8sZX1f9fMvz638fvN01R4y8PyJcwCS4gtYgAmV5B3FssPwHPSvWnOT0Uj1XRT3RwT/CqX SPiInxS1TXLS71iWRIpNsZhjExwmY0Vs/MC3OTjGcGvCqScKkql1a/zM3SpuE1VfT0sfPH/C b6X/AHW/8CG/xr2PqMPL7j5v2S7M/Trxp8IfDWqfATR18E2UtnqenWtrdXKRwBHYpCEmUgAZ dTu+VucqR1reWFVOLnFW7ndgcRGhU5V1PkOyvfht4E+XT/F0d/qFzdLEbGxiBaU5OPMGN3GT wCAK8jE1aFGPPF/d1Pp61WVSNrWPoP4da38LPCfw41fxv8VrC1+1RTg20Rc+ZFCqbkRAOQzM TzwOOTxWuWUlOnKrXVnfRHmUsBis0xMcLhl8+nz8j4282z/6IH4t/wDAKX/43Xq88Tr/ANW5 f8/kfUv7SP8AyVXxh/13/wDaS10y+D5Hyq+Nep+ex/5Kfff9dz/6Ea+fl8a9T3Z7I9G03/ke dB/7Cmk/+lgr0I/Czryb/fP+3ZfkfrZWoz//2Q== --------------020503000201060006070001 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1P41+K9H+OfxGT4aX2r2Q8L6DaW39twTR wY1XU5I1kZZXkHzKm4KEyF3Z4OBgA4j4pQaB8BTY6Z8O9FfTNeuIjMh0nT7aNba3I4aWV1WE A9lJJOPSgD6y/ZC+J1h8cvhWNR8R6Ppa+J9Cum0zVXt7RIfOYKrxXKBR8nmRspIHCuHA6UAN /wCFneK/+g5N/wCO/wCFAHwR4m+EWrXv7Tup6L4fGl6ldX5s9XgTVbfzbZI7q1jkcKGGDIkh IJ9Ao45yAehXHhTRbOd7T4k6trOp2Wl38umaxLE4kgihQ5tmjYsQCMsCu3gDqMDIB7F8CrTT vBPxxstO+HOmySaV4ks4JhIF2n7DCCr7h0wpdCDntgZyKAF/tj/aoA0fix8G/FN3ofhX41eC YxfNoGi276rpECEXspSCOOYQ4GWdRGpMZIIMbAAlsUAeE/Brx9Y6le+L/BWij93eiW7tLiJi bicMMkynhsLwNqug7MCSaAHfst/GZdN/aM8Paf4julOn6Rptx4dkvJH2rC8zAxs5zgEsgB9N 1AHoX9leK/8AoWtV/wDAOT/4mgCx8d/+Su+JP+vtf/RaUAfm+3/JQPGP/Xzf/wDo00AW/wBm z/koPh3/ALGrTf8A0qioA/oHoA//2Q== --------------020503000201060006070001 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020503000201060006070001-- --------------080505070005080604060106-- --===============4441208983521181167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4441208983521181167==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:18:32 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvq9j-0005vc-8w; Tue, 02 Dec 2014 16:18:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvq9h-0005vJ-6R for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:18:25 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 60/3D-28865-056ED745; Tue, 02 Dec 2014 16:18:24 +0000 X-Env-Sender: len@inthemail.org X-Msg-Ref: server-14.tower-206.messagelabs.com!1417537102!5710541!1 X-Originating-IP: [209.85.220.181] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17263 invoked from network); 2 Dec 2014 16:18:23 -0000 Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com) (209.85.220.181) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 16:18:23 -0000 Received: by mail-vc0-f181.google.com with SMTP id le20so5849992vcb.40 for ; Tue, 02 Dec 2014 08:18:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K+brV+anXqmVs6BSoiTBi51XLaFL/hMHZjkw8bXg6UI=; b=ZTihHYB8JFzCejTgu89pAJ6zxbhO5sfT65QLZOPUntfkYlNmwGqs+wTLzQzzP5Y83C J1hKtZTdVvjYuqz9RaQn6KIHiiRoy460ttX2rsGOCcHkjgwLAP6rU762EAq/D5MOdHc3 W31zV3FsI3sgl4fdhmSTDL1TvxdOISsZ2lPwniiGkdWd7OgEyvgEoflU2MflRufpSVw2 YpJCJ1fDGPFU3w/Ww12cX5cYsfZ73nkRdbsab0BzUrfY2g0/0IHekc/wZF6oH2ArtIxf Z2zPNHnT0Pg6HkbVVh8KW5CfBqTySKDz8g1ZHqU1P2UPYvKLpSDw6HD/ffGG1dB/Yoj/ 2C5g== X-Gm-Message-State: ALoCoQkZ8cyatdeYYXlp6ge/P4KmQcefDm3khjGh6LkGyQFaHE1GHXZO9IMAmYOKp9loDxEdEswh MIME-Version: 1.0 X-Received: by 10.221.4.2 with SMTP id oa2mr50522vcb.17.1417537101902; Tue, 02 Dec 2014 08:18:21 -0800 (PST) Received: by 10.31.33.20 with HTTP; Tue, 2 Dec 2014 08:18:21 -0800 (PST) In-Reply-To: <547DD56E.8090104@gmail.com> References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> <547DD56E.8090104@gmail.com> Date: Tue, 2 Dec 2014 11:18:21 -0500 Message-ID: From: Len Maxwell To: Toby Moore Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9108356007620020070==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============9108356007620020070== Content-Type: multipart/alternative; boundary=089e013c719e6a4ceb05093e1316 --089e013c719e6a4ceb05093e1316 Content-Type: text/plain; charset=UTF-8 Hi Toby, I just built a similar example [1] and it is running OK on EC2 [2]. You might try building and deploying my code from your environment and see if you get any different result. Note that I am using the mirage-dev OPAM remote, and explicitly calling for a V1.CLOCK "device" (per #289 [3]). [1] https://github.com/lnmx/mirage-sandbox/tree/master/http-clock [2] up temporarily: http://54.145.130.16/ [3] https://github.com/mirage/mirage/issues/289 -- Len On Tue, Dec 2, 2014 at 10:06 AM, Toby Moore wrote: > I've just added a github issue ( > https://github.com/mirage/mirage/issues/333). > > I'm on a mac, doing my dev in a linux vm which won't support xen inside > Parallels. If I get a chance this weekend I'll try out the OS X hosting > that I've seen going past on here. > > I have just tried adding `Xen -> ["mirage-clock-xen"] for the ocamlfind > stuff on AWS but it doesn't seem to make a difference, compiles fine but > again fails at runtime. > > Looking more closely at the error and my code, possibly it's the not the > time call or a missing dependency but the conversion? My code is doing > `Clock.gmtime (Clock.time ())`. I've found this reference here: > https://github.com/mirage/mirage-clock/blob/master/xen/clock.ml#L30 but > I'm not sure what that gets linked to. > --089e013c719e6a4ceb05093e1316 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Toby,

I ju= st built a similar example [1] and it is running OK on EC2 [2].=C2=A0 You m= ight try building and deploying my code from your environment and see if yo= u get any different result.

Note that I am using t= he mirage-dev OPAM remote, and explicitly calling for a V1.CLOCK "devi= ce" (per #289 [3]).

[2] up t= emporarily: http://54.145.130.16/=C2= =A0


--
Len

On Tue, Dec 2, 2014 at 10:06 AM, Toby Moore <to= by.moore.0@gmail.com> wrote:
I've just added a github=20 issue (https://github.com/mirage/mirage/issues/333).

I'm on a mac, doing my dev in a linux vm which won't support xen in= side=20 Parallels. If I get a chance this weekend I'll try out the OS X hosting= =20 that I've seen going past on here.

I have just tried adding `Xen -> ["mirage-clock-xen"] for the= =20 ocamlfind stuff on AWS but it doesn't seem to make a difference,= =20 compiles fine but again fails at runtime.

Looking more closely at the error and my code, possibly it's the not th= e time call or a missing dependency but the conversion? My code is doing `Clock.gmtime (Clock.time ())`. I've found this reference here:= =20 https://github.com/mirage/mirage-clock/blob/master/x= en/clock.ml#L30 but=20 I'm not sure what that gets linked to.

--089e013c719e6a4ceb05093e1316-- --===============9108356007620020070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============9108356007620020070==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:18:32 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvq9j-0005vc-8w; Tue, 02 Dec 2014 16:18:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvq9h-0005vJ-6R for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:18:25 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 60/3D-28865-056ED745; Tue, 02 Dec 2014 16:18:24 +0000 X-Env-Sender: len@inthemail.org X-Msg-Ref: server-14.tower-206.messagelabs.com!1417537102!5710541!1 X-Originating-IP: [209.85.220.181] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17263 invoked from network); 2 Dec 2014 16:18:23 -0000 Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com) (209.85.220.181) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 16:18:23 -0000 Received: by mail-vc0-f181.google.com with SMTP id le20so5849992vcb.40 for ; Tue, 02 Dec 2014 08:18:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K+brV+anXqmVs6BSoiTBi51XLaFL/hMHZjkw8bXg6UI=; b=ZTihHYB8JFzCejTgu89pAJ6zxbhO5sfT65QLZOPUntfkYlNmwGqs+wTLzQzzP5Y83C J1hKtZTdVvjYuqz9RaQn6KIHiiRoy460ttX2rsGOCcHkjgwLAP6rU762EAq/D5MOdHc3 W31zV3FsI3sgl4fdhmSTDL1TvxdOISsZ2lPwniiGkdWd7OgEyvgEoflU2MflRufpSVw2 YpJCJ1fDGPFU3w/Ww12cX5cYsfZ73nkRdbsab0BzUrfY2g0/0IHekc/wZF6oH2ArtIxf Z2zPNHnT0Pg6HkbVVh8KW5CfBqTySKDz8g1ZHqU1P2UPYvKLpSDw6HD/ffGG1dB/Yoj/ 2C5g== X-Gm-Message-State: ALoCoQkZ8cyatdeYYXlp6ge/P4KmQcefDm3khjGh6LkGyQFaHE1GHXZO9IMAmYOKp9loDxEdEswh MIME-Version: 1.0 X-Received: by 10.221.4.2 with SMTP id oa2mr50522vcb.17.1417537101902; Tue, 02 Dec 2014 08:18:21 -0800 (PST) Received: by 10.31.33.20 with HTTP; Tue, 2 Dec 2014 08:18:21 -0800 (PST) In-Reply-To: <547DD56E.8090104@gmail.com> References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> <547DD56E.8090104@gmail.com> Date: Tue, 2 Dec 2014 11:18:21 -0500 Message-ID: From: Len Maxwell To: Toby Moore Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9108356007620020070==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============9108356007620020070== Content-Type: multipart/alternative; boundary=089e013c719e6a4ceb05093e1316 --089e013c719e6a4ceb05093e1316 Content-Type: text/plain; charset=UTF-8 Hi Toby, I just built a similar example [1] and it is running OK on EC2 [2]. You might try building and deploying my code from your environment and see if you get any different result. Note that I am using the mirage-dev OPAM remote, and explicitly calling for a V1.CLOCK "device" (per #289 [3]). [1] https://github.com/lnmx/mirage-sandbox/tree/master/http-clock [2] up temporarily: http://54.145.130.16/ [3] https://github.com/mirage/mirage/issues/289 -- Len On Tue, Dec 2, 2014 at 10:06 AM, Toby Moore wrote: > I've just added a github issue ( > https://github.com/mirage/mirage/issues/333). > > I'm on a mac, doing my dev in a linux vm which won't support xen inside > Parallels. If I get a chance this weekend I'll try out the OS X hosting > that I've seen going past on here. > > I have just tried adding `Xen -> ["mirage-clock-xen"] for the ocamlfind > stuff on AWS but it doesn't seem to make a difference, compiles fine but > again fails at runtime. > > Looking more closely at the error and my code, possibly it's the not the > time call or a missing dependency but the conversion? My code is doing > `Clock.gmtime (Clock.time ())`. I've found this reference here: > https://github.com/mirage/mirage-clock/blob/master/xen/clock.ml#L30 but > I'm not sure what that gets linked to. > --089e013c719e6a4ceb05093e1316 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Toby,

I ju= st built a similar example [1] and it is running OK on EC2 [2].=C2=A0 You m= ight try building and deploying my code from your environment and see if yo= u get any different result.

Note that I am using t= he mirage-dev OPAM remote, and explicitly calling for a V1.CLOCK "devi= ce" (per #289 [3]).

[2] up t= emporarily: http://54.145.130.16/=C2= =A0


--
Len

On Tue, Dec 2, 2014 at 10:06 AM, Toby Moore <to= by.moore.0@gmail.com> wrote:
I've just added a github=20 issue (https://github.com/mirage/mirage/issues/333).

I'm on a mac, doing my dev in a linux vm which won't support xen in= side=20 Parallels. If I get a chance this weekend I'll try out the OS X hosting= =20 that I've seen going past on here.

I have just tried adding `Xen -> ["mirage-clock-xen"] for the= =20 ocamlfind stuff on AWS but it doesn't seem to make a difference,= =20 compiles fine but again fails at runtime.

Looking more closely at the error and my code, possibly it's the not th= e time call or a missing dependency but the conversion? My code is doing `Clock.gmtime (Clock.time ())`. I've found this reference here:= =20 https://github.com/mirage/mirage-clock/blob/master/x= en/clock.ml#L30 but=20 I'm not sure what that gets linked to.

--089e013c719e6a4ceb05093e1316-- --===============9108356007620020070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============9108356007620020070==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:24:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:24:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqFA-0006EE-Hh; Tue, 02 Dec 2014 16:24:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqF9-0006E1-ME for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:24:03 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 2B/E9-17958-2A7ED745; Tue, 02 Dec 2014 16:24:02 +0000 X-Env-Sender: len@inthemail.org X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537440!10905291!1 X-Originating-IP: [209.85.220.180] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5590 invoked from network); 2 Dec 2014 16:24:01 -0000 Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 16:24:01 -0000 Received: by mail-vc0-f180.google.com with SMTP id im6so6041613vcb.39 for ; Tue, 02 Dec 2014 08:24:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iwaASLlPyLhI3hXuru49yDWszXpCK/kevc2q8YCDYUY=; b=guRqttEmq6pX+ke1RkTFpHvU50vD0T4wc1wce6V28dHZ/DBPT0elLZx7dIebRsRKRN KfCOjeL4PMBNm7Erz/VdStbUbLoY5xLBZDIXRZrpNCWQBkwC8UmEzTKhJhOZ0KHxx14I 0LuWoQKwEwMU44Nb9MTdgGCu+dyKBfx6p4s4FBTuSRMTNbyKvQJZ1/jykS53wNqT3DeL Naa4wsUdszYpqedW+1+sQi84Hxhzxl8Tlga8DmMOdovBnWCkceeuqeYyFPobHPWped9S DTRKX4Jf1Hi7uc+CYcQMDXKMGMg2CynuyuqsGuAgfhuCfpcHGAPd3Dj/d+nEPn+39BdW WrUA== X-Gm-Message-State: ALoCoQkjO2T5hvk8Qtb7wKrlVFrcV9pNaSELNFaosWC8WQVbP3SkHNAHplAzEBgqrfY04T4OJvTA MIME-Version: 1.0 X-Received: by 10.220.74.197 with SMTP id v5mr65364vcj.27.1417537440337; Tue, 02 Dec 2014 08:24:00 -0800 (PST) Received: by 10.31.33.20 with HTTP; Tue, 2 Dec 2014 08:24:00 -0800 (PST) In-Reply-To: References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> <547DD56E.8090104@gmail.com> Date: Tue, 2 Dec 2014 11:24:00 -0500 Message-ID: From: Len Maxwell To: Toby Moore Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0739219810744957059==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0739219810744957059== Content-Type: multipart/alternative; boundary=089e0160b76e96872405093e27ae --089e0160b76e96872405093e27ae Content-Type: text/plain; charset=UTF-8 Oops -- after reviewing the comments on issue #333, I realize this is related to Clock.gmtime. Ignore my reply above. -- Len --089e0160b76e96872405093e27ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Oops -- after reviewing the comments on issue #33= 3, I realize this is related to Clock.gmtime. =C2=A0

Ignore my reply above.


--
<= div>Len --089e0160b76e96872405093e27ae-- --===============0739219810744957059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0739219810744957059==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:24:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:24:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqFA-0006EE-Hh; Tue, 02 Dec 2014 16:24:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqF9-0006E1-ME for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:24:03 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 2B/E9-17958-2A7ED745; Tue, 02 Dec 2014 16:24:02 +0000 X-Env-Sender: len@inthemail.org X-Msg-Ref: server-6.tower-31.messagelabs.com!1417537440!10905291!1 X-Originating-IP: [209.85.220.180] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5590 invoked from network); 2 Dec 2014 16:24:01 -0000 Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 16:24:01 -0000 Received: by mail-vc0-f180.google.com with SMTP id im6so6041613vcb.39 for ; Tue, 02 Dec 2014 08:24:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iwaASLlPyLhI3hXuru49yDWszXpCK/kevc2q8YCDYUY=; b=guRqttEmq6pX+ke1RkTFpHvU50vD0T4wc1wce6V28dHZ/DBPT0elLZx7dIebRsRKRN KfCOjeL4PMBNm7Erz/VdStbUbLoY5xLBZDIXRZrpNCWQBkwC8UmEzTKhJhOZ0KHxx14I 0LuWoQKwEwMU44Nb9MTdgGCu+dyKBfx6p4s4FBTuSRMTNbyKvQJZ1/jykS53wNqT3DeL Naa4wsUdszYpqedW+1+sQi84Hxhzxl8Tlga8DmMOdovBnWCkceeuqeYyFPobHPWped9S DTRKX4Jf1Hi7uc+CYcQMDXKMGMg2CynuyuqsGuAgfhuCfpcHGAPd3Dj/d+nEPn+39BdW WrUA== X-Gm-Message-State: ALoCoQkjO2T5hvk8Qtb7wKrlVFrcV9pNaSELNFaosWC8WQVbP3SkHNAHplAzEBgqrfY04T4OJvTA MIME-Version: 1.0 X-Received: by 10.220.74.197 with SMTP id v5mr65364vcj.27.1417537440337; Tue, 02 Dec 2014 08:24:00 -0800 (PST) Received: by 10.31.33.20 with HTTP; Tue, 2 Dec 2014 08:24:00 -0800 (PST) In-Reply-To: References: <547DB24A.7050602@gmail.com> <645A9BBF-F4A3-4CBF-8022-8C042D634452@recoil.org> <547DD56E.8090104@gmail.com> Date: Tue, 2 Dec 2014 11:24:00 -0500 Message-ID: From: Len Maxwell To: Toby Moore Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Issues with CLOCK on xen X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0739219810744957059==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0739219810744957059== Content-Type: multipart/alternative; boundary=089e0160b76e96872405093e27ae --089e0160b76e96872405093e27ae Content-Type: text/plain; charset=UTF-8 Oops -- after reviewing the comments on issue #333, I realize this is related to Clock.gmtime. Ignore my reply above. -- Len --089e0160b76e96872405093e27ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Oops -- after reviewing the comments on issue #33= 3, I realize this is related to Clock.gmtime. =C2=A0

Ignore my reply above.


--
<= div>Len --089e0160b76e96872405093e27ae-- --===============0739219810744957059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0739219810744957059==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:53:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:53:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvqi1-0001J8-6y; Tue, 02 Dec 2014 16:53:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvqhz-0001J2-Rf for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:53:52 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 2A/09-25276-F9EED745; Tue, 02 Dec 2014 16:53:51 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-21.messagelabs.com!1417539230!12933585!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29728 invoked from network); 2 Dec 2014 16:53:50 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 16:53:50 -0000 Received: from [192.168.1.69] (host31-52-140-84.range31-52.btcentralplus.com [31.52.140.84]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0effa08d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 16:58:54 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 16:52:55 +0000 Message-Id: <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: Nicolas Ojeda Bar , Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Cj4gT24gMSBEZWMgMjAxNCwgYXQgMTQ6MzEsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnps aUBlcnJhdGlxdWUuY2g+IHdyb3RlOgo+IAo+IAo+IAo+IExlIGx1bmRpLCAxIGTDqWNlbWJyZSAy MDE0IMOgIDE1OjA1LCBUaG9tYXMgR2F6YWduYWlyZSBhIMOpY3JpdCA6Cj4gCj4+PiBPbmUgY2Fu IG9mIGNvdXJzZSwgbWFrZSB0aGUgbmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0aGUgbmFtZSBv ZiB0aGUKPj4+IHBhcmFtZXRlciB3aXRoIHRoZSBuYW1lIG9mIHRoZSBDT05GSUdVUkFCTEUgKGN1 cnJlbnRseQo+Pj4gc2VtaS1hbGdvcml0aG1pY2FsbHkgZ2VuZXJhdGVkIHRvIGtlZXAgdGhlbSB1 bmlxdWUpLCBidXQgdGhpcyBkb2VzIG5vdAo+Pj4gc2VlbSB2ZXJ5IHVzZXIgZnJpZW5kbHkuCj4+ IAo+PiBNYXliZSBleHBvc2UgYSA/bmFtZSBwYXJhbWF0ZXIgdG8gYWxsIHRoZSBjb21iaW5hdG9y cyB3aGljaCB3aWxsIGJlIHByZWZpeGVkIHRvIHBhcmFtZXRlciBhcmd1bWVudHMgaWYgbmVlZGVk Lgo+IAo+IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0uIElmIEkgdW5kZXJzdG9vZCB3 ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBkb2VzIGdlbmVyYXRlIG5ldyBj b25maWd1cmF0aW9uIHZhbHVlcy4gIAo+IAo+IE9mIGNvdXJzZSBpZiB0aGV5IGFyZSBtZWFudCB0 byBiZSBzaGFyZWQgYW1vbmcgaW5zdGFuY2VzIGl0IG1lYW5zIHRoYXQgeW91IGFyZSBkZWNsYXJp bmcgdGhlbSBhdCB0aGUgd3JvbmcgcGxhY2UuIEJlc3Qgd291bGQgYmUgdG8gZGVmaW5lIGEgbW9k dWxlIHdpdGggInN0YW5kYXJkIiBjb25maWd1cmF0aW9uIGtleXMgKGUuZy4gaXAgYWRkcmVzcykg dG8gYmUgdXNlZCB0byBiZSB1c2VkIHRocm91Z2hvdXQgdGhlIHN5c3RlbSBhbmQgdGVsbGluZyB1 c2VycyB0byBmaXJzdCB0cnkgdG8gdXNlIHRoZSBzdGFuZGFyZCBjb25maWd1cmF0aW9uIGtleXMg YmVmb3JlIHRyeWluZyB0byBkZWZpbmUgbmV3IG9uZXMuCgpPbmUgcHJvYmxlbSBjdXJyZW50bHkg aXMgdGhhdCB3aGlsZSBmdW5jdG9yIGFwcGxpY2F0aW9uIGdlbmVyYXRlcyBuZXcgY29uZmlndXJh dGlvbiB2YWx1ZXMsIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbnMgb2YgZGV2aWNlcyBtYXkgcmV1 c2UgdGhlIGZ1bmN0b3IgYXBwbGljYXRpb24gd2l0aCBkaWZmZXJlbnQgc3RhdGUgdmFyaWFibGVz LgoKRm9yIGluc3RhbmNlLCByaWdodCBub3cgaWYgd2UgZ2VuZXJhdGUgYSBIVFRQIGNsaWVudCwg d2UgbmVlZCB0aGlzIGluIG91ciBjb25maWcubWw6CgpsZXQgc3Y0ID0gc3RhY2sgZGVmYXVsdF9j b25zb2xlIGluCmxldCByZXNfZG5zID0gcmVzb2x2ZXJfZG5zIHN2NCBpbgpsZXQgY29uZHVpdCA9 IGNvbmR1aXRfZGlyZWN0IHN2NCBpbgoKVGhlIHN0YWNrIChzdjQpIGlzIGluc3RhbnRpYXRlZCBh cyBvbmUgZnVuY3RvciwgYnV0IGlzIGN1cnJlbnRseSBjb25uZWN0KCknZWQgdHdpY2UuICBUaGUg b2JzZXJ2YWJsZSBidWcgaXMgdGhhdCBpdCBpc3N1ZXMgYSBESENQIHF1ZXJ5IGZvciBldmVyeSB0 aW1lIGl0IGlzIGNhbGxlZC4KCkZpbGxpbmcgdGhpcyBhdCBmaXJzdCBnbGFuY2UgcmVxdWlyZXMg aW5zdGFudGlhdGlvbnMgdG8gYmUgbGF6eSwgc28gdGhhdCB3ZSByZXVzZSB0aGVtLiAgSG93ZXZl ciwgaXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBleHBsaWNpdGx5IG5hbWUgZGV2aWNlcyBzbyB0aGF0 IHdlIGNhbiBzYWZlbHkgbWVtb2lzZSBtdWx0aXBsZSBzdGFja3MgdGhhdCBzaGFyZSB0aGUgc2Ft ZSBmdW5jdG9yIGJ1dCBvdGhlcndpc2UgZGlmZmVyIGluIHRoZWlyIHN0YXRlIChlLmcuIHR3byBj b21wbGV0ZWx5IHNlcGFyYXRlIHN0YWNrcyB0aGF0IGlzc3VlIHRoZWlyIG93biBESENQIHJlcXVl c3RzIHdpdGggdGhlaXIgb3duIE1BQyBhZGRyZXNzZXMsIGJ1dCBvdGhlcndpc2Ugc2hhcmUgdGhl IHNhbWUgT0NhbWwgVENQL0lQIGZ1bmN0b3JzKS4KCihzZWUgaHR0cHM6Ly9naXRodWIuY29tL21p cmFnZS9taXJhZ2UvaXNzdWVzLzMzMSBmb3IgbW9yZSkKCj4gCj4gTm93IHRoZSBxdWVzdGlvbiBh bmQgcHJvYmxlbSByZW1haW5zIHdoZXRoZXIgdGhlcmUgd291bGQgYmUgdGhlIG5lZWQgZm9yIHBl ciBtb2R1bGUgaW5zdGFuY2lhdGlvbiBjb25maWd1cmF0aW9uIGtleXMuIEluIHRoYXQgY2FzZSBp dCBzZWVtcyB0aGF0IHdoYXQgVGhvbWFzIGlzIHByb3Bvc2luZyBpcyB0aGUgZ29vZCBhbnN3ZXIs IHRoZSBtb2R1bGUgcGFyYW1ldGVyIHNob3VsZCB0aGVuIHByb3ZpZGUgYSBgdmFsIG5hbWUgOiBz dHJpbmdgIGluIHRoZSBzaWduYXR1cmUgdGhhdCB5b3UgdGhyZWFkIGluIHRoZSByZXN1bHRpbmcg bW9kdWxlIHVzaW5nIHRoYXQgYD9uYW1lYCBwYXJhbWV0ZXIgd2hlbiBpdCBjcmVhdGVzIGl0cyBv d24ga2V5cy4KClRoaXMgaXMgcHJvYmFibHkgdXNlZnVsIHRvIGdlbmVyYXRlIG5pY2VyIGVycm9y IG1lc3NhZ2VzIGFzIHdlbGwsIGJ1dCB3ZSBoYXZlIHRvIGJlIHZlcnkgY2FyZWZ1bCB0aGF0IHRo ZSA/bmFtZSBwYXJhbWV0ZXIgbm90IGludHJvZHVjZSBtb2R1bGUgbmFtZSBjbGFzaGVzIGluIHRo ZSBnZW5lcmF0ZWQgY29kZS4gIFJpZ2h0IG5vdyB0aGV5J3JlIGd1YXJhbnRlZWQgdG8gYmUgZnJl c2ggbW9kdWxlIG5hbWVzIHNpbmNlIHRoZXkncmUgZ2VuZXJhdGVkIGluc2lkZSB0aGUgbWlyYWdl IHRvb2wuCgo+IFAuUy4gSXQgd291bGQgYmUgbmljZSB0byBwcm92aWRlIG1vcmUgc3BlY2lmaWMg bGlua3Mgd2hlbiB5b3UgYXNrIGZvciBmZWVkYmFjaywgb2YgaW50ZXJlc3QgaGVyZSB3b3VsZCBi ZSB0aGUgQVBJIGFuZCB0aGUgd2F5IGl0IGdldHMgdXNlZCBpbiB0aGUgY29kZS4KCkkgZGlkIGlu ZGVlZCB0cnkgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIHBhdGNoIHJpZ2h0IG5vdyB1c2luZyB0aGUg YGNvbXBhcmVgIGJ1dHRvbiBvbiB0aGF0IGJyYW5jaCwgYW5kIHJhbiByaWdodCBpbnRvIE5pY29s YXMnIElQdjYgcGF0Y2hlcyB0aGVyZSBhcyB3ZWxsLiAgVGhpcyBpcyBwcm9iYWJseSBhIGhpbnQg dG8gbWUgdGhhdCB0aGV5IG5lZWQgcmV2aWV3IGFuZCBtZXJnaW5nIHNvb24gOi0pCgotYW5pbApf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1k ZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vv cy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:53:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:53:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvqi1-0001J8-6y; Tue, 02 Dec 2014 16:53:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvqhz-0001J2-Rf for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:53:52 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 2A/09-25276-F9EED745; Tue, 02 Dec 2014 16:53:51 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-21.messagelabs.com!1417539230!12933585!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29728 invoked from network); 2 Dec 2014 16:53:50 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 16:53:50 -0000 Received: from [192.168.1.69] (host31-52-140-84.range31-52.btcentralplus.com [31.52.140.84]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0effa08d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 16:58:54 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 16:52:55 +0000 Message-Id: <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: Nicolas Ojeda Bar , Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Cj4gT24gMSBEZWMgMjAxNCwgYXQgMTQ6MzEsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnps aUBlcnJhdGlxdWUuY2g+IHdyb3RlOgo+IAo+IAo+IAo+IExlIGx1bmRpLCAxIGTDqWNlbWJyZSAy MDE0IMOgIDE1OjA1LCBUaG9tYXMgR2F6YWduYWlyZSBhIMOpY3JpdCA6Cj4gCj4+PiBPbmUgY2Fu IG9mIGNvdXJzZSwgbWFrZSB0aGUgbmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0aGUgbmFtZSBv ZiB0aGUKPj4+IHBhcmFtZXRlciB3aXRoIHRoZSBuYW1lIG9mIHRoZSBDT05GSUdVUkFCTEUgKGN1 cnJlbnRseQo+Pj4gc2VtaS1hbGdvcml0aG1pY2FsbHkgZ2VuZXJhdGVkIHRvIGtlZXAgdGhlbSB1 bmlxdWUpLCBidXQgdGhpcyBkb2VzIG5vdAo+Pj4gc2VlbSB2ZXJ5IHVzZXIgZnJpZW5kbHkuCj4+ IAo+PiBNYXliZSBleHBvc2UgYSA/bmFtZSBwYXJhbWF0ZXIgdG8gYWxsIHRoZSBjb21iaW5hdG9y cyB3aGljaCB3aWxsIGJlIHByZWZpeGVkIHRvIHBhcmFtZXRlciBhcmd1bWVudHMgaWYgbmVlZGVk Lgo+IAo+IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0uIElmIEkgdW5kZXJzdG9vZCB3 ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBkb2VzIGdlbmVyYXRlIG5ldyBj b25maWd1cmF0aW9uIHZhbHVlcy4gIAo+IAo+IE9mIGNvdXJzZSBpZiB0aGV5IGFyZSBtZWFudCB0 byBiZSBzaGFyZWQgYW1vbmcgaW5zdGFuY2VzIGl0IG1lYW5zIHRoYXQgeW91IGFyZSBkZWNsYXJp bmcgdGhlbSBhdCB0aGUgd3JvbmcgcGxhY2UuIEJlc3Qgd291bGQgYmUgdG8gZGVmaW5lIGEgbW9k dWxlIHdpdGggInN0YW5kYXJkIiBjb25maWd1cmF0aW9uIGtleXMgKGUuZy4gaXAgYWRkcmVzcykg dG8gYmUgdXNlZCB0byBiZSB1c2VkIHRocm91Z2hvdXQgdGhlIHN5c3RlbSBhbmQgdGVsbGluZyB1 c2VycyB0byBmaXJzdCB0cnkgdG8gdXNlIHRoZSBzdGFuZGFyZCBjb25maWd1cmF0aW9uIGtleXMg YmVmb3JlIHRyeWluZyB0byBkZWZpbmUgbmV3IG9uZXMuCgpPbmUgcHJvYmxlbSBjdXJyZW50bHkg aXMgdGhhdCB3aGlsZSBmdW5jdG9yIGFwcGxpY2F0aW9uIGdlbmVyYXRlcyBuZXcgY29uZmlndXJh dGlvbiB2YWx1ZXMsIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbnMgb2YgZGV2aWNlcyBtYXkgcmV1 c2UgdGhlIGZ1bmN0b3IgYXBwbGljYXRpb24gd2l0aCBkaWZmZXJlbnQgc3RhdGUgdmFyaWFibGVz LgoKRm9yIGluc3RhbmNlLCByaWdodCBub3cgaWYgd2UgZ2VuZXJhdGUgYSBIVFRQIGNsaWVudCwg d2UgbmVlZCB0aGlzIGluIG91ciBjb25maWcubWw6CgpsZXQgc3Y0ID0gc3RhY2sgZGVmYXVsdF9j b25zb2xlIGluCmxldCByZXNfZG5zID0gcmVzb2x2ZXJfZG5zIHN2NCBpbgpsZXQgY29uZHVpdCA9 IGNvbmR1aXRfZGlyZWN0IHN2NCBpbgoKVGhlIHN0YWNrIChzdjQpIGlzIGluc3RhbnRpYXRlZCBh cyBvbmUgZnVuY3RvciwgYnV0IGlzIGN1cnJlbnRseSBjb25uZWN0KCknZWQgdHdpY2UuICBUaGUg b2JzZXJ2YWJsZSBidWcgaXMgdGhhdCBpdCBpc3N1ZXMgYSBESENQIHF1ZXJ5IGZvciBldmVyeSB0 aW1lIGl0IGlzIGNhbGxlZC4KCkZpbGxpbmcgdGhpcyBhdCBmaXJzdCBnbGFuY2UgcmVxdWlyZXMg aW5zdGFudGlhdGlvbnMgdG8gYmUgbGF6eSwgc28gdGhhdCB3ZSByZXVzZSB0aGVtLiAgSG93ZXZl ciwgaXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBleHBsaWNpdGx5IG5hbWUgZGV2aWNlcyBzbyB0aGF0 IHdlIGNhbiBzYWZlbHkgbWVtb2lzZSBtdWx0aXBsZSBzdGFja3MgdGhhdCBzaGFyZSB0aGUgc2Ft ZSBmdW5jdG9yIGJ1dCBvdGhlcndpc2UgZGlmZmVyIGluIHRoZWlyIHN0YXRlIChlLmcuIHR3byBj b21wbGV0ZWx5IHNlcGFyYXRlIHN0YWNrcyB0aGF0IGlzc3VlIHRoZWlyIG93biBESENQIHJlcXVl c3RzIHdpdGggdGhlaXIgb3duIE1BQyBhZGRyZXNzZXMsIGJ1dCBvdGhlcndpc2Ugc2hhcmUgdGhl IHNhbWUgT0NhbWwgVENQL0lQIGZ1bmN0b3JzKS4KCihzZWUgaHR0cHM6Ly9naXRodWIuY29tL21p cmFnZS9taXJhZ2UvaXNzdWVzLzMzMSBmb3IgbW9yZSkKCj4gCj4gTm93IHRoZSBxdWVzdGlvbiBh bmQgcHJvYmxlbSByZW1haW5zIHdoZXRoZXIgdGhlcmUgd291bGQgYmUgdGhlIG5lZWQgZm9yIHBl ciBtb2R1bGUgaW5zdGFuY2lhdGlvbiBjb25maWd1cmF0aW9uIGtleXMuIEluIHRoYXQgY2FzZSBp dCBzZWVtcyB0aGF0IHdoYXQgVGhvbWFzIGlzIHByb3Bvc2luZyBpcyB0aGUgZ29vZCBhbnN3ZXIs IHRoZSBtb2R1bGUgcGFyYW1ldGVyIHNob3VsZCB0aGVuIHByb3ZpZGUgYSBgdmFsIG5hbWUgOiBz dHJpbmdgIGluIHRoZSBzaWduYXR1cmUgdGhhdCB5b3UgdGhyZWFkIGluIHRoZSByZXN1bHRpbmcg bW9kdWxlIHVzaW5nIHRoYXQgYD9uYW1lYCBwYXJhbWV0ZXIgd2hlbiBpdCBjcmVhdGVzIGl0cyBv d24ga2V5cy4KClRoaXMgaXMgcHJvYmFibHkgdXNlZnVsIHRvIGdlbmVyYXRlIG5pY2VyIGVycm9y IG1lc3NhZ2VzIGFzIHdlbGwsIGJ1dCB3ZSBoYXZlIHRvIGJlIHZlcnkgY2FyZWZ1bCB0aGF0IHRo ZSA/bmFtZSBwYXJhbWV0ZXIgbm90IGludHJvZHVjZSBtb2R1bGUgbmFtZSBjbGFzaGVzIGluIHRo ZSBnZW5lcmF0ZWQgY29kZS4gIFJpZ2h0IG5vdyB0aGV5J3JlIGd1YXJhbnRlZWQgdG8gYmUgZnJl c2ggbW9kdWxlIG5hbWVzIHNpbmNlIHRoZXkncmUgZ2VuZXJhdGVkIGluc2lkZSB0aGUgbWlyYWdl IHRvb2wuCgo+IFAuUy4gSXQgd291bGQgYmUgbmljZSB0byBwcm92aWRlIG1vcmUgc3BlY2lmaWMg bGlua3Mgd2hlbiB5b3UgYXNrIGZvciBmZWVkYmFjaywgb2YgaW50ZXJlc3QgaGVyZSB3b3VsZCBi ZSB0aGUgQVBJIGFuZCB0aGUgd2F5IGl0IGdldHMgdXNlZCBpbiB0aGUgY29kZS4KCkkgZGlkIGlu ZGVlZCB0cnkgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIHBhdGNoIHJpZ2h0IG5vdyB1c2luZyB0aGUg YGNvbXBhcmVgIGJ1dHRvbiBvbiB0aGF0IGJyYW5jaCwgYW5kIHJhbiByaWdodCBpbnRvIE5pY29s YXMnIElQdjYgcGF0Y2hlcyB0aGVyZSBhcyB3ZWxsLiAgVGhpcyBpcyBwcm9iYWJseSBhIGhpbnQg dG8gbWUgdGhhdCB0aGV5IG5lZWQgcmV2aWV3IGFuZCBtZXJnaW5nIHNvb24gOi0pCgotYW5pbApf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1k ZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vv cy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:58:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:58:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqmR-0001Ns-KH; Tue, 02 Dec 2014 16:58:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqmR-0001Nn-5q for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:58:27 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 1D/6F-25276-2BFED745; Tue, 02 Dec 2014 16:58:26 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-13.tower-21.messagelabs.com!1417539505!5624743!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21368 invoked from network); 2 Dec 2014 16:58:25 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 16:58:25 -0000 Received: from [192.168.1.69] (host31-52-140-84.range31-52.btcentralplus.com [31.52.140.84]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 9cb93704; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 17:03:30 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> Date: Tue, 2 Dec 2014 16:58:25 +0000 Message-Id: <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: Nicolas Ojeda Bar , Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMiBEZWMgMjAxNCwgYXQgMTY6NTIsIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmlsQHJlY29pbC5v cmc+IHdyb3RlOgo+PiBPbiAxIERlYyAyMDE0LCBhdCAxNDozMSwgRGFuaWVsIELDvG56bGkgPGRh bmllbC5idWVuemxpQGVycmF0aXF1ZS5jaD4gd3JvdGU6Cj4+IExlIGx1bmRpLCAxIGTDqWNlbWJy ZSAyMDE0IMOgIDE1OjA1LCBUaG9tYXMgR2F6YWduYWlyZSBhIMOpY3JpdCA6Cj4+IAo+Pj4+IE9u ZSBjYW4gb2YgY291cnNlLCBtYWtlIHRoZSBuYW1lcyB1bmlxdWUgYnkgY29tYmluaW5nIHRoZSBu YW1lIG9mIHRoZQo+Pj4+IHBhcmFtZXRlciB3aXRoIHRoZSBuYW1lIG9mIHRoZSBDT05GSUdVUkFC TEUgKGN1cnJlbnRseQo+Pj4+IHNlbWktYWxnb3JpdGhtaWNhbGx5IGdlbmVyYXRlZCB0byBrZWVw IHRoZW0gdW5pcXVlKSwgYnV0IHRoaXMgZG9lcyBub3QKPj4+PiBzZWVtIHZlcnkgdXNlciBmcmll bmRseS4KPj4+IAo+Pj4gTWF5YmUgZXhwb3NlIGEgP25hbWUgcGFyYW1hdGVyIHRvIGFsbCB0aGUg Y29tYmluYXRvcnMgd2hpY2ggd2lsbCBiZSBwcmVmaXhlZCB0byBwYXJhbWV0ZXIgYXJndW1lbnRz IGlmIG5lZWRlZC4KPj4gCj4+IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0uIElmIEkg dW5kZXJzdG9vZCB3ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBkb2VzIGdl bmVyYXRlIG5ldyBjb25maWd1cmF0aW9uIHZhbHVlcy4gIAo+PiAKPj4gT2YgY291cnNlIGlmIHRo ZXkgYXJlIG1lYW50IHRvIGJlIHNoYXJlZCBhbW9uZyBpbnN0YW5jZXMgaXQgbWVhbnMgdGhhdCB5 b3UgYXJlIGRlY2xhcmluZyB0aGVtIGF0IHRoZSB3cm9uZyBwbGFjZS4gQmVzdCB3b3VsZCBiZSB0 byBkZWZpbmUgYSBtb2R1bGUgd2l0aCAic3RhbmRhcmQiIGNvbmZpZ3VyYXRpb24ga2V5cyAoZS5n LiBpcCBhZGRyZXNzKSB0byBiZSB1c2VkIHRvIGJlIHVzZWQgdGhyb3VnaG91dCB0aGUgc3lzdGVt IGFuZCB0ZWxsaW5nIHVzZXJzIHRvIGZpcnN0IHRyeSB0byB1c2UgdGhlIHN0YW5kYXJkIGNvbmZp Z3VyYXRpb24ga2V5cyBiZWZvcmUgdHJ5aW5nIHRvIGRlZmluZSBuZXcgb25lcy4KPiAKPiBPbmUg cHJvYmxlbSBjdXJyZW50bHkgaXMgdGhhdCB3aGlsZSBmdW5jdG9yIGFwcGxpY2F0aW9uIGdlbmVy YXRlcyBuZXcgY29uZmlndXJhdGlvbiB2YWx1ZXMsIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbnMg b2YgZGV2aWNlcyBtYXkgcmV1c2UgdGhlIGZ1bmN0b3IgYXBwbGljYXRpb24gd2l0aCBkaWZmZXJl bnQgc3RhdGUgdmFyaWFibGVzLgo+IAo+IEZvciBpbnN0YW5jZSwgcmlnaHQgbm93IGlmIHdlIGdl bmVyYXRlIGEgSFRUUCBjbGllbnQsIHdlIG5lZWQgdGhpcyBpbiBvdXIgY29uZmlnLm1sOgo+IAo+ IGxldCBzdjQgPSBzdGFjayBkZWZhdWx0X2NvbnNvbGUgaW4KPiBsZXQgcmVzX2RucyA9IHJlc29s dmVyX2RucyBzdjQgaW4KPiBsZXQgY29uZHVpdCA9IGNvbmR1aXRfZGlyZWN0IHN2NCBpbgo+IAo+ IFRoZSBzdGFjayAoc3Y0KSBpcyBpbnN0YW50aWF0ZWQgYXMgb25lIGZ1bmN0b3IsIGJ1dCBpcyBj dXJyZW50bHkgY29ubmVjdCgpJ2VkIHR3aWNlLiAgVGhlIG9ic2VydmFibGUgYnVnIGlzIHRoYXQg aXQgaXNzdWVzIGEgREhDUCBxdWVyeSBmb3IgZXZlcnkgdGltZSBpdCBpcyBjYWxsZWQuCj4gCj4g RmlsbGluZyB0aGlzIGF0IGZpcnN0IGdsYW5jZSByZXF1aXJlcyBpbnN0YW50aWF0aW9ucyB0byBi ZSBsYXp5LCBzbyB0aGF0IHdlIHJldXNlIHRoZW0uICBIb3dldmVyLCBpdCBtYXkgYmUgbmVjZXNz YXJ5IHRvIGV4cGxpY2l0bHkgbmFtZSBkZXZpY2VzIHNvIHRoYXQgd2UgY2FuIHNhZmVseSBtZW1v aXNlIG11bHRpcGxlIHN0YWNrcyB0aGF0IHNoYXJlIHRoZSBzYW1lIGZ1bmN0b3IgYnV0IG90aGVy d2lzZSBkaWZmZXIgaW4gdGhlaXIgc3RhdGUgKGUuZy4gdHdvIGNvbXBsZXRlbHkgc2VwYXJhdGUg c3RhY2tzIHRoYXQgaXNzdWUgdGhlaXIgb3duIERIQ1AgcmVxdWVzdHMgd2l0aCB0aGVpciBvd24g TUFDIGFkZHJlc3NlcywgYnV0IG90aGVyd2lzZSBzaGFyZSB0aGUgc2FtZSBPQ2FtbCBUQ1AvSVAg ZnVuY3RvcnMpLgo+IAo+IChzZWUgaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvaXNz dWVzLzMzMSBmb3IgbW9yZSkKCkFuIGFkZGVuZHVtIHRvIHRoaXMgaXMgdGhhdCB3ZSBkb24ndCB3 YW50IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1c2UgbGF6eSBhbmQgc2hhcmVkIGJ5IGRl ZmF1bHQuCgpJbiB0aGUgZXhhbXBsZSBhYm92ZSwgaXQgaXMgcGVyZmVjdGx5IHNlbnNpYmxlIHRv IHdhbnQgdG8gaGF2ZSBvbmUgSVAgc3RhY2sgZm9yIHRoZSBwdXJwb3NlcyBvZiBETlMgcmVzb2x1 dGlvbiBvbmx5LCBhbmQgYW5vdGhlciBmb3IgdGhlIHB1cnBvc2VzIG9mIG9wZW5pbmcgbmV0d29y ayBjb25uZWN0aW9ucyBmb3IgZGF0YSB0cmFuc2Zlci4gIFRoYXQncyBkaWZmaWN1bHQgdG8gc2V0 dXAgb24gbW9zdCBzeXN0ZW1zIHRvZGF5LCBidXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc2Vt YmxlIHdpdGggTWlyYWdlLgoKLWFuaWwKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVs QGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmlu L21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 16:58:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 16:58:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqmR-0001Ns-KH; Tue, 02 Dec 2014 16:58:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvqmR-0001Nn-5q for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 16:58:27 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 1D/6F-25276-2BFED745; Tue, 02 Dec 2014 16:58:26 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-13.tower-21.messagelabs.com!1417539505!5624743!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21368 invoked from network); 2 Dec 2014 16:58:25 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 16:58:25 -0000 Received: from [192.168.1.69] (host31-52-140-84.range31-52.btcentralplus.com [31.52.140.84]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 9cb93704; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 17:03:30 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> Date: Tue, 2 Dec 2014 16:58:25 +0000 Message-Id: <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: Nicolas Ojeda Bar , Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMiBEZWMgMjAxNCwgYXQgMTY6NTIsIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmlsQHJlY29pbC5v cmc+IHdyb3RlOgo+PiBPbiAxIERlYyAyMDE0LCBhdCAxNDozMSwgRGFuaWVsIELDvG56bGkgPGRh bmllbC5idWVuemxpQGVycmF0aXF1ZS5jaD4gd3JvdGU6Cj4+IExlIGx1bmRpLCAxIGTDqWNlbWJy ZSAyMDE0IMOgIDE1OjA1LCBUaG9tYXMgR2F6YWduYWlyZSBhIMOpY3JpdCA6Cj4+IAo+Pj4+IE9u ZSBjYW4gb2YgY291cnNlLCBtYWtlIHRoZSBuYW1lcyB1bmlxdWUgYnkgY29tYmluaW5nIHRoZSBu YW1lIG9mIHRoZQo+Pj4+IHBhcmFtZXRlciB3aXRoIHRoZSBuYW1lIG9mIHRoZSBDT05GSUdVUkFC TEUgKGN1cnJlbnRseQo+Pj4+IHNlbWktYWxnb3JpdGhtaWNhbGx5IGdlbmVyYXRlZCB0byBrZWVw IHRoZW0gdW5pcXVlKSwgYnV0IHRoaXMgZG9lcyBub3QKPj4+PiBzZWVtIHZlcnkgdXNlciBmcmll bmRseS4KPj4+IAo+Pj4gTWF5YmUgZXhwb3NlIGEgP25hbWUgcGFyYW1hdGVyIHRvIGFsbCB0aGUg Y29tYmluYXRvcnMgd2hpY2ggd2lsbCBiZSBwcmVmaXhlZCB0byBwYXJhbWV0ZXIgYXJndW1lbnRz IGlmIG5lZWRlZC4KPj4gCj4+IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0uIElmIEkg dW5kZXJzdG9vZCB3ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBkb2VzIGdl bmVyYXRlIG5ldyBjb25maWd1cmF0aW9uIHZhbHVlcy4gIAo+PiAKPj4gT2YgY291cnNlIGlmIHRo ZXkgYXJlIG1lYW50IHRvIGJlIHNoYXJlZCBhbW9uZyBpbnN0YW5jZXMgaXQgbWVhbnMgdGhhdCB5 b3UgYXJlIGRlY2xhcmluZyB0aGVtIGF0IHRoZSB3cm9uZyBwbGFjZS4gQmVzdCB3b3VsZCBiZSB0 byBkZWZpbmUgYSBtb2R1bGUgd2l0aCAic3RhbmRhcmQiIGNvbmZpZ3VyYXRpb24ga2V5cyAoZS5n LiBpcCBhZGRyZXNzKSB0byBiZSB1c2VkIHRvIGJlIHVzZWQgdGhyb3VnaG91dCB0aGUgc3lzdGVt IGFuZCB0ZWxsaW5nIHVzZXJzIHRvIGZpcnN0IHRyeSB0byB1c2UgdGhlIHN0YW5kYXJkIGNvbmZp Z3VyYXRpb24ga2V5cyBiZWZvcmUgdHJ5aW5nIHRvIGRlZmluZSBuZXcgb25lcy4KPiAKPiBPbmUg cHJvYmxlbSBjdXJyZW50bHkgaXMgdGhhdCB3aGlsZSBmdW5jdG9yIGFwcGxpY2F0aW9uIGdlbmVy YXRlcyBuZXcgY29uZmlndXJhdGlvbiB2YWx1ZXMsIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbnMg b2YgZGV2aWNlcyBtYXkgcmV1c2UgdGhlIGZ1bmN0b3IgYXBwbGljYXRpb24gd2l0aCBkaWZmZXJl bnQgc3RhdGUgdmFyaWFibGVzLgo+IAo+IEZvciBpbnN0YW5jZSwgcmlnaHQgbm93IGlmIHdlIGdl bmVyYXRlIGEgSFRUUCBjbGllbnQsIHdlIG5lZWQgdGhpcyBpbiBvdXIgY29uZmlnLm1sOgo+IAo+ IGxldCBzdjQgPSBzdGFjayBkZWZhdWx0X2NvbnNvbGUgaW4KPiBsZXQgcmVzX2RucyA9IHJlc29s dmVyX2RucyBzdjQgaW4KPiBsZXQgY29uZHVpdCA9IGNvbmR1aXRfZGlyZWN0IHN2NCBpbgo+IAo+ IFRoZSBzdGFjayAoc3Y0KSBpcyBpbnN0YW50aWF0ZWQgYXMgb25lIGZ1bmN0b3IsIGJ1dCBpcyBj dXJyZW50bHkgY29ubmVjdCgpJ2VkIHR3aWNlLiAgVGhlIG9ic2VydmFibGUgYnVnIGlzIHRoYXQg aXQgaXNzdWVzIGEgREhDUCBxdWVyeSBmb3IgZXZlcnkgdGltZSBpdCBpcyBjYWxsZWQuCj4gCj4g RmlsbGluZyB0aGlzIGF0IGZpcnN0IGdsYW5jZSByZXF1aXJlcyBpbnN0YW50aWF0aW9ucyB0byBi ZSBsYXp5LCBzbyB0aGF0IHdlIHJldXNlIHRoZW0uICBIb3dldmVyLCBpdCBtYXkgYmUgbmVjZXNz YXJ5IHRvIGV4cGxpY2l0bHkgbmFtZSBkZXZpY2VzIHNvIHRoYXQgd2UgY2FuIHNhZmVseSBtZW1v aXNlIG11bHRpcGxlIHN0YWNrcyB0aGF0IHNoYXJlIHRoZSBzYW1lIGZ1bmN0b3IgYnV0IG90aGVy d2lzZSBkaWZmZXIgaW4gdGhlaXIgc3RhdGUgKGUuZy4gdHdvIGNvbXBsZXRlbHkgc2VwYXJhdGUg c3RhY2tzIHRoYXQgaXNzdWUgdGhlaXIgb3duIERIQ1AgcmVxdWVzdHMgd2l0aCB0aGVpciBvd24g TUFDIGFkZHJlc3NlcywgYnV0IG90aGVyd2lzZSBzaGFyZSB0aGUgc2FtZSBPQ2FtbCBUQ1AvSVAg ZnVuY3RvcnMpLgo+IAo+IChzZWUgaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvaXNz dWVzLzMzMSBmb3IgbW9yZSkKCkFuIGFkZGVuZHVtIHRvIHRoaXMgaXMgdGhhdCB3ZSBkb24ndCB3 YW50IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1c2UgbGF6eSBhbmQgc2hhcmVkIGJ5IGRl ZmF1bHQuCgpJbiB0aGUgZXhhbXBsZSBhYm92ZSwgaXQgaXMgcGVyZmVjdGx5IHNlbnNpYmxlIHRv IHdhbnQgdG8gaGF2ZSBvbmUgSVAgc3RhY2sgZm9yIHRoZSBwdXJwb3NlcyBvZiBETlMgcmVzb2x1 dGlvbiBvbmx5LCBhbmQgYW5vdGhlciBmb3IgdGhlIHB1cnBvc2VzIG9mIG9wZW5pbmcgbmV0d29y ayBjb25uZWN0aW9ucyBmb3IgZGF0YSB0cmFuc2Zlci4gIFRoYXQncyBkaWZmaWN1bHQgdG8gc2V0 dXAgb24gbW9zdCBzeXN0ZW1zIHRvZGF5LCBidXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc2Vt YmxlIHdpdGggTWlyYWdlLgoKLWFuaWwKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVs QGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmlu L21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 20:11:42 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 20:11:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvtnM-0000Bv-NE; Tue, 02 Dec 2014 20:11:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvtnL-0000Bq-Ko for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 20:11:35 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 13/FB-15461-7FC1E745; Tue, 02 Dec 2014 20:11:35 +0000 X-Env-Sender: manu.delab@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1417551094!12968865!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19030 invoked from network); 2 Dec 2014 20:11:34 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 20:11:34 -0000 Received: by mail-wg0-f50.google.com with SMTP id k14so17864292wgh.23 for ; Tue, 02 Dec 2014 12:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ecgwNyLsO/NhQcb4VLzYOkvGlHv5oTCtyuKt6XGAG10=; b=uoAZ5Mx92YMc0GHBUMTSeBkhp/n3WwKhz1gPiT0hRG1Ew9MB6EPt9PLYpsxriSuXFX v4DP0Cu1osL1ICQ4ZaSRQdXy46PIzmZYcxrLYJCJKV+iqC1eZwnoBJDDzskraBa9u6jj JtwaHyeDEwI4HwcOuvVWzjLj/E3obYkoBTvmEaY3s2W4qyw4bAGWCzZ41yxcnxeC7MYI x4m+u17oDkwm+iLP85xBI2nucHqfzD9HJuMKqfMXTRM8geBFVOttfGYrCn4afnhraOYl NDE5KaSvWN7TsH1tmNzjZZCjphEWlr3oKh6VKZZ01hBt2gPPFwY7tkSYNE7+Z+RCswH7 whpQ== X-Received: by 10.194.185.68 with SMTP id fa4mr1312149wjc.83.1417551094060; Tue, 02 Dec 2014 12:11:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.68.194 with HTTP; Tue, 2 Dec 2014 12:10:52 -0800 (PST) From: manu delab Date: Wed, 3 Dec 2014 09:10:52 +1300 Message-ID: To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Fwd: MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3398933729889000181==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3398933729889000181== Content-Type: multipart/alternative; boundary=047d7bacb11e699cc40509415595 --047d7bacb11e699cc40509415595 Content-Type: text/plain; charset=UTF-8 It works for me too. Running without sudo raises the following exception: $ ./mir-http-fetch Fatal error: exception Lwt_vmnet.Error(0) Raised at file "src/core/lwt.ml", line 782, characters 22-23 Called from file "src/unix/lwt_main.ml", line 34, characters 8-18 Called from file "main.ml", line 100, characters 2-28 With sudo, everything goes well Manu --047d7bacb11e699cc40509415595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It works for me too.

Running without = sudo raises the following exception:

$ ./mir-http-fetch
Fatal er= ror: exception Lwt_vmnet.Error(0)
Raised at file "src/core/lwt.ml", line 782, characters 22-23
Called f= rom file "src/unix/lwt_main.ml"= ;, line 34, characters 8-18
Called from file "main.ml", line 100, characters 2-28


With sudo, ev= erything goes well

Manu

--047d7bacb11e699cc40509415595-- --===============3398933729889000181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3398933729889000181==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 20:11:42 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 20:11:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvtnM-0000Bv-NE; Tue, 02 Dec 2014 20:11:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvtnL-0000Bq-Ko for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 20:11:35 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 13/FB-15461-7FC1E745; Tue, 02 Dec 2014 20:11:35 +0000 X-Env-Sender: manu.delab@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1417551094!12968865!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19030 invoked from network); 2 Dec 2014 20:11:34 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 20:11:34 -0000 Received: by mail-wg0-f50.google.com with SMTP id k14so17864292wgh.23 for ; Tue, 02 Dec 2014 12:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ecgwNyLsO/NhQcb4VLzYOkvGlHv5oTCtyuKt6XGAG10=; b=uoAZ5Mx92YMc0GHBUMTSeBkhp/n3WwKhz1gPiT0hRG1Ew9MB6EPt9PLYpsxriSuXFX v4DP0Cu1osL1ICQ4ZaSRQdXy46PIzmZYcxrLYJCJKV+iqC1eZwnoBJDDzskraBa9u6jj JtwaHyeDEwI4HwcOuvVWzjLj/E3obYkoBTvmEaY3s2W4qyw4bAGWCzZ41yxcnxeC7MYI x4m+u17oDkwm+iLP85xBI2nucHqfzD9HJuMKqfMXTRM8geBFVOttfGYrCn4afnhraOYl NDE5KaSvWN7TsH1tmNzjZZCjphEWlr3oKh6VKZZ01hBt2gPPFwY7tkSYNE7+Z+RCswH7 whpQ== X-Received: by 10.194.185.68 with SMTP id fa4mr1312149wjc.83.1417551094060; Tue, 02 Dec 2014 12:11:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.68.194 with HTTP; Tue, 2 Dec 2014 12:10:52 -0800 (PST) From: manu delab Date: Wed, 3 Dec 2014 09:10:52 +1300 Message-ID: To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Fwd: MacOS X vmnet support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3398933729889000181==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3398933729889000181== Content-Type: multipart/alternative; boundary=047d7bacb11e699cc40509415595 --047d7bacb11e699cc40509415595 Content-Type: text/plain; charset=UTF-8 It works for me too. Running without sudo raises the following exception: $ ./mir-http-fetch Fatal error: exception Lwt_vmnet.Error(0) Raised at file "src/core/lwt.ml", line 782, characters 22-23 Called from file "src/unix/lwt_main.ml", line 34, characters 8-18 Called from file "main.ml", line 100, characters 2-28 With sudo, everything goes well Manu --047d7bacb11e699cc40509415595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It works for me too.

Running without = sudo raises the following exception:

$ ./mir-http-fetch
Fatal er= ror: exception Lwt_vmnet.Error(0)
Raised at file "src/core/lwt.ml", line 782, characters 22-23
Called f= rom file "src/unix/lwt_main.ml"= ;, line 34, characters 8-18
Called from file "main.ml", line 100, characters 2-28


With sudo, ev= erything goes well

Manu

--047d7bacb11e699cc40509415595-- --===============3398933729889000181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3398933729889000181==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:21:27 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:21:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvuss-0003Qu-8y; Tue, 02 Dec 2014 21:21:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvusr-0003Qp-0T for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:21:21 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id BF/86-23865-05D2E745; Tue, 02 Dec 2014 21:21:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-31.messagelabs.com!1417555279!15291500!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14666 invoked from network); 2 Dec 2014 21:21:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:21:19 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 55b02ac9; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:26:24 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> Date: Tue, 2 Dec 2014 20:44:23 +0000 Message-Id: <31941300-9BB9-4F0F-A185-946CED17C8FE@recoil.org> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 13:22, Richard Mortier wrote: > > On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > >> On 6 Oct 2014, at 11:43, Richard Mortier wrote: >>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>> >>>> Block devices have another Xenstore numbering scheme that seems far more Linux-specific (and afaict, one that only Dave and Mort understand :-) >>> >>> pshaw. it's in the code. plain for all to see. somewhere. >>> (just don't ask me to remember it... :) >>> >>> in a spirit of functorisation, it seems like one should be able to pass in a function that would generate the next device id as part of the configuration of a unikernel, rather than embedding it in some backend library (or even frontend tool). or perhaps that's what providing a device tree would do? >> >> Yes, but what does 'next' mean here? What happens if you have three devices simultaneously hotplugged? They are mostly independent devices with the only connection being the unique identifier that Xenstore gives then (via the backend toolchain), so it seems odd that one device would be required to give the next one (which is potentially running in a completely separate domain) it's identifier. > > hm-- yes. > > tbh i think i had several misunderstandings, notably that i was assuming that it was the guest's job to register an id for the device in xenstore (under a domain prefix) when the device gets hot plugged into the guest, rather than xenstore's job to give each device an id that's unique inside the guest. Technically, it's not really xenstore's job either. When a device is hotplugged, the toolstack is only responsible for coordinating the establishment of a shared memory channel via xenstore. Typically the backend domain that has the physical device driver runs some hotplug script (e.g. udev on Linux), which results in the toolchain establishing the backend device (in /local/domain/0, although it can also be in another non-0 domain). This backend device (which has a grant reference to a memory ring, usually) then gets passed into the guest VM's xenstore area (/local/domain//) with a unique frontend device id that is selected by the toolchain (xend, libxl, xapi, etc). Xenstore is just acting as a distributed database in the middle of this device dance of toolchains and domains with different privilege levels... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:21:27 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:21:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvuss-0003Qu-8y; Tue, 02 Dec 2014 21:21:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvusr-0003Qp-0T for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:21:21 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id BF/86-23865-05D2E745; Tue, 02 Dec 2014 21:21:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-31.messagelabs.com!1417555279!15291500!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14666 invoked from network); 2 Dec 2014 21:21:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:21:19 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 55b02ac9; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:26:24 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> Date: Tue, 2 Dec 2014 20:44:23 +0000 Message-Id: <31941300-9BB9-4F0F-A185-946CED17C8FE@recoil.org> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 13:22, Richard Mortier wrote: > > On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > >> On 6 Oct 2014, at 11:43, Richard Mortier wrote: >>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>> >>>> Block devices have another Xenstore numbering scheme that seems far more Linux-specific (and afaict, one that only Dave and Mort understand :-) >>> >>> pshaw. it's in the code. plain for all to see. somewhere. >>> (just don't ask me to remember it... :) >>> >>> in a spirit of functorisation, it seems like one should be able to pass in a function that would generate the next device id as part of the configuration of a unikernel, rather than embedding it in some backend library (or even frontend tool). or perhaps that's what providing a device tree would do? >> >> Yes, but what does 'next' mean here? What happens if you have three devices simultaneously hotplugged? They are mostly independent devices with the only connection being the unique identifier that Xenstore gives then (via the backend toolchain), so it seems odd that one device would be required to give the next one (which is potentially running in a completely separate domain) it's identifier. > > hm-- yes. > > tbh i think i had several misunderstandings, notably that i was assuming that it was the guest's job to register an id for the device in xenstore (under a domain prefix) when the device gets hot plugged into the guest, rather than xenstore's job to give each device an id that's unique inside the guest. Technically, it's not really xenstore's job either. When a device is hotplugged, the toolstack is only responsible for coordinating the establishment of a shared memory channel via xenstore. Typically the backend domain that has the physical device driver runs some hotplug script (e.g. udev on Linux), which results in the toolchain establishing the backend device (in /local/domain/0, although it can also be in another non-0 domain). This backend device (which has a grant reference to a memory ring, usually) then gets passed into the guest VM's xenstore area (/local/domain//) with a unique frontend device id that is selected by the toolchain (xend, libxl, xapi, etc). Xenstore is just acting as a distributed database in the middle of this device dance of toolchains and domains with different privilege levels... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:22:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuuF-0003Yj-GD; Tue, 02 Dec 2014 21:22:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuuE-0003Ye-0d for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:22:46 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 9B/C2-09284-5AD2E745; Tue, 02 Dec 2014 21:22:45 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-31.messagelabs.com!1417555360!15338852!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3473 invoked from network); 2 Dec 2014 21:22:41 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:22:41 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6535798b; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:27:46 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> Date: Tue, 2 Dec 2014 20:44:23 +0000 Message-Id: <31941300-9BB9-4F0F-A185-946CED17C8FE@recoil.org> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 13:22, Richard Mortier wrote: > > On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > >> On 6 Oct 2014, at 11:43, Richard Mortier wrote: >>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>> >>>> Block devices have another Xenstore numbering scheme that seems far more Linux-specific (and afaict, one that only Dave and Mort understand :-) >>> >>> pshaw. it's in the code. plain for all to see. somewhere. >>> (just don't ask me to remember it... :) >>> >>> in a spirit of functorisation, it seems like one should be able to pass in a function that would generate the next device id as part of the configuration of a unikernel, rather than embedding it in some backend library (or even frontend tool). or perhaps that's what providing a device tree would do? >> >> Yes, but what does 'next' mean here? What happens if you have three devices simultaneously hotplugged? They are mostly independent devices with the only connection being the unique identifier that Xenstore gives then (via the backend toolchain), so it seems odd that one device would be required to give the next one (which is potentially running in a completely separate domain) it's identifier. > > hm-- yes. > > tbh i think i had several misunderstandings, notably that i was assuming that it was the guest's job to register an id for the device in xenstore (under a domain prefix) when the device gets hot plugged into the guest, rather than xenstore's job to give each device an id that's unique inside the guest. Technically, it's not really xenstore's job either. When a device is hotplugged, the toolstack is only responsible for coordinating the establishment of a shared memory channel via xenstore. Typically the backend domain that has the physical device driver runs some hotplug script (e.g. udev on Linux), which results in the toolchain establishing the backend device (in /local/domain/0, although it can also be in another non-0 domain). This backend device (which has a grant reference to a memory ring, usually) then gets passed into the guest VM's xenstore area (/local/domain//) with a unique frontend device id that is selected by the toolchain (xend, libxl, xapi, etc). Xenstore is just acting as a distributed database in the middle of this device dance of toolchains and domains with different privilege levels... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:22:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuuF-0003Yj-GD; Tue, 02 Dec 2014 21:22:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuuE-0003Ye-0d for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:22:46 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 9B/C2-09284-5AD2E745; Tue, 02 Dec 2014 21:22:45 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-31.messagelabs.com!1417555360!15338852!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3473 invoked from network); 2 Dec 2014 21:22:41 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:22:41 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6535798b; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:27:46 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> Date: Tue, 2 Dec 2014 20:44:23 +0000 Message-Id: <31941300-9BB9-4F0F-A185-946CED17C8FE@recoil.org> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 13:22, Richard Mortier wrote: > > On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > >> On 6 Oct 2014, at 11:43, Richard Mortier wrote: >>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>> >>>> Block devices have another Xenstore numbering scheme that seems far more Linux-specific (and afaict, one that only Dave and Mort understand :-) >>> >>> pshaw. it's in the code. plain for all to see. somewhere. >>> (just don't ask me to remember it... :) >>> >>> in a spirit of functorisation, it seems like one should be able to pass in a function that would generate the next device id as part of the configuration of a unikernel, rather than embedding it in some backend library (or even frontend tool). or perhaps that's what providing a device tree would do? >> >> Yes, but what does 'next' mean here? What happens if you have three devices simultaneously hotplugged? They are mostly independent devices with the only connection being the unique identifier that Xenstore gives then (via the backend toolchain), so it seems odd that one device would be required to give the next one (which is potentially running in a completely separate domain) it's identifier. > > hm-- yes. > > tbh i think i had several misunderstandings, notably that i was assuming that it was the guest's job to register an id for the device in xenstore (under a domain prefix) when the device gets hot plugged into the guest, rather than xenstore's job to give each device an id that's unique inside the guest. Technically, it's not really xenstore's job either. When a device is hotplugged, the toolstack is only responsible for coordinating the establishment of a shared memory channel via xenstore. Typically the backend domain that has the physical device driver runs some hotplug script (e.g. udev on Linux), which results in the toolchain establishing the backend device (in /local/domain/0, although it can also be in another non-0 domain). This backend device (which has a grant reference to a memory ring, usually) then gets passed into the guest VM's xenstore area (/local/domain//) with a unique frontend device id that is selected by the toolchain (xend, libxl, xapi, etc). Xenstore is just acting as a distributed database in the middle of this device dance of toolchains and domains with different privilege levels... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:24:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:24:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuwA-0003eK-OP; Tue, 02 Dec 2014 21:24:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvuw9-0003eF-Eb for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:24:45 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id C9/A2-17735-C1E2E745; Tue, 02 Dec 2014 21:24:44 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-16.tower-31.messagelabs.com!1417555483!15378778!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20183 invoked from network); 2 Dec 2014 21:24:43 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:24:43 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 88c3672c; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:29:48 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> Date: Tue, 2 Dec 2014 20:44:23 +0000 Message-Id: <31941300-9BB9-4F0F-A185-946CED17C8FE@recoil.org> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 13:22, Richard Mortier wrote: > > On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > >> On 6 Oct 2014, at 11:43, Richard Mortier wrote: >>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>> >>>> Block devices have another Xenstore numbering scheme that seems far more Linux-specific (and afaict, one that only Dave and Mort understand :-) >>> >>> pshaw. it's in the code. plain for all to see. somewhere. >>> (just don't ask me to remember it... :) >>> >>> in a spirit of functorisation, it seems like one should be able to pass in a function that would generate the next device id as part of the configuration of a unikernel, rather than embedding it in some backend library (or even frontend tool). or perhaps that's what providing a device tree would do? >> >> Yes, but what does 'next' mean here? What happens if you have three devices simultaneously hotplugged? They are mostly independent devices with the only connection being the unique identifier that Xenstore gives then (via the backend toolchain), so it seems odd that one device would be required to give the next one (which is potentially running in a completely separate domain) it's identifier. > > hm-- yes. > > tbh i think i had several misunderstandings, notably that i was assuming that it was the guest's job to register an id for the device in xenstore (under a domain prefix) when the device gets hot plugged into the guest, rather than xenstore's job to give each device an id that's unique inside the guest. Technically, it's not really xenstore's job either. When a device is hotplugged, the toolstack is only responsible for coordinating the establishment of a shared memory channel via xenstore. Typically the backend domain that has the physical device driver runs some hotplug script (e.g. udev on Linux), which results in the toolchain establishing the backend device (in /local/domain/0, although it can also be in another non-0 domain). This backend device (which has a grant reference to a memory ring, usually) then gets passed into the guest VM's xenstore area (/local/domain//) with a unique frontend device id that is selected by the toolchain (xend, libxl, xapi, etc). Xenstore is just acting as a distributed database in the middle of this device dance of toolchains and domains with different privilege levels... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:24:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:24:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuwA-0003eK-OP; Tue, 02 Dec 2014 21:24:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvuw9-0003eF-Eb for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:24:45 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id C9/A2-17735-C1E2E745; Tue, 02 Dec 2014 21:24:44 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-16.tower-31.messagelabs.com!1417555483!15378778!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20183 invoked from network); 2 Dec 2014 21:24:43 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-16.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:24:43 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 88c3672c; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:29:48 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> Date: Tue, 2 Dec 2014 20:44:23 +0000 Message-Id: <31941300-9BB9-4F0F-A185-946CED17C8FE@recoil.org> References: <53E0F76F.4080303@nottingham.ac.uk> <53E10B55.7060107@somerandomidiot.com> <1295FC52-A711-47B4-B832-596931D98C04@recoil.org> <5431A41B.2060001@somerandomidiot.com> <5431B21F.2060407@somerandomidiot.com> <264D91F1-2A11-4B17-9FF7-96DC9D4FB38A@nottingham.ac.uk> <58FF46E1-98A8-499A-9E66-1BCB3816AC95@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Passing tap devices to the main module X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 Dec 2014, at 13:22, Richard Mortier wrote: > > On 6 Oct 2014, at 11:51, Anil Madhavapeddy wrote: > >> On 6 Oct 2014, at 11:43, Richard Mortier wrote: >>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy wrote: >>> >>>> Block devices have another Xenstore numbering scheme that seems far more Linux-specific (and afaict, one that only Dave and Mort understand :-) >>> >>> pshaw. it's in the code. plain for all to see. somewhere. >>> (just don't ask me to remember it... :) >>> >>> in a spirit of functorisation, it seems like one should be able to pass in a function that would generate the next device id as part of the configuration of a unikernel, rather than embedding it in some backend library (or even frontend tool). or perhaps that's what providing a device tree would do? >> >> Yes, but what does 'next' mean here? What happens if you have three devices simultaneously hotplugged? They are mostly independent devices with the only connection being the unique identifier that Xenstore gives then (via the backend toolchain), so it seems odd that one device would be required to give the next one (which is potentially running in a completely separate domain) it's identifier. > > hm-- yes. > > tbh i think i had several misunderstandings, notably that i was assuming that it was the guest's job to register an id for the device in xenstore (under a domain prefix) when the device gets hot plugged into the guest, rather than xenstore's job to give each device an id that's unique inside the guest. Technically, it's not really xenstore's job either. When a device is hotplugged, the toolstack is only responsible for coordinating the establishment of a shared memory channel via xenstore. Typically the backend domain that has the physical device driver runs some hotplug script (e.g. udev on Linux), which results in the toolchain establishing the backend device (in /local/domain/0, although it can also be in another non-0 domain). This backend device (which has a grant reference to a memory ring, usually) then gets passed into the guest VM's xenstore area (/local/domain//) with a unique frontend device id that is selected by the toolchain (xend, libxl, xapi, etc). Xenstore is just acting as a distributed database in the middle of this device dance of toolchains and domains with different privilege levels... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:26:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:26:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuyB-0003gB-1Z; Tue, 02 Dec 2014 21:26:51 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvuy9-0003g6-Gc for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:26:49 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id FC/3A-23865-89E2E745; Tue, 02 Dec 2014 21:26:48 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-31.messagelabs.com!1417555607!12926734!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26063 invoked from network); 2 Dec 2014 21:26:48 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:26:48 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id f2af3a9a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:31:52 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 20:57:37 +0000 Message-Id: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 1 Dec 2014, at 11:04, Thomas Leonard wrote: > > This is taking a bit longer than expected... here's the current status. > > I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by > compiling in an OPAM switch with the right CFLAGS for Mini-OS. > However, we don't want to do it this way because dealing with OPAM > switches is annoying. > > Instead, I'm adding an ocamlfind variable which packages can use to > indicate the C stubs to link against under Xen. e.g. tcpip would put > this in its META file: > > xen_linkopts = "-ltcpip_xen_stubs" > > No libraries will be linked without this option, so we won't > accidentally link Unix libraries. This is important on x86_64, where > linking Unix libraries creates subtle race conditions due to the "red > zone" not being available in kernel mode. All sounds good to me! > > When testing this, I realised we compile openlibm for Unix, so I > updated that to get the CFLAGS from Mini-OS, but it turned out that > didn't work because Mini-OS doesn't provide sys/types.h (just > types.h), and also openlibm used some legacy type names that Mini-OS > doesn't provide. sys/types.h is currently provided by mirage-platform. > > Options: > > 1. Make openlibm depend on mirage-platform to get sys/types.h. > 2. Rename Mini-OS's types.h to sys/types.h and put everything there. > 3. Modify openlibm to use only stdint.h. > > I'm leaning towards option (3) at the moment (assuming it's possible), > but shout if you have a better idea! Isn't 2) a reasonable thing to do as well? is very commonly included due to POSIX, so there seems little harm in making MiniOS's layout comply. > After that, I'll update mirage-profile and tcpip to the new linking > system and make a pull request for the updated mirage tool. You'll > probably need to update several things at once when this happens. > > Then we'll be in a position to add the tls libraries. That might > require a little > extra work if we want to add Xen C stubs to 3rd-party packages (e.g. > zarith). Anil has suggested using OPAM depexts for this. > > Finally, we could really use some pkg-config support in OASIS. > Otherwise, getting the necessary CFLAGS is unreasonably difficult... Yeah. I believe there might be some PRs floating around, but I'd rather put the effort into Assemblage at the moment than shoehorn pkg-config into OASIS at the moment... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:26:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:26:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvuyB-0003gB-1Z; Tue, 02 Dec 2014 21:26:51 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xvuy9-0003g6-Gc for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:26:49 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id FC/3A-23865-89E2E745; Tue, 02 Dec 2014 21:26:48 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-31.messagelabs.com!1417555607!12926734!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26063 invoked from network); 2 Dec 2014 21:26:48 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Dec 2014 21:26:48 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id f2af3a9a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 2 Dec 2014 21:31:52 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 2 Dec 2014 20:57:37 +0000 Message-Id: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 1 Dec 2014, at 11:04, Thomas Leonard wrote: > > This is taking a bit longer than expected... here's the current status. > > I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by > compiling in an OPAM switch with the right CFLAGS for Mini-OS. > However, we don't want to do it this way because dealing with OPAM > switches is annoying. > > Instead, I'm adding an ocamlfind variable which packages can use to > indicate the C stubs to link against under Xen. e.g. tcpip would put > this in its META file: > > xen_linkopts = "-ltcpip_xen_stubs" > > No libraries will be linked without this option, so we won't > accidentally link Unix libraries. This is important on x86_64, where > linking Unix libraries creates subtle race conditions due to the "red > zone" not being available in kernel mode. All sounds good to me! > > When testing this, I realised we compile openlibm for Unix, so I > updated that to get the CFLAGS from Mini-OS, but it turned out that > didn't work because Mini-OS doesn't provide sys/types.h (just > types.h), and also openlibm used some legacy type names that Mini-OS > doesn't provide. sys/types.h is currently provided by mirage-platform. > > Options: > > 1. Make openlibm depend on mirage-platform to get sys/types.h. > 2. Rename Mini-OS's types.h to sys/types.h and put everything there. > 3. Modify openlibm to use only stdint.h. > > I'm leaning towards option (3) at the moment (assuming it's possible), > but shout if you have a better idea! Isn't 2) a reasonable thing to do as well? is very commonly included due to POSIX, so there seems little harm in making MiniOS's layout comply. > After that, I'll update mirage-profile and tcpip to the new linking > system and make a pull request for the updated mirage tool. You'll > probably need to update several things at once when this happens. > > Then we'll be in a position to add the tls libraries. That might > require a little > extra work if we want to add Xen C stubs to 3rd-party packages (e.g. > zarith). Anil has suggested using OPAM depexts for this. > > Finally, we could really use some pkg-config support in OASIS. > Otherwise, getting the necessary CFLAGS is unreasonably difficult... Yeah. I believe there might be some PRs floating around, but I'd rather put the effort into Assemblage at the moment than shoehorn pkg-config into OASIS at the moment... -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:52:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:52:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvvN5-0004b2-Ae; Tue, 02 Dec 2014 21:52:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvvN4-0004ax-Gp for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:52:34 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 7C/B1-03148-1A43E745; Tue, 02 Dec 2014 21:52:33 +0000 X-Env-Sender: unitedbiscuits@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1417557152!7923341!1 X-Originating-IP: [209.85.216.169] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29620 invoked from network); 2 Dec 2014 21:52:32 -0000 Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 21:52:32 -0000 Received: by mail-qc0-f169.google.com with SMTP id w7so10225577qcr.14 for ; Tue, 02 Dec 2014 13:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YVVLJCgBIPNBiOVJBaxi/YrptrpVMk3tZd0PwJ4t1LQ=; b=ySpQmAunfrv6SMjsy4sXM+LKBhLALERLOcNAYOukh/uZnIRg6Vxj05Snrj+MHxnLLJ bySWuy/eiCLjjvNU2PKw75D9M4uVhyo+sehCzsH78Qabc/nJjgM1NtSzImbyq5Gvh+9O Bu8fJ/1d5mMjj4nj/o35bo3n6gkZgJPF+a4IGfsM77FsPUP+Ginb/jdEClYqqwbNDCIU KyRpR0SPHWYAEqNvzUk2gpG5Uh4itrLuZYDMR97kQ+f89dzRb0SZ88+JtZu8tsXu9yAn rJ6g3+Nfg0hd0UuvO8YjpJbAps+rb5Mr+dpIDYaIVqRwyLU7z6k0y0A9Y03bMzOqFU97 TO1g== X-Received: by 10.140.108.201 with SMTP id j67mr2019260qgf.89.1417557151767; Tue, 02 Dec 2014 13:52:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.35.211 with HTTP; Tue, 2 Dec 2014 13:52:11 -0800 (PST) In-Reply-To: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> References: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> From: david Date: Tue, 2 Dec 2014 22:52:11 +0100 Message-ID: To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On Tue, Dec 2, 2014 at 9:57 PM, Anil Madhavapeddy wrote: > On 1 Dec 2014, at 11:04, Thomas Leonard wrote: >> >> Finally, we could really use some pkg-config support in OASIS. >> Otherwise, getting the necessary CFLAGS is unreasonably difficult... > > Yeah. I believe there might be some PRs floating around, but I'd > rather put the effort into Assemblage at the moment than shoehorn > pkg-config into OASIS at the moment... And I'm anxiously reading all news about Assemblage, hoping that I get to use it soon. OASIS turned out to lack quite a bit of flexibility and made me eager to find a replacement. .... but that's probably best expressed through PRs to Assemblage. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 02 21:52:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 02 Dec 2014 21:52:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvvN5-0004b2-Ae; Tue, 02 Dec 2014 21:52:35 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XvvN4-0004ax-Gp for mirageos-devel@lists.xenproject.org; Tue, 02 Dec 2014 21:52:34 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 7C/B1-03148-1A43E745; Tue, 02 Dec 2014 21:52:33 +0000 X-Env-Sender: unitedbiscuits@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1417557152!7923341!1 X-Originating-IP: [209.85.216.169] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29620 invoked from network); 2 Dec 2014 21:52:32 -0000 Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Dec 2014 21:52:32 -0000 Received: by mail-qc0-f169.google.com with SMTP id w7so10225577qcr.14 for ; Tue, 02 Dec 2014 13:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YVVLJCgBIPNBiOVJBaxi/YrptrpVMk3tZd0PwJ4t1LQ=; b=ySpQmAunfrv6SMjsy4sXM+LKBhLALERLOcNAYOukh/uZnIRg6Vxj05Snrj+MHxnLLJ bySWuy/eiCLjjvNU2PKw75D9M4uVhyo+sehCzsH78Qabc/nJjgM1NtSzImbyq5Gvh+9O Bu8fJ/1d5mMjj4nj/o35bo3n6gkZgJPF+a4IGfsM77FsPUP+Ginb/jdEClYqqwbNDCIU KyRpR0SPHWYAEqNvzUk2gpG5Uh4itrLuZYDMR97kQ+f89dzRb0SZ88+JtZu8tsXu9yAn rJ6g3+Nfg0hd0UuvO8YjpJbAps+rb5Mr+dpIDYaIVqRwyLU7z6k0y0A9Y03bMzOqFU97 TO1g== X-Received: by 10.140.108.201 with SMTP id j67mr2019260qgf.89.1417557151767; Tue, 02 Dec 2014 13:52:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.35.211 with HTTP; Tue, 2 Dec 2014 13:52:11 -0800 (PST) In-Reply-To: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> References: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> From: david Date: Tue, 2 Dec 2014 22:52:11 +0100 Message-ID: To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On Tue, Dec 2, 2014 at 9:57 PM, Anil Madhavapeddy wrote: > On 1 Dec 2014, at 11:04, Thomas Leonard wrote: >> >> Finally, we could really use some pkg-config support in OASIS. >> Otherwise, getting the necessary CFLAGS is unreasonably difficult... > > Yeah. I believe there might be some PRs floating around, but I'd > rather put the effort into Assemblage at the moment than shoehorn > pkg-config into OASIS at the moment... And I'm anxiously reading all news about Assemblage, hoping that I get to use it soon. OASIS turned out to lack quite a bit of flexibility and made me eager to find a replacement. .... but that's probably best expressed through PRs to Assemblage. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 09:35:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 09:35:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw6Kv-0005Y3-Dj; Wed, 03 Dec 2014 09:35:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw6Kt-0005Xw-Sp for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 09:35:04 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id C9/3B-07724-749DE745; Wed, 03 Dec 2014 09:35:03 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1417599301!10759095!1 X-Originating-IP: [209.85.220.169] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30320 invoked from network); 3 Dec 2014 09:35:02 -0000 Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 09:35:02 -0000 Received: by mail-vc0-f169.google.com with SMTP id hy10so6673944vcb.28 for ; Wed, 03 Dec 2014 01:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s4krqWKkV//7OgwCuAz6QA/WFb+ChUJ4H9CgN/xEiFw=; b=A433xE9GLzJGq7qyOfhy/SvfVoDWJUimZbmvQX1+A1p+V7SPcw1OaPbYpHGw5nZViQ XoGTKRVsT+K8xPoCHx4gcIMqpc0TD58QI2DJ+ytKsGHLJMHmmQEuz3JxzzNiEalL2sqv Bu+kIf61bznGbGx2zVGkcyU5t4KYt0L7ZdSzE44rysYgnW/A2G2KGzHWhXiVI828np6j IuuhPxa6vwiYi6m7YnCv1WJpQLLLWiHnGg1vcgW77pQ9N8MQQgW5FN8Fo8t4/emZUp99 /S1EVfMbpHD4iM4ywbOXK7hAtISLy85BgGDkGzOsWvJfqoZYG75jJCEb7y7qm/F5647M bO2w== MIME-Version: 1.0 X-Received: by 10.220.250.198 with SMTP id mp6mr2287935vcb.19.1417599301027; Wed, 03 Dec 2014 01:35:01 -0800 (PST) Received: by 10.31.183.134 with HTTP; Wed, 3 Dec 2014 01:35:00 -0800 (PST) In-Reply-To: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> References: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> Date: Wed, 3 Dec 2014 09:35:00 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 December 2014 at 20:57, Anil Madhavapeddy wrote: > On 1 Dec 2014, at 11:04, Thomas Leonard wrote: >> >> This is taking a bit longer than expected... here's the current status. >> >> I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by >> compiling in an OPAM switch with the right CFLAGS for Mini-OS. >> However, we don't want to do it this way because dealing with OPAM >> switches is annoying. >> >> Instead, I'm adding an ocamlfind variable which packages can use to >> indicate the C stubs to link against under Xen. e.g. tcpip would put >> this in its META file: >> >> xen_linkopts = "-ltcpip_xen_stubs" >> >> No libraries will be linked without this option, so we won't >> accidentally link Unix libraries. This is important on x86_64, where >> linking Unix libraries creates subtle race conditions due to the "red >> zone" not being available in kernel mode. > > All sounds good to me! > >> >> When testing this, I realised we compile openlibm for Unix, so I >> updated that to get the CFLAGS from Mini-OS, but it turned out that >> didn't work because Mini-OS doesn't provide sys/types.h (just >> types.h), and also openlibm used some legacy type names that Mini-OS >> doesn't provide. sys/types.h is currently provided by mirage-platform. >> >> Options: >> >> 1. Make openlibm depend on mirage-platform to get sys/types.h. >> 2. Rename Mini-OS's types.h to sys/types.h and put everything there. >> 3. Modify openlibm to use only stdint.h. >> >> I'm leaning towards option (3) at the moment (assuming it's possible), >> but shout if you have a better idea! > > Isn't 2) a reasonable thing to do as well? is very > commonly included due to POSIX, so there seems little harm in making > MiniOS's layout comply. I did start on (2), but it's quite invasive and I'm not sure it really belongs in Mini-OS. The mirage-platform version has legacy support for BSD, GNU, and types like ino_t and pid_t, etc. (3) turned out to be quite simple, and the openlibm people have merged my patch already. There's a PR to compile the new openlibm with Mini-OS headers here: https://github.com/mirage/mirage-xen-minios/pull/10 >> After that, I'll update mirage-profile and tcpip to the new linking >> system and make a pull request for the updated mirage tool. You'll >> probably need to update several things at once when this happens. >> >> Then we'll be in a position to add the tls libraries. That might >> require a little >> extra work if we want to add Xen C stubs to 3rd-party packages (e.g. >> zarith). Anil has suggested using OPAM depexts for this. >> >> Finally, we could really use some pkg-config support in OASIS. >> Otherwise, getting the necessary CFLAGS is unreasonably difficult... > > Yeah. I believe there might be some PRs floating around, but I'd > rather put the effort into Assemblage at the moment than shoehorn > pkg-config into OASIS at the moment... Here's how I'm doing it currently with OASIS: https://github.com/mirage/mirage-tcpip/pull/85 It's a bit messy, but if it's going to be replaced with assemblage soon then it should be OK. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 09:35:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 09:35:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw6Kv-0005Y3-Dj; Wed, 03 Dec 2014 09:35:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw6Kt-0005Xw-Sp for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 09:35:04 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id C9/3B-07724-749DE745; Wed, 03 Dec 2014 09:35:03 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1417599301!10759095!1 X-Originating-IP: [209.85.220.169] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30320 invoked from network); 3 Dec 2014 09:35:02 -0000 Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 09:35:02 -0000 Received: by mail-vc0-f169.google.com with SMTP id hy10so6673944vcb.28 for ; Wed, 03 Dec 2014 01:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s4krqWKkV//7OgwCuAz6QA/WFb+ChUJ4H9CgN/xEiFw=; b=A433xE9GLzJGq7qyOfhy/SvfVoDWJUimZbmvQX1+A1p+V7SPcw1OaPbYpHGw5nZViQ XoGTKRVsT+K8xPoCHx4gcIMqpc0TD58QI2DJ+ytKsGHLJMHmmQEuz3JxzzNiEalL2sqv Bu+kIf61bznGbGx2zVGkcyU5t4KYt0L7ZdSzE44rysYgnW/A2G2KGzHWhXiVI828np6j IuuhPxa6vwiYi6m7YnCv1WJpQLLLWiHnGg1vcgW77pQ9N8MQQgW5FN8Fo8t4/emZUp99 /S1EVfMbpHD4iM4ywbOXK7hAtISLy85BgGDkGzOsWvJfqoZYG75jJCEb7y7qm/F5647M bO2w== MIME-Version: 1.0 X-Received: by 10.220.250.198 with SMTP id mp6mr2287935vcb.19.1417599301027; Wed, 03 Dec 2014 01:35:01 -0800 (PST) Received: by 10.31.183.134 with HTTP; Wed, 3 Dec 2014 01:35:00 -0800 (PST) In-Reply-To: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> References: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> Date: Wed, 3 Dec 2014 09:35:00 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 2 December 2014 at 20:57, Anil Madhavapeddy wrote: > On 1 Dec 2014, at 11:04, Thomas Leonard wrote: >> >> This is taking a bit longer than expected... here's the current status. >> >> I have ocaml-tls working on Xen/ARM (and demoed by Anil at #osio), by >> compiling in an OPAM switch with the right CFLAGS for Mini-OS. >> However, we don't want to do it this way because dealing with OPAM >> switches is annoying. >> >> Instead, I'm adding an ocamlfind variable which packages can use to >> indicate the C stubs to link against under Xen. e.g. tcpip would put >> this in its META file: >> >> xen_linkopts = "-ltcpip_xen_stubs" >> >> No libraries will be linked without this option, so we won't >> accidentally link Unix libraries. This is important on x86_64, where >> linking Unix libraries creates subtle race conditions due to the "red >> zone" not being available in kernel mode. > > All sounds good to me! > >> >> When testing this, I realised we compile openlibm for Unix, so I >> updated that to get the CFLAGS from Mini-OS, but it turned out that >> didn't work because Mini-OS doesn't provide sys/types.h (just >> types.h), and also openlibm used some legacy type names that Mini-OS >> doesn't provide. sys/types.h is currently provided by mirage-platform. >> >> Options: >> >> 1. Make openlibm depend on mirage-platform to get sys/types.h. >> 2. Rename Mini-OS's types.h to sys/types.h and put everything there. >> 3. Modify openlibm to use only stdint.h. >> >> I'm leaning towards option (3) at the moment (assuming it's possible), >> but shout if you have a better idea! > > Isn't 2) a reasonable thing to do as well? is very > commonly included due to POSIX, so there seems little harm in making > MiniOS's layout comply. I did start on (2), but it's quite invasive and I'm not sure it really belongs in Mini-OS. The mirage-platform version has legacy support for BSD, GNU, and types like ino_t and pid_t, etc. (3) turned out to be quite simple, and the openlibm people have merged my patch already. There's a PR to compile the new openlibm with Mini-OS headers here: https://github.com/mirage/mirage-xen-minios/pull/10 >> After that, I'll update mirage-profile and tcpip to the new linking >> system and make a pull request for the updated mirage tool. You'll >> probably need to update several things at once when this happens. >> >> Then we'll be in a position to add the tls libraries. That might >> require a little >> extra work if we want to add Xen C stubs to 3rd-party packages (e.g. >> zarith). Anil has suggested using OPAM depexts for this. >> >> Finally, we could really use some pkg-config support in OASIS. >> Otherwise, getting the necessary CFLAGS is unreasonably difficult... > > Yeah. I believe there might be some PRs floating around, but I'd > rather put the effort into Assemblage at the moment than shoehorn > pkg-config into OASIS at the moment... Here's how I'm doing it currently with OASIS: https://github.com/mirage/mirage-tcpip/pull/85 It's a bit messy, but if it's going to be replaced with assemblage soon then it should be OK. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 10:27:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 10:27:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw79b-0007Id-HZ; Wed, 03 Dec 2014 10:27:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw79a-0007IR-GJ for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 10:27:26 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 0F/09-02696-D85EE745; Wed, 03 Dec 2014 10:27:25 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-11.tower-27.messagelabs.com!1417602444!9342921!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13351 invoked from network); 3 Dec 2014 10:27:24 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-11.tower-27.messagelabs.com with SMTP; 3 Dec 2014 10:27:24 -0000 Received: from [172.20.10.2] (34-224.197-178.cust.bluewin.ch [178.197.224.34]) by smtp.webfaction.com (Postfix) with ESMTP id 3FC8920781EC; Wed, 3 Dec 2014 10:27:23 +0000 (UTC) Date: Wed, 3 Dec 2014 11:27:22 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Leonard Message-ID: <0D42B2605DC446DD91716DD8409802A6@erratique.ch> In-Reply-To: References: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbWVyY3JlZGksIDMgZMOpY2VtYnJlIDIwMTQgw6AgMTA6MzUsIFRob21hcyBMZW9uYXJkIGEg w6ljcml0IDoKPiBJdCdzIGEgYml0IG1lc3N5LCBidXQgaWYgaXQncyBnb2luZyB0byBiZSByZXBs YWNlZCB3aXRoIGFzc2VtYmxhZ2UKPiBzb29uIHRoZW4gaXQgc2hvdWxkIGJlIE9LLgoKSW4gZ2Vu ZXJhbCBJIHdvdWxkIHN0b3AgdGhpbmtpbmcgb2YgYXNzZW1ibGFnZSB3aXRoIHNvb24uIEkgbXlz ZWxmIHdvbid0IGhhdmUgdGltZSB0byB3b3JrIG9uIGl0IGR1cmluZyBhdCBsZWFzdCB0aGUgbmV4 dCBzaXggbW9udGhzLCBUaG9tYXMgRy4gc2FpZCBvbiB0aGUgcGxhdGZvcm0gbGlzdCBoZSBoYXMg bm8gdGltZSBmb3IgaXQgdGhlIG5lYXIgZnV0dXJlIGFuZCBub25lIHNlZW1zIHRvIGJlIGludGVy ZXN0ZWQgaW4gd29ya2luZyBvbiBpdCBhdCB0aGUgbW9tZW50LgoKTWFraW5nIGEgZ29vZCBzeXN0 ZW0gaW4gdGhhdCBhcmVhIGlzIHNvbWV0aGluZyB0aGF0IHdpbGwgdGFrZSB0aW1lIGFuZCB0aGVy ZSBhcmUgc3RpbGwsIG1hbnksIG1hbnkgZGVzaWduIGRlY2lzaW9ucyB0aGF0IG5lZWQgdG8gYmUg ZG9uZSBhdCB0aGUgQVBJIGFuZCBjb25jZXB0dWFsIGxldmVsIChhIHRvdXIgb24gYXNzZW1ibGFn ZSdzIGJ0IG1heSBnaXZlIGEgZmVlbGluZykuIFRoZXJlIGhhdmUgYmVlbiBhbHJlYWR5IHNvIG1h bnkgYXR0ZW1wdHMgaW4gT0NhbWwgYXQgZml4aW5nIHRoZSBidWlsZCBwcm9ibGVtIHRoYXQgSSBk b24ndCB0aGluayBpdCdzIHNhbmUgdG8gdHJ5IHRvIGh1cnJ5IG9yIHByb3Bvc2UgYSBoYWxmIGJh a2VkL2hhbGYgZmluaXNoZWQgc29sdXRpb24sIGVzcGVjaWFsbHkgc2luY2UgYnkgYmVpbmcgYW4g aW5mcmFzdHJ1Y3R1cmUgdG9vbCB0aGlzIGNhbiBxdWlja2x5IGJlY29tZSBhIG1haW50ZW5hbmNl IG5pZ2h0bWFyZSBpZiB3ZSBydXNoIHRvIHB1YmxpY2F0aW9uIHdpdGggYSBiYWRseSBkZXNpZ25l ZCBzeXN0ZW0uICAgCgpTbyBwbGVhc2UgZXZlcnlvbmUgc3RvcCB0aGlua2luZy9mYW50YXN5aW5n IGFib3V0IGFzc2VtYmxhZ2UgYXMgYW4gdXBjb21pbmcgc2lsdmVyIGJ1bGxldCBhbmQgdmlhYmxl IHRvb2wgZm9yIG5vdy4gVHJlYXQgaXQgYXMgdmFwb3Vyd2FyZSBhdCBiZXN0LgoKVGhlc2UgYXJl IG15IHRob3VnaHRzIGFuZCBUaG9tYXMgRy4gbWF5IHRoaW5rIG90aGVyd2lzZS4gIAoKKEl0J3Mg c28gYW5ub3lpbmcgdG8gYmUgYXNzb2NpYXRlZCB0byB0aGUgZGV2ZWxvcG1lbnQgb2YgcHJlLWFu bm91bmNlZCBzb2Z0d2FyZSkKCkJlc3QsCgpEYW5pZWwKCgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1p cmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0 Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 10:27:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 10:27:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw79b-0007Id-HZ; Wed, 03 Dec 2014 10:27:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xw79a-0007IR-GJ for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 10:27:26 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 0F/09-02696-D85EE745; Wed, 03 Dec 2014 10:27:25 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-11.tower-27.messagelabs.com!1417602444!9342921!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13351 invoked from network); 3 Dec 2014 10:27:24 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-11.tower-27.messagelabs.com with SMTP; 3 Dec 2014 10:27:24 -0000 Received: from [172.20.10.2] (34-224.197-178.cust.bluewin.ch [178.197.224.34]) by smtp.webfaction.com (Postfix) with ESMTP id 3FC8920781EC; Wed, 3 Dec 2014 10:27:23 +0000 (UTC) Date: Wed, 3 Dec 2014 11:27:22 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Leonard Message-ID: <0D42B2605DC446DD91716DD8409802A6@erratique.ch> In-Reply-To: References: <593E3748-1FF3-43E9-9DFD-AC54589D46B9@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] TLS packaging status update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbWVyY3JlZGksIDMgZMOpY2VtYnJlIDIwMTQgw6AgMTA6MzUsIFRob21hcyBMZW9uYXJkIGEg w6ljcml0IDoKPiBJdCdzIGEgYml0IG1lc3N5LCBidXQgaWYgaXQncyBnb2luZyB0byBiZSByZXBs YWNlZCB3aXRoIGFzc2VtYmxhZ2UKPiBzb29uIHRoZW4gaXQgc2hvdWxkIGJlIE9LLgoKSW4gZ2Vu ZXJhbCBJIHdvdWxkIHN0b3AgdGhpbmtpbmcgb2YgYXNzZW1ibGFnZSB3aXRoIHNvb24uIEkgbXlz ZWxmIHdvbid0IGhhdmUgdGltZSB0byB3b3JrIG9uIGl0IGR1cmluZyBhdCBsZWFzdCB0aGUgbmV4 dCBzaXggbW9udGhzLCBUaG9tYXMgRy4gc2FpZCBvbiB0aGUgcGxhdGZvcm0gbGlzdCBoZSBoYXMg bm8gdGltZSBmb3IgaXQgdGhlIG5lYXIgZnV0dXJlIGFuZCBub25lIHNlZW1zIHRvIGJlIGludGVy ZXN0ZWQgaW4gd29ya2luZyBvbiBpdCBhdCB0aGUgbW9tZW50LgoKTWFraW5nIGEgZ29vZCBzeXN0 ZW0gaW4gdGhhdCBhcmVhIGlzIHNvbWV0aGluZyB0aGF0IHdpbGwgdGFrZSB0aW1lIGFuZCB0aGVy ZSBhcmUgc3RpbGwsIG1hbnksIG1hbnkgZGVzaWduIGRlY2lzaW9ucyB0aGF0IG5lZWQgdG8gYmUg ZG9uZSBhdCB0aGUgQVBJIGFuZCBjb25jZXB0dWFsIGxldmVsIChhIHRvdXIgb24gYXNzZW1ibGFn ZSdzIGJ0IG1heSBnaXZlIGEgZmVlbGluZykuIFRoZXJlIGhhdmUgYmVlbiBhbHJlYWR5IHNvIG1h bnkgYXR0ZW1wdHMgaW4gT0NhbWwgYXQgZml4aW5nIHRoZSBidWlsZCBwcm9ibGVtIHRoYXQgSSBk b24ndCB0aGluayBpdCdzIHNhbmUgdG8gdHJ5IHRvIGh1cnJ5IG9yIHByb3Bvc2UgYSBoYWxmIGJh a2VkL2hhbGYgZmluaXNoZWQgc29sdXRpb24sIGVzcGVjaWFsbHkgc2luY2UgYnkgYmVpbmcgYW4g aW5mcmFzdHJ1Y3R1cmUgdG9vbCB0aGlzIGNhbiBxdWlja2x5IGJlY29tZSBhIG1haW50ZW5hbmNl IG5pZ2h0bWFyZSBpZiB3ZSBydXNoIHRvIHB1YmxpY2F0aW9uIHdpdGggYSBiYWRseSBkZXNpZ25l ZCBzeXN0ZW0uICAgCgpTbyBwbGVhc2UgZXZlcnlvbmUgc3RvcCB0aGlua2luZy9mYW50YXN5aW5n IGFib3V0IGFzc2VtYmxhZ2UgYXMgYW4gdXBjb21pbmcgc2lsdmVyIGJ1bGxldCBhbmQgdmlhYmxl IHRvb2wgZm9yIG5vdy4gVHJlYXQgaXQgYXMgdmFwb3Vyd2FyZSBhdCBiZXN0LgoKVGhlc2UgYXJl IG15IHRob3VnaHRzIGFuZCBUaG9tYXMgRy4gbWF5IHRoaW5rIG90aGVyd2lzZS4gIAoKKEl0J3Mg c28gYW5ub3lpbmcgdG8gYmUgYXNzb2NpYXRlZCB0byB0aGUgZGV2ZWxvcG1lbnQgb2YgcHJlLWFu bm91bmNlZCBzb2Z0d2FyZSkKCkJlc3QsCgpEYW5pZWwKCgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1p cmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0 Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 13:46:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 13:46:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwAFi-0003nV-Cw; Wed, 03 Dec 2014 13:45:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwAFh-0003nN-PJ; Wed, 03 Dec 2014 13:45:57 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id AA/2C-26652-4141F745; Wed, 03 Dec 2014 13:45:56 +0000 X-Env-Sender: russell.pavlicek@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1417614354!8426226!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5913 invoked from network); 3 Dec 2014 13:45:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 13:45:56 -0000 X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199396524" From: Russell Pavlicek To: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "xen-api@lists.xen.org" , "xen-announce@lists.xenproject.org" , "xs-devel@lists.xenserver.org" , "mirageos-devel@lists.xenproject.org" Thread-Topic: Announcing Xen Project Test Day for 4.5 RC3 on December 4 Thread-Index: AQHQDmhP3KthO1lmv0KpABJgHiXx6A== Date: Wed, 3 Dec 2014 13:45:40 +0000 Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA2050D17DF@SJCPEX01CL03.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: [MirageOS-devel] Announcing Xen Project Test Day for 4.5 RC3 on December 4 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Folks, This Thursday, December 4, is our third Test Day for the 4.5 release cycle. Release Candidate 3 will be available for assessment on Wednesday. Now is the time to see if the upcoming release of the Xen Project Hypervisor will work in your environment. Information about testing this release can be found here: http://wiki.xenproject.org/wiki/Xen_4.5_RC3_test_instructions To learn more about Test Days, including the proposed dates for the RC4 Test Day and final release, check out: http://wiki.xenproject.org/wiki/Xen_Project_Test_Days See you in #xentest on IRC this Thursday for Test Day! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 13:46:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 13:46:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwAFi-0003nV-Cw; Wed, 03 Dec 2014 13:45:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwAFh-0003nN-PJ; Wed, 03 Dec 2014 13:45:57 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id AA/2C-26652-4141F745; Wed, 03 Dec 2014 13:45:56 +0000 X-Env-Sender: russell.pavlicek@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1417614354!8426226!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5913 invoked from network); 3 Dec 2014 13:45:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 13:45:56 -0000 X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="199396524" From: Russell Pavlicek To: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "xen-api@lists.xen.org" , "xen-announce@lists.xenproject.org" , "xs-devel@lists.xenserver.org" , "mirageos-devel@lists.xenproject.org" Thread-Topic: Announcing Xen Project Test Day for 4.5 RC3 on December 4 Thread-Index: AQHQDmhP3KthO1lmv0KpABJgHiXx6A== Date: Wed, 3 Dec 2014 13:45:40 +0000 Message-ID: <55E78A57290FB64FA0D3CF672F9F3DA2050D17DF@SJCPEX01CL03.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: [MirageOS-devel] Announcing Xen Project Test Day for 4.5 RC3 on December 4 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Folks, This Thursday, December 4, is our third Test Day for the 4.5 release cycle. Release Candidate 3 will be available for assessment on Wednesday. Now is the time to see if the upcoming release of the Xen Project Hypervisor will work in your environment. Information about testing this release can be found here: http://wiki.xenproject.org/wiki/Xen_4.5_RC3_test_instructions To learn more about Test Days, including the proposed dates for the RC4 Test Day and final release, check out: http://wiki.xenproject.org/wiki/Xen_Project_Test_Days See you in #xentest on IRC this Thursday for Test Day! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 21:33:00 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 21:33:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHXY-0005Kv-Cv; Wed, 03 Dec 2014 21:32:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHXX-0005Kq-9O for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:32:51 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id CD/74-02707-2818F745; Wed, 03 Dec 2014 21:32:50 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1417642369!11384478!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17588 invoked from network); 3 Dec 2014 21:32:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 21:32:49 -0000 X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="27439379" From: Dave Scott To: "mirageos-devel@lists.xenproject.org" Thread-Topic: refactoring Xen drivers Thread-Index: AQHQD0CuVhVY/qslI0KeymkqTMFUBQ== Date: Wed, 3 Dec 2014 21:32:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <78ECA60E328BA2438CA60A6596C6D56D@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Subject: [MirageOS-devel] refactoring Xen drivers X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGksDQoNCknigJlkIGxpa2UgdG8gbWFrZSB0aGUgWGVuIGRyaXZlcnMgZWFzaWVyIHRvIHRlc3Qg YW5kIG1vcmUgZmxleGlibGUsIHNvIHdlIGNhbiByZS11c2Ugc29tZSBvZiB0aGUgcHJvdG9jb2xz IGZvciBJUEMgdW5kZXIgVW5peC4gSeKAmWQgYWxzbyBsaWtlIHRvIHJlbW92ZSB0aGUg4oCcbGlu a2luZyBoYWNr4oCdIHdoZXJlIHdlIGF2b2lkIGZ1bmN0b3Jpc2luZyB0aGUgZHJpdmVycyBpbiBP Q2FtbCBieSBjaG9vc2luZyBmcm9tIGFsdGVybmF0aXZlIEMgc3R1YnMgYXQgbGluay10aW1lLCB0 aGVyZWJ5IGxvc2luZyBzb21lIG9mIHRoZSBzYWZldHkgd2XigJlkIGhhdmUgbm93IGlmIHdlIGhh ZCBqdXN0IHN0dWNrIHdpdGggT0NhbWzigKYNCg0KQW55d2F5LCBJ4oCZdmUgcHJvdG90eXBlZCBj aGFuZ2VzIHRvIHhlbi1ldnRjaG5bMV0gYW5kIHhlbi1nbnRbMl0uIFRoZXkgbm93IGhhdmUgdGhl IGZvbGxvd2luZyBvY2FtbGZpbmQgc3RydWN0dXJlOg0KDQp4ZW4tZXZ0Y2huOiBwdXJlIE9DYW1s IGRlZmluaXRpb25zLCBpbmNsdWRpbmcgYW4g4oCcRVZFTlRT4oCdIHNpZ25hdHVyZQ0KeGVuLWV2 dGNobi54ZW46IGFuIGltcGxlbWVudGF0aW9uIG9mIOKAnEVWRU5UU+KAnSB3aGljaCBydW5zIGlu IFhlbiBrZXJuZWxzDQp4ZW4tZXZ0Y2huLnhlbmN0cmw6IGFuIGltcGxlbWVudGF0aW9uIG9mIOKA nEVWRU5UU+KAnSB3aGljaCB1c2VzIC9kZXYveGVuL2V2dGNobg0KeGVuLWV2dGNobi51bml4OiBh biBpbXBsZW1lbnRhdGlvbiBvZiDigJxFVkVOVFPigJ0gd2hpY2ggdXNlcyBVbml4IGRvbWFpbiBz b2NrZXRzDQp4ZW4tZXZ0Y2huLmluaGVhcDogYW4gaW1wbGVtZW50YXRpb24gb2Yg4oCcRVZFTlRT 4oCdIHdoaWNoIHVzZXMgTHd0X2NvbmRpdGlvbi50DQoNCnhlbi1nbnQ6IHB1cmUgT0NhbWwgZGVm aW5pdGlvbnMsIGluY2x1ZGluZyBhIOKAnE1FTU9SWeKAnSBzaWduYXR1cmUNCnhlbi1nbnQueGVu OiBhbiBpbXBsZW1lbnRhdGlvbiBvZiDigJxNRU1PUlnigJ0gd2hpY2ggdXNlcyBtaW5pLW9zIGdy YW50IHRhYmxlcw0KeGVuLWdudC54ZW5jdHJsOiBhbiBpbXBsZW1lbnRhdGlvbiBvZiDigJxNRU1P UlnigJ0gd2hpY2ggdXNlcyBnbnRkZXYvZ250c2hyDQp4ZW4tZ250LnVuaXg6IGFuIGltcGxlbWVu dGF0aW9uIG9mIOKAnE1FTU9SWeKAnSB3aGljaCB1c2VzIG1tYXAoMikNCnhlbi1nbnQuaW5oZWFw OiBhbiBpbXBsZW1lbnRhdGlvbiBvZiDigJxNRU1PUlnigJ0gd2hpY2ggdXNlcyBIYXNodGJscyBm dWxsIG9mIGJ1ZmZlcnMNCg0KU28gbm93IGEgdHlwaWNhbCBYZW4gZHJpdmVyLCBzdWNoIGFzIHZj aGFuWzNdLCBjYW4gYmUgYSBmdW5jdG9yIG92ZXIgRVZFTlRTIGFuZCBNRU1PUlksIHBlcm1pdHRp bmcgbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zLiBGb3IgZXhhbXBsZSB0aGVyZSBpcyBhbiBleGFt cGxlIENMSSB3aGljaCB1c2VzIHRoZSB2Y2hhbiBwcm90b2NvbCBiZXR3ZWVuIHR3byBVbml4IHBy b2Nlc3NlcyAoZS5nLiBvbiBPUyBYKSDigJQgbm8gWGVuIGhlYWRlcnMgcmVxdWlyZWQ6DQoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9kanM1NS9vY2FtbC12Y2hhbi9ibG9iL3JlZmFjdG9yLW1vZHVsZXMv UkVBRE1FLm1kDQoNCiAgJCAuL3VuaXhjYXQubmF0aXZlIC1sIDIgZm9vDQogIFhFTl9ST09UPS90 bXAvdW5peGNhdC5uYXRpdmUuMjg1ODUuMDsgZXhwb3J0IFhFTl9ST09UOw0KICBYRU5fQ09ORklH VVJBVElPTj0iKChyaW5nX3JlZiAwKSAoZXZlbnRfY2hhbm5lbCAvdG1wL3VuaXhjYXQubmF0aXZl LjI4NTg1LjAvMCkpIjsgZXhwb3J0IFhFTl9DT05GSUdVUkFUSU9ODQoNCknigJltIHBsYW5uaW5n IG9uIGZ1bmN0b3Jpc2luZyBzaGFyZWQtbWVtb3J5LXJpbmcgb3ZlciB0aGVzZSBzaWduYXR1cmVz IHNvIHdl4oCZbGwgYmUgYWJsZSB0byBydW4gbmV0YmFjay9uZXRmcm9udCBhbmQgYmxrYmFjay9i bGtmcm9udCBiZXR3ZWVuIFVuaXggcHJvY2Vzc2VzIChhbmQgdGVzdCB0aGVtIG1vcmUgd2hpbGUg d2XigJlyZSBhdCBpdCkuIFRoZSDigJhtaXJhZ2XigJkgdG9vbCBjb3VsZCBnZW5lcmF0ZSB0aGUg YXBwcm9wcmlhdGUgZnVuY3RvciBhcHBsaWNhdGlvbiBkZXBlbmRpbmcgb24gdGhlIHRhcmdldCBw bGF0Zm9ybS4NCg0KT25jZSB3ZeKAmXZlIHNvcnRlZCBvdXQgdGhlIGFiaWxpdHkgdG8gYnVpbGQg QyBzdHVicyBmb3IgTWlyYWdlL1hlbiwgdGhlbiB3ZSBjYW4gbW92ZSB0aGUgQyBzdHVicyBmcm9t IG1pcmFnZS1wbGF0Zm9ybSB0byB4ZW4te2V2dGNobixnbnR9Lnhlbiwgd2hpY2ggd2lsbCBtYWtl IGV2ZXJ5dGhpbmcgbG9vayBhIGxvdCBtb3JlIG5vcm1hbC4NCg0KTGV0IG1lIGtub3cgd2hhdCB5 b3UgdGhpbmssDQpEYXZlDQoNClsxXSBodHRwczovL2dpdGh1Yi5jb20vZGpzNTUvb2NhbWwtZXZ0 Y2huL2Jsb2IvcmVmYWN0b3ItbW9kdWxlcy9saWIvcy5tbGkjTDE3DQpbMl0gaHR0cHM6Ly9naXRo dWIuY29tL2RqczU1L29jYW1sLWdudC9ibG9iL3JlZmFjdG9yLW1vZHVsZXMvbGliL3MubWxpI0wx Nw0KWzNdIGh0dHBzOi8vZ2l0aHViLmNvbS9kanM1NS9vY2FtbC12Y2hhbi9ibG9iL3JlZmFjdG9y LW1vZHVsZXMvY2xpL3hlbmNhdC5tbCNMMjENCiAgICBodHRwczovL2dpdGh1Yi5jb20vZGpzNTUv b2NhbWwtdmNoYW4vYmxvYi9yZWZhY3Rvci1tb2R1bGVzL2NsaS91bml4Y2F0Lm1sI0wyMApfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZl bCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDov L2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1k ZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 21:33:00 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 21:33:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHXY-0005Kv-Cv; Wed, 03 Dec 2014 21:32:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHXX-0005Kq-9O for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:32:51 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id CD/74-02707-2818F745; Wed, 03 Dec 2014 21:32:50 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1417642369!11384478!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17588 invoked from network); 3 Dec 2014 21:32:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 21:32:49 -0000 X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="27439379" From: Dave Scott To: "mirageos-devel@lists.xenproject.org" Thread-Topic: refactoring Xen drivers Thread-Index: AQHQD0CuVhVY/qslI0KeymkqTMFUBQ== Date: Wed, 3 Dec 2014 21:32:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <78ECA60E328BA2438CA60A6596C6D56D@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Subject: [MirageOS-devel] refactoring Xen drivers X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGksDQoNCknigJlkIGxpa2UgdG8gbWFrZSB0aGUgWGVuIGRyaXZlcnMgZWFzaWVyIHRvIHRlc3Qg YW5kIG1vcmUgZmxleGlibGUsIHNvIHdlIGNhbiByZS11c2Ugc29tZSBvZiB0aGUgcHJvdG9jb2xz IGZvciBJUEMgdW5kZXIgVW5peC4gSeKAmWQgYWxzbyBsaWtlIHRvIHJlbW92ZSB0aGUg4oCcbGlu a2luZyBoYWNr4oCdIHdoZXJlIHdlIGF2b2lkIGZ1bmN0b3Jpc2luZyB0aGUgZHJpdmVycyBpbiBP Q2FtbCBieSBjaG9vc2luZyBmcm9tIGFsdGVybmF0aXZlIEMgc3R1YnMgYXQgbGluay10aW1lLCB0 aGVyZWJ5IGxvc2luZyBzb21lIG9mIHRoZSBzYWZldHkgd2XigJlkIGhhdmUgbm93IGlmIHdlIGhh ZCBqdXN0IHN0dWNrIHdpdGggT0NhbWzigKYNCg0KQW55d2F5LCBJ4oCZdmUgcHJvdG90eXBlZCBj aGFuZ2VzIHRvIHhlbi1ldnRjaG5bMV0gYW5kIHhlbi1nbnRbMl0uIFRoZXkgbm93IGhhdmUgdGhl IGZvbGxvd2luZyBvY2FtbGZpbmQgc3RydWN0dXJlOg0KDQp4ZW4tZXZ0Y2huOiBwdXJlIE9DYW1s IGRlZmluaXRpb25zLCBpbmNsdWRpbmcgYW4g4oCcRVZFTlRT4oCdIHNpZ25hdHVyZQ0KeGVuLWV2 dGNobi54ZW46IGFuIGltcGxlbWVudGF0aW9uIG9mIOKAnEVWRU5UU+KAnSB3aGljaCBydW5zIGlu IFhlbiBrZXJuZWxzDQp4ZW4tZXZ0Y2huLnhlbmN0cmw6IGFuIGltcGxlbWVudGF0aW9uIG9mIOKA nEVWRU5UU+KAnSB3aGljaCB1c2VzIC9kZXYveGVuL2V2dGNobg0KeGVuLWV2dGNobi51bml4OiBh biBpbXBsZW1lbnRhdGlvbiBvZiDigJxFVkVOVFPigJ0gd2hpY2ggdXNlcyBVbml4IGRvbWFpbiBz b2NrZXRzDQp4ZW4tZXZ0Y2huLmluaGVhcDogYW4gaW1wbGVtZW50YXRpb24gb2Yg4oCcRVZFTlRT 4oCdIHdoaWNoIHVzZXMgTHd0X2NvbmRpdGlvbi50DQoNCnhlbi1nbnQ6IHB1cmUgT0NhbWwgZGVm aW5pdGlvbnMsIGluY2x1ZGluZyBhIOKAnE1FTU9SWeKAnSBzaWduYXR1cmUNCnhlbi1nbnQueGVu OiBhbiBpbXBsZW1lbnRhdGlvbiBvZiDigJxNRU1PUlnigJ0gd2hpY2ggdXNlcyBtaW5pLW9zIGdy YW50IHRhYmxlcw0KeGVuLWdudC54ZW5jdHJsOiBhbiBpbXBsZW1lbnRhdGlvbiBvZiDigJxNRU1P UlnigJ0gd2hpY2ggdXNlcyBnbnRkZXYvZ250c2hyDQp4ZW4tZ250LnVuaXg6IGFuIGltcGxlbWVu dGF0aW9uIG9mIOKAnE1FTU9SWeKAnSB3aGljaCB1c2VzIG1tYXAoMikNCnhlbi1nbnQuaW5oZWFw OiBhbiBpbXBsZW1lbnRhdGlvbiBvZiDigJxNRU1PUlnigJ0gd2hpY2ggdXNlcyBIYXNodGJscyBm dWxsIG9mIGJ1ZmZlcnMNCg0KU28gbm93IGEgdHlwaWNhbCBYZW4gZHJpdmVyLCBzdWNoIGFzIHZj aGFuWzNdLCBjYW4gYmUgYSBmdW5jdG9yIG92ZXIgRVZFTlRTIGFuZCBNRU1PUlksIHBlcm1pdHRp bmcgbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zLiBGb3IgZXhhbXBsZSB0aGVyZSBpcyBhbiBleGFt cGxlIENMSSB3aGljaCB1c2VzIHRoZSB2Y2hhbiBwcm90b2NvbCBiZXR3ZWVuIHR3byBVbml4IHBy b2Nlc3NlcyAoZS5nLiBvbiBPUyBYKSDigJQgbm8gWGVuIGhlYWRlcnMgcmVxdWlyZWQ6DQoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9kanM1NS9vY2FtbC12Y2hhbi9ibG9iL3JlZmFjdG9yLW1vZHVsZXMv UkVBRE1FLm1kDQoNCiAgJCAuL3VuaXhjYXQubmF0aXZlIC1sIDIgZm9vDQogIFhFTl9ST09UPS90 bXAvdW5peGNhdC5uYXRpdmUuMjg1ODUuMDsgZXhwb3J0IFhFTl9ST09UOw0KICBYRU5fQ09ORklH VVJBVElPTj0iKChyaW5nX3JlZiAwKSAoZXZlbnRfY2hhbm5lbCAvdG1wL3VuaXhjYXQubmF0aXZl LjI4NTg1LjAvMCkpIjsgZXhwb3J0IFhFTl9DT05GSUdVUkFUSU9ODQoNCknigJltIHBsYW5uaW5n IG9uIGZ1bmN0b3Jpc2luZyBzaGFyZWQtbWVtb3J5LXJpbmcgb3ZlciB0aGVzZSBzaWduYXR1cmVz IHNvIHdl4oCZbGwgYmUgYWJsZSB0byBydW4gbmV0YmFjay9uZXRmcm9udCBhbmQgYmxrYmFjay9i bGtmcm9udCBiZXR3ZWVuIFVuaXggcHJvY2Vzc2VzIChhbmQgdGVzdCB0aGVtIG1vcmUgd2hpbGUg d2XigJlyZSBhdCBpdCkuIFRoZSDigJhtaXJhZ2XigJkgdG9vbCBjb3VsZCBnZW5lcmF0ZSB0aGUg YXBwcm9wcmlhdGUgZnVuY3RvciBhcHBsaWNhdGlvbiBkZXBlbmRpbmcgb24gdGhlIHRhcmdldCBw bGF0Zm9ybS4NCg0KT25jZSB3ZeKAmXZlIHNvcnRlZCBvdXQgdGhlIGFiaWxpdHkgdG8gYnVpbGQg QyBzdHVicyBmb3IgTWlyYWdlL1hlbiwgdGhlbiB3ZSBjYW4gbW92ZSB0aGUgQyBzdHVicyBmcm9t IG1pcmFnZS1wbGF0Zm9ybSB0byB4ZW4te2V2dGNobixnbnR9Lnhlbiwgd2hpY2ggd2lsbCBtYWtl IGV2ZXJ5dGhpbmcgbG9vayBhIGxvdCBtb3JlIG5vcm1hbC4NCg0KTGV0IG1lIGtub3cgd2hhdCB5 b3UgdGhpbmssDQpEYXZlDQoNClsxXSBodHRwczovL2dpdGh1Yi5jb20vZGpzNTUvb2NhbWwtZXZ0 Y2huL2Jsb2IvcmVmYWN0b3ItbW9kdWxlcy9saWIvcy5tbGkjTDE3DQpbMl0gaHR0cHM6Ly9naXRo dWIuY29tL2RqczU1L29jYW1sLWdudC9ibG9iL3JlZmFjdG9yLW1vZHVsZXMvbGliL3MubWxpI0wx Nw0KWzNdIGh0dHBzOi8vZ2l0aHViLmNvbS9kanM1NS9vY2FtbC12Y2hhbi9ibG9iL3JlZmFjdG9y LW1vZHVsZXMvY2xpL3hlbmNhdC5tbCNMMjENCiAgICBodHRwczovL2dpdGh1Yi5jb20vZGpzNTUv b2NhbWwtdmNoYW4vYmxvYi9yZWZhY3Rvci1tb2R1bGVzL2NsaS91bml4Y2F0Lm1sI0wyMApfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZl bCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDov L2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1k ZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 21:36:42 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 21:36:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHbF-0005Mo-Ow; Wed, 03 Dec 2014 21:36:41 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHbF-0005Mj-32 for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:36:41 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 1E/59-02954-8628F745; Wed, 03 Dec 2014 21:36:40 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1417642599!12737798!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11245 invoked from network); 3 Dec 2014 21:36:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 21:36:39 -0000 X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="27439432" From: Dave Scott To: Anil Madhavapeddy Thread-Topic: [MirageOS-devel] Parallelizing writing to network devices Thread-Index: AQHQCmOIVbOr4bOncka1AHP8aEGGeJx1zcmAgAAMXwCAAFNQgIAIL2gA Date: Wed, 3 Dec 2014 21:36:37 +0000 Message-ID: References: <547757A6.9080504@nottingham.ac.uk> <545318FE-985F-4C42-9CB0-C5A525838E22@citrix.com> <94C8E81B-5545-46A0-9A01-DCA427B2CEE3@recoil.org> In-Reply-To: <94C8E81B-5545-46A0-9A01-DCA427B2CEE3@recoil.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <111DD242611FC54F8B6EE239B1BE02CD@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org DQo+IE9uIDI4IE5vdiAyMDE0LCBhdCAxNjozNiwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVj b2lsLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiAyOCBOb3YgMjAxNCwgYXQgMTE6MzgsIERhdmUgU2Nv dHQgPERhdmUuU2NvdHRAY2l0cml4LmNvbT4gd3JvdGU6DQo+PiANCj4+IEFzIGFuIGFzaWRlLCBJ 4oCZbSBpbiB0aGUgbWlkZGxlIG9mIGZ1bmN0b3Jpc2luZyB0aGUgcmluZyBjb2RlIHRvIG1ha2Ug aXQgbW9yZSBsaWtlIFZjaGFuLiBJbiBwYXJ0aWN1bGFyIHlvdeKAmWxsIGJlIGFibGUgdG8gaW5z dGFudGlhdGUgdGhlIGZ1bmN0b3Igd2l0aCBhbnkgc3VpdGFibGUgbWVtb3J5IHNoYXJpbmcgYW5k IGV2ZW50IHNpZ25hbGxpbmcgcHJpbWl0aXZlcy4gVGhpcyBtZWFucyB3ZeKAmWxsIGJlIGFibGUg dG8gcnVuIHRoZSBjb2RlIGluIHNldmVyYWwgZGlmZmVyZW50IGVudmlyb25tZW50cw0KPj4gDQo+ PiAtIGluLXByb2Nlc3Mgd2hlcmUgbWVtb3J5IHNoYXJpbmcgaXMgdHJpdmlhbCBhbmQgZXZlbnQg c2lnbmFsbGluZyB1c2VzIEx3dF9jb25kaXRpb24udC4gVGhpcyBpcyBnb29kIGZvciB1bml0LXRl c3RzDQo+PiAtIGNyb3NzLXByb2Nlc3MgdW5kZXIgVW5peCB3aGVyZSBtZW1vcnkgc2hhcmluZyBp cyB2aWEgc29tZXRoaW5nIGxpa2UgL2Rldi9zaG0gYW5kIHNpZ25hbGxpbmcgdmlhIGV2ZW50ZmQg b3IgcGlwZXM/IChTdWdnZXN0aW9ucyB3ZWxjb21lKQ0KPiANCj4gSSdkIHN1Z2dlc3Qgc3RhcnRp bmcgb2ZmIHdpdGggY29yZSBQT1NJWCBpbnRlcmZhY2VzIHN1Y2ggYXMgYSBwaXBlIGZvciBzeW5j aHJvbmlzYXRpb24gYW5kIEJpZ2FycmF5Lm1hcF9maWxlIGZvciBzaGFyZWQgbWVtb3J5Lg0KDQpJ 4oCZdmUgbm93IGltcGxlbWVudGVkIHRoZXNlIGFuZCBnb3QgdmNoYW4gd29ya2luZyBjcm9zcy1w cm9jZXNzLg0KDQpXaGVuIEnigJl2ZSBmaW5pc2hlZCB0aGUgcmVmYWN0b3IgaXQgc2hvdWxkIGJl IHBvc3NpYmxlIHRvIHJ1biBuZXRmcm9udC9uZXRiYWNrIGJldHdlZW4gcHJvY2Vzc2VzIHdoaWNo IHNob3VsZCBpbmNyZWFzZSB0aGVpciBkZWJ1Zy1hYmlsaXR5LiBBIHNsaWdodCBzbmFnIGlzIHRo YXQgd2UgaGF2ZW7igJl0IGdvdCBhbiBpbXBsZW1lbnRhdGlvbiBvZiBuZXRiYWNrIHlldCwgYnV0 IGl0IHNob3VsZG7igJl0IGJlIGRpZmZpY3VsdCB0byBjcmVhdGUuIE9uY2Ugd2UgaGF2ZSBib3Ro IGZyb250IGFuZCBiYWNrIHdlIGNhbiBhbHNvIGhhdmUgc29tZSBuaWNlIHRlc3RzIGluIHRoZSBy ZXBvIGFuZCBydW4gdGhlbSBmcm9tIHRyYXZpcy4NCg0KQ2hlZXJzLA0KRGF2ZQ0KDQo+IA0KPiBF dmVudGZkIGFuZCAvZGV2L3NobSBhcmUgTGludXgtaXNtcyB0aGF0IHdlIGNhbiBhZGQgbGF0ZXIg YnkgY2hlcnJ5IHBpY2tpbmcgcmluZyBBUElzIGZyb20gdGhlIElQQyBiZW5jaCByZXBvc2l0b3J5 OiBodHRwczovL2dpdGh1Yi5jb20vYXZzbS9pcGMtYmVuY2guICBUaGVyZSBhcmUgYmxpbmRpbmds eSBmYXN0IHByb3RvY29scyBpbiB0aGVyZSBpZiBzcGlubmluZyBpcyBhbiBvcHRpb24sIGZvciBl eGFtcGxlLg0KPiANCj4+IC0gYXMgYSBYZW4gYmFja2VuZC9mcm9udGVuZCB1bmRlciBMaW51eCB3 aGVyZSBtZW1vcnkgc2hhcmluZyBpcyB2aWEgZ250ZGV2L2dudHNociBhbmQgZXZlbnRzIGFyZSB2 aWEgL2Rldi94ZW4vZXZ0Y2huDQo+PiAtIHVuZGVyIFhlbiBhcyBub3JtYWwNCj4+IA0KPj4gSSBy ZWFsbHkgd2FudCB0byBiZSBhYmxlIHRvIHJ1biAyIHV0b3Agc2hlbGxzLCAjcmVxdWlyZSB0aGUg Y29kZSwgaW5zdGFudGlhdGUgdGhlIGZ1bmN0b3IgZm9yIFVuaXggYW5kIGhhdmUgWGVuIG5ldGZy b250L25ldGJhY2sgYmV0d2VlbiByZWd1bGFyIHByb2Nlc3NlcyB1bmRlciBPUyBYLg0KPiANCj4g QWxsIHRob3NlIHdvcmRzIHNvdW5kIGdvb2QgdG8gbWUgOikNCj4gDQo+IEFuaWwNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwg bWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9s aXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2 ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 21:36:42 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 21:36:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHbF-0005Mo-Ow; Wed, 03 Dec 2014 21:36:41 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHbF-0005Mj-32 for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:36:41 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 1E/59-02954-8628F745; Wed, 03 Dec 2014 21:36:40 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1417642599!12737798!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11245 invoked from network); 3 Dec 2014 21:36:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 21:36:39 -0000 X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="scan'208";a="27439432" From: Dave Scott To: Anil Madhavapeddy Thread-Topic: [MirageOS-devel] Parallelizing writing to network devices Thread-Index: AQHQCmOIVbOr4bOncka1AHP8aEGGeJx1zcmAgAAMXwCAAFNQgIAIL2gA Date: Wed, 3 Dec 2014 21:36:37 +0000 Message-ID: References: <547757A6.9080504@nottingham.ac.uk> <545318FE-985F-4C42-9CB0-C5A525838E22@citrix.com> <94C8E81B-5545-46A0-9A01-DCA427B2CEE3@recoil.org> In-Reply-To: <94C8E81B-5545-46A0-9A01-DCA427B2CEE3@recoil.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <111DD242611FC54F8B6EE239B1BE02CD@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org DQo+IE9uIDI4IE5vdiAyMDE0LCBhdCAxNjozNiwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVj b2lsLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiAyOCBOb3YgMjAxNCwgYXQgMTE6MzgsIERhdmUgU2Nv dHQgPERhdmUuU2NvdHRAY2l0cml4LmNvbT4gd3JvdGU6DQo+PiANCj4+IEFzIGFuIGFzaWRlLCBJ 4oCZbSBpbiB0aGUgbWlkZGxlIG9mIGZ1bmN0b3Jpc2luZyB0aGUgcmluZyBjb2RlIHRvIG1ha2Ug aXQgbW9yZSBsaWtlIFZjaGFuLiBJbiBwYXJ0aWN1bGFyIHlvdeKAmWxsIGJlIGFibGUgdG8gaW5z dGFudGlhdGUgdGhlIGZ1bmN0b3Igd2l0aCBhbnkgc3VpdGFibGUgbWVtb3J5IHNoYXJpbmcgYW5k IGV2ZW50IHNpZ25hbGxpbmcgcHJpbWl0aXZlcy4gVGhpcyBtZWFucyB3ZeKAmWxsIGJlIGFibGUg dG8gcnVuIHRoZSBjb2RlIGluIHNldmVyYWwgZGlmZmVyZW50IGVudmlyb25tZW50cw0KPj4gDQo+ PiAtIGluLXByb2Nlc3Mgd2hlcmUgbWVtb3J5IHNoYXJpbmcgaXMgdHJpdmlhbCBhbmQgZXZlbnQg c2lnbmFsbGluZyB1c2VzIEx3dF9jb25kaXRpb24udC4gVGhpcyBpcyBnb29kIGZvciB1bml0LXRl c3RzDQo+PiAtIGNyb3NzLXByb2Nlc3MgdW5kZXIgVW5peCB3aGVyZSBtZW1vcnkgc2hhcmluZyBp cyB2aWEgc29tZXRoaW5nIGxpa2UgL2Rldi9zaG0gYW5kIHNpZ25hbGxpbmcgdmlhIGV2ZW50ZmQg b3IgcGlwZXM/IChTdWdnZXN0aW9ucyB3ZWxjb21lKQ0KPiANCj4gSSdkIHN1Z2dlc3Qgc3RhcnRp bmcgb2ZmIHdpdGggY29yZSBQT1NJWCBpbnRlcmZhY2VzIHN1Y2ggYXMgYSBwaXBlIGZvciBzeW5j aHJvbmlzYXRpb24gYW5kIEJpZ2FycmF5Lm1hcF9maWxlIGZvciBzaGFyZWQgbWVtb3J5Lg0KDQpJ 4oCZdmUgbm93IGltcGxlbWVudGVkIHRoZXNlIGFuZCBnb3QgdmNoYW4gd29ya2luZyBjcm9zcy1w cm9jZXNzLg0KDQpXaGVuIEnigJl2ZSBmaW5pc2hlZCB0aGUgcmVmYWN0b3IgaXQgc2hvdWxkIGJl IHBvc3NpYmxlIHRvIHJ1biBuZXRmcm9udC9uZXRiYWNrIGJldHdlZW4gcHJvY2Vzc2VzIHdoaWNo IHNob3VsZCBpbmNyZWFzZSB0aGVpciBkZWJ1Zy1hYmlsaXR5LiBBIHNsaWdodCBzbmFnIGlzIHRo YXQgd2UgaGF2ZW7igJl0IGdvdCBhbiBpbXBsZW1lbnRhdGlvbiBvZiBuZXRiYWNrIHlldCwgYnV0 IGl0IHNob3VsZG7igJl0IGJlIGRpZmZpY3VsdCB0byBjcmVhdGUuIE9uY2Ugd2UgaGF2ZSBib3Ro IGZyb250IGFuZCBiYWNrIHdlIGNhbiBhbHNvIGhhdmUgc29tZSBuaWNlIHRlc3RzIGluIHRoZSBy ZXBvIGFuZCBydW4gdGhlbSBmcm9tIHRyYXZpcy4NCg0KQ2hlZXJzLA0KRGF2ZQ0KDQo+IA0KPiBF dmVudGZkIGFuZCAvZGV2L3NobSBhcmUgTGludXgtaXNtcyB0aGF0IHdlIGNhbiBhZGQgbGF0ZXIg YnkgY2hlcnJ5IHBpY2tpbmcgcmluZyBBUElzIGZyb20gdGhlIElQQyBiZW5jaCByZXBvc2l0b3J5 OiBodHRwczovL2dpdGh1Yi5jb20vYXZzbS9pcGMtYmVuY2guICBUaGVyZSBhcmUgYmxpbmRpbmds eSBmYXN0IHByb3RvY29scyBpbiB0aGVyZSBpZiBzcGlubmluZyBpcyBhbiBvcHRpb24sIGZvciBl eGFtcGxlLg0KPiANCj4+IC0gYXMgYSBYZW4gYmFja2VuZC9mcm9udGVuZCB1bmRlciBMaW51eCB3 aGVyZSBtZW1vcnkgc2hhcmluZyBpcyB2aWEgZ250ZGV2L2dudHNociBhbmQgZXZlbnRzIGFyZSB2 aWEgL2Rldi94ZW4vZXZ0Y2huDQo+PiAtIHVuZGVyIFhlbiBhcyBub3JtYWwNCj4+IA0KPj4gSSBy ZWFsbHkgd2FudCB0byBiZSBhYmxlIHRvIHJ1biAyIHV0b3Agc2hlbGxzLCAjcmVxdWlyZSB0aGUg Y29kZSwgaW5zdGFudGlhdGUgdGhlIGZ1bmN0b3IgZm9yIFVuaXggYW5kIGhhdmUgWGVuIG5ldGZy b250L25ldGJhY2sgYmV0d2VlbiByZWd1bGFyIHByb2Nlc3NlcyB1bmRlciBPUyBYLg0KPiANCj4g QWxsIHRob3NlIHdvcmRzIHNvdW5kIGdvb2QgdG8gbWUgOikNCj4gDQo+IEFuaWwNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwg bWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9s aXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2 ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 21:38:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 21:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHd6-0005OV-Vo; Wed, 03 Dec 2014 21:38:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHd5-0005OQ-VX for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:38:36 +0000 Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id 41/26-11581-BD28F745; Wed, 03 Dec 2014 21:38:35 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1417642714!8041600!1 X-Originating-IP: [74.125.82.52] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20612 invoked from network); 3 Dec 2014 21:38:34 -0000 Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com) (74.125.82.52) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 21:38:34 -0000 Received: by mail-wg0-f52.google.com with SMTP id a1so21001897wgh.25 for ; Wed, 03 Dec 2014 13:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KRAxpMNygiclKFGxWOX0pxHFZuaBmRZHGJwKTnzKnKk=; b=d+P77vHtc9C/KsXBZv0C76h8YiUnCkA8dgtCRbg2rj7X660rNIjYUaYOSASEhZP+Cz ZvRkWGOkGgT2uXSVt2PN+AJGLuGDaIwFFyorCsWiW5Y9CscxJ7X2PVpJcs9S/Os8yGxS UFFa0rTlb0PQOxdTbCHw9icRZoELxOg8pQXFLCjkJPo6o9mBCcuA5KslK0UVKxZSlymd rsfn9EzAXZVXboDbAciCzgy3NQdpcSBNWFwqaYFa/i00FMA2KM+DwB/w5HpNG+T+DYL8 KrHSRBVvgFJBbN3ffWzX8CwRHYc99YDYqgqVZfZl/ISfmeWu2/pKj5GnwG5RjQN0usRj 020Q== X-Received: by 10.194.62.19 with SMTP id u19mr11150556wjr.0.1417642714280; Wed, 03 Dec 2014 13:38:34 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id mc10sm52362292wic.24.2014.12.03.13.38.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 13:38:33 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Wed, 3 Dec 2014 21:38:31 +0000 Message-Id: <139B87D1-4F08-4B78-980D-408C3893A6C3@gazagnaire.org> References: To: Dave Scott X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] refactoring Xen drivers X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhdCdzIGdyZWF0IQoKPiB4ZW4tZXZ0Y2huLmluaGVhcDogYW4gaW1wbGVtZW50YXRpb24gb2Yg 4oCcRVZFTlRT4oCdIHdoaWNoIHVzZXMgTHd0X2NvbmRpdGlvbi50CgpJIHRlbmQgdG8gdXNlICJN ZW1vcnkiIG9yICJJbl9tZW1vcnkiIGluIG15IGxpYnMsIGJ1dCBpbmhlYXAgc2VlbXMgbW9yZSBw cmVjaXNlLiBJIG1pZ2h0IHN3aXRjaCBteSBuYW1pbmcgc2NoZW1lIHRvIGZvbGxvdyB5b3VycyA6 LSkKCj4geGVuLWdudDogcHVyZSBPQ2FtbCBkZWZpbml0aW9ucywgaW5jbHVkaW5nIGEg4oCcTUVN T1JZ4oCdIHNpZ25hdHVyZQoKV2hlbiB0aGlzIHNpZ3MgYmVjb21lIG1vcmUgc3RhYmxlLCBpdCB3 aWxsIG1heWJlIG1ha2Ugc2Vuc2UgdG8gbW92ZSB0aGVtIHRvIG1pcmFnZS10eXBlcyBhbmQgYWRk IHByb3BlciBjb21iaW5hdG9ycyBmb3IgdGhlbSBpbiB0aGUgbWlyYWdlIERTTC4KClRob21hcwpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1k ZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vv cy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Dec 03 21:38:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 03 Dec 2014 21:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHd6-0005OV-Vo; Wed, 03 Dec 2014 21:38:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwHd5-0005OQ-VX for mirageos-devel@lists.xenproject.org; Wed, 03 Dec 2014 21:38:36 +0000 Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id 41/26-11581-BD28F745; Wed, 03 Dec 2014 21:38:35 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1417642714!8041600!1 X-Originating-IP: [74.125.82.52] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20612 invoked from network); 3 Dec 2014 21:38:34 -0000 Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com) (74.125.82.52) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Dec 2014 21:38:34 -0000 Received: by mail-wg0-f52.google.com with SMTP id a1so21001897wgh.25 for ; Wed, 03 Dec 2014 13:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KRAxpMNygiclKFGxWOX0pxHFZuaBmRZHGJwKTnzKnKk=; b=d+P77vHtc9C/KsXBZv0C76h8YiUnCkA8dgtCRbg2rj7X660rNIjYUaYOSASEhZP+Cz ZvRkWGOkGgT2uXSVt2PN+AJGLuGDaIwFFyorCsWiW5Y9CscxJ7X2PVpJcs9S/Os8yGxS UFFa0rTlb0PQOxdTbCHw9icRZoELxOg8pQXFLCjkJPo6o9mBCcuA5KslK0UVKxZSlymd rsfn9EzAXZVXboDbAciCzgy3NQdpcSBNWFwqaYFa/i00FMA2KM+DwB/w5HpNG+T+DYL8 KrHSRBVvgFJBbN3ffWzX8CwRHYc99YDYqgqVZfZl/ISfmeWu2/pKj5GnwG5RjQN0usRj 020Q== X-Received: by 10.194.62.19 with SMTP id u19mr11150556wjr.0.1417642714280; Wed, 03 Dec 2014 13:38:34 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id mc10sm52362292wic.24.2014.12.03.13.38.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 13:38:33 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Wed, 3 Dec 2014 21:38:31 +0000 Message-Id: <139B87D1-4F08-4B78-980D-408C3893A6C3@gazagnaire.org> References: To: Dave Scott X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] refactoring Xen drivers X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhdCdzIGdyZWF0IQoKPiB4ZW4tZXZ0Y2huLmluaGVhcDogYW4gaW1wbGVtZW50YXRpb24gb2Yg 4oCcRVZFTlRT4oCdIHdoaWNoIHVzZXMgTHd0X2NvbmRpdGlvbi50CgpJIHRlbmQgdG8gdXNlICJN ZW1vcnkiIG9yICJJbl9tZW1vcnkiIGluIG15IGxpYnMsIGJ1dCBpbmhlYXAgc2VlbXMgbW9yZSBw cmVjaXNlLiBJIG1pZ2h0IHN3aXRjaCBteSBuYW1pbmcgc2NoZW1lIHRvIGZvbGxvdyB5b3VycyA6 LSkKCj4geGVuLWdudDogcHVyZSBPQ2FtbCBkZWZpbml0aW9ucywgaW5jbHVkaW5nIGEg4oCcTUVN T1JZ4oCdIHNpZ25hdHVyZQoKV2hlbiB0aGlzIHNpZ3MgYmVjb21lIG1vcmUgc3RhYmxlLCBpdCB3 aWxsIG1heWJlIG1ha2Ugc2Vuc2UgdG8gbW92ZSB0aGVtIHRvIG1pcmFnZS10eXBlcyBhbmQgYWRk IHByb3BlciBjb21iaW5hdG9ycyBmb3IgdGhlbSBpbiB0aGUgbWlyYWdlIERTTC4KClRob21hcwpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1k ZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vv cy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 12:43:23 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 12:43:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVka-0002iF-L8; Thu, 04 Dec 2014 12:43:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVkX-0002iA-EF for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:43:14 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 03/68-22819-0E650845; Thu, 04 Dec 2014 12:43:12 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1417696991!11526708!1 X-Originating-IP: [209.85.220.181] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16349 invoked from network); 4 Dec 2014 12:43:11 -0000 Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com) (209.85.220.181) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 12:43:11 -0000 Received: by mail-vc0-f181.google.com with SMTP id le20so7735960vcb.26 for ; Thu, 04 Dec 2014 04:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rtyvyV0hl4z//fXme0UaaxgjM/hxdadMT6L42MmFIYQ=; b=D2az0E4r6nBkFSWOmCc6/2s35fP2dsdeQequsJF3JrezY46wbcHe0TUxmDf2QQ9r1l RyoRhtu+SgFGfM7kwOZCRvXgq5D0IEV6gUJD4qGBlz3HPQE2xc7anMfHGpQd/1W33f3A CNE2wgIMT83UAdLvTmDjYWUMg8tu8gu6a9HAcWsi6TByhHwffbKCusBY1l6yeBGJ9F9b Z4R9yEUy6hmMXL7SMZALiLnXeGnC4cpNPh+bmUOGyr901gFNCdrB7Kgz46DZJ1vVOLpx n6rNIh7WuQExSKA7QGpSeYqZ7ysO0jsI5DaQAcjMbwiWEJfjDyAbARhTy0XXbNN/COl0 HAyQ== MIME-Version: 1.0 X-Received: by 10.221.29.136 with SMTP id ry8mr5331880vcb.26.1417696990713; Thu, 04 Dec 2014 04:43:10 -0800 (PST) Received: by 10.31.183.134 with HTTP; Thu, 4 Dec 2014 04:43:10 -0800 (PST) Date: Thu, 4 Dec 2014 12:43:10 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Xen C stubs / profiling / TLS / status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I'm currently working on upstreaming the profiling/tracing support for Mirage, and also on fixing the C compilation problems on Xen/x86 (needed for TLS on Xen). I now have quite a few pull requests open and managing all the various branches is getting tricky (not least because of the Mirage practice of keeping OASIS files and changelogs under version control, making every PR conflict with every other). If someone could merge a few of them, that would help a lot! (I think I have permission to do it myself, but that seems rude and having someone else review them is always useful) For example, on mirage-platform, I have: https://github.com/mirage/mirage-platform/pull/108 (Use monotonic time for events) https://github.com/mirage/mirage-platform/pull/107 (Add some more C functions for the TLS libraries) https://github.com/mirage/mirage-platform/pull/105 (Depend on mirage-profile to add tracing support) Merging #108 would not only fix sleep on Xen/x86, but would also unblock https://github.com/mirage/mirage-profile/pull/2 (Remove C stubs for adding timestamp on Xen) after which I could merge the mirage-profile mvars thread: https://github.com/mirage/mirage-profile/tree/mvars which would allow me to make a PR for the tracing work on tcpip. That, in turn, would be easier to manage if these PRs were merged first: https://github.com/mirage/mirage-tcpip/pull/86 (Fixed race waiting for ARP response) https://github.com/mirage/mirage-tcpip/pull/85 (Build Xen stubs separately, with CFLAGS from Mini-OS) Merging #85 would, in particular, unblock: https://github.com/mirage/mirage/pull/332 (Get Xen linker options from ocamlfind xen_linkopts variables) (which also depends on mirage-profile/pull/2, which is blocked by mirage-platform#108) Thanks! -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 12:43:23 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 12:43:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVka-0002iF-L8; Thu, 04 Dec 2014 12:43:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVkX-0002iA-EF for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:43:14 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 03/68-22819-0E650845; Thu, 04 Dec 2014 12:43:12 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1417696991!11526708!1 X-Originating-IP: [209.85.220.181] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16349 invoked from network); 4 Dec 2014 12:43:11 -0000 Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com) (209.85.220.181) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 12:43:11 -0000 Received: by mail-vc0-f181.google.com with SMTP id le20so7735960vcb.26 for ; Thu, 04 Dec 2014 04:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rtyvyV0hl4z//fXme0UaaxgjM/hxdadMT6L42MmFIYQ=; b=D2az0E4r6nBkFSWOmCc6/2s35fP2dsdeQequsJF3JrezY46wbcHe0TUxmDf2QQ9r1l RyoRhtu+SgFGfM7kwOZCRvXgq5D0IEV6gUJD4qGBlz3HPQE2xc7anMfHGpQd/1W33f3A CNE2wgIMT83UAdLvTmDjYWUMg8tu8gu6a9HAcWsi6TByhHwffbKCusBY1l6yeBGJ9F9b Z4R9yEUy6hmMXL7SMZALiLnXeGnC4cpNPh+bmUOGyr901gFNCdrB7Kgz46DZJ1vVOLpx n6rNIh7WuQExSKA7QGpSeYqZ7ysO0jsI5DaQAcjMbwiWEJfjDyAbARhTy0XXbNN/COl0 HAyQ== MIME-Version: 1.0 X-Received: by 10.221.29.136 with SMTP id ry8mr5331880vcb.26.1417696990713; Thu, 04 Dec 2014 04:43:10 -0800 (PST) Received: by 10.31.183.134 with HTTP; Thu, 4 Dec 2014 04:43:10 -0800 (PST) Date: Thu, 4 Dec 2014 12:43:10 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Xen C stubs / profiling / TLS / status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I'm currently working on upstreaming the profiling/tracing support for Mirage, and also on fixing the C compilation problems on Xen/x86 (needed for TLS on Xen). I now have quite a few pull requests open and managing all the various branches is getting tricky (not least because of the Mirage practice of keeping OASIS files and changelogs under version control, making every PR conflict with every other). If someone could merge a few of them, that would help a lot! (I think I have permission to do it myself, but that seems rude and having someone else review them is always useful) For example, on mirage-platform, I have: https://github.com/mirage/mirage-platform/pull/108 (Use monotonic time for events) https://github.com/mirage/mirage-platform/pull/107 (Add some more C functions for the TLS libraries) https://github.com/mirage/mirage-platform/pull/105 (Depend on mirage-profile to add tracing support) Merging #108 would not only fix sleep on Xen/x86, but would also unblock https://github.com/mirage/mirage-profile/pull/2 (Remove C stubs for adding timestamp on Xen) after which I could merge the mirage-profile mvars thread: https://github.com/mirage/mirage-profile/tree/mvars which would allow me to make a PR for the tracing work on tcpip. That, in turn, would be easier to manage if these PRs were merged first: https://github.com/mirage/mirage-tcpip/pull/86 (Fixed race waiting for ARP response) https://github.com/mirage/mirage-tcpip/pull/85 (Build Xen stubs separately, with CFLAGS from Mini-OS) Merging #85 would, in particular, unblock: https://github.com/mirage/mirage/pull/332 (Get Xen linker options from ocamlfind xen_linkopts variables) (which also depends on mirage-profile/pull/2, which is blocked by mirage-platform#108) Thanks! -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 12:44:18 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 12:44:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVla-0002jp-R8; Thu, 04 Dec 2014 12:44:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVla-0002jk-AP for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:44:18 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 25/4C-15461-12750845; Thu, 04 Dec 2014 12:44:17 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1417697056!13054094!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23130 invoked from network); 4 Dec 2014 12:44:17 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 12:44:17 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id e7f05738; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 4 Dec 2014 12:49:27 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 4 Dec 2014 12:44:15 +0000 Message-Id: References: To: David Scott X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] refactoring Xen drivers X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMyBEZWMgMjAxNCwgYXQgMjE6MzIsIERhdmUgU2NvdHQgPERhdmUuU2NvdHRAY2l0cml4LmNv bT4gd3JvdGU6Cj4gSeKAmW0gcGxhbm5pbmcgb24gZnVuY3RvcmlzaW5nIHNoYXJlZC1tZW1vcnkt cmluZyBvdmVyIHRoZXNlIHNpZ25hdHVyZXMgc28gd2XigJlsbCBiZSBhYmxlIHRvIHJ1biBuZXRi YWNrL25ldGZyb250IGFuZCBibGtiYWNrL2Jsa2Zyb250IGJldHdlZW4gVW5peCBwcm9jZXNzZXMg KGFuZCB0ZXN0IHRoZW0gbW9yZSB3aGlsZSB3ZeKAmXJlIGF0IGl0KS4gVGhlIOKAmG1pcmFnZeKA mSB0b29sIGNvdWxkIGdlbmVyYXRlIHRoZSBhcHByb3ByaWF0ZSBmdW5jdG9yIGFwcGxpY2F0aW9u IGRlcGVuZGluZyBvbiB0aGUgdGFyZ2V0IHBsYXRmb3JtLgo+IAo+IE9uY2Ugd2XigJl2ZSBzb3J0 ZWQgb3V0IHRoZSBhYmlsaXR5IHRvIGJ1aWxkIEMgc3R1YnMgZm9yIE1pcmFnZS9YZW4sIHRoZW4g d2UgY2FuIG1vdmUgdGhlIEMgc3R1YnMgZnJvbSBtaXJhZ2UtcGxhdGZvcm0gdG8geGVuLXtldnRj aG4sZ250fS54ZW4sIHdoaWNoIHdpbGwgbWFrZSBldmVyeXRoaW5nIGxvb2sgYSBsb3QgbW9yZSBu b3JtYWwuCj4gCj4gTGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmssCj4gRGF2ZQoKRnVsbCBzdXBw b3J0IGZyb20gbWUuICBUaGlzIHdpbGwgaGF2ZSB0aGUgcmVtYXJrYWJsZSBlZmZlY3Qgb2YgbGV0 dGluZyB1cyBiZW5jaG1hcmsgWGVuIGRldmljZSBkcml2ZXIgcGVyZm9ybWFuY2UgKGZyb20gdGhl IHBlcnNwZWN0aXZlIG9mIHJpbmcgdXRpbGlzYXRpb24gYW5kIHNvIGZvcnRoKSBmcm9tIHVzZXJz cGFjZSBpbiBNYWNPUyBYLCBhbmQgZXZlbiBidWlsZCBmcm9udGVuZC9iYWNrZW5kIGRyaXZlcnMg d2l0aG91dCBuZWVkaW5nIFhlbi4KCkF0IGEgcXVpY2sgZ2xhbmNlLCBpdCBzaG91bGQgYWxzbyBi ZSBwb3NzaWJsZSB0byBidWlsZCBhbiBYUEMgbGF5ZXIgZm9yIE1hY09TIFggc2FuZGJveGluZyBm cm9tIHlvdXIgZXZlbnQgc2lnbmF0dXJlcy4uLgoKLWFuaWwKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1p cmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0 Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 12:44:18 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 12:44:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVla-0002jp-R8; Thu, 04 Dec 2014 12:44:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwVla-0002jk-AP for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 12:44:18 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 25/4C-15461-12750845; Thu, 04 Dec 2014 12:44:17 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1417697056!13054094!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23130 invoked from network); 4 Dec 2014 12:44:17 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 12:44:17 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id e7f05738; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 4 Dec 2014 12:49:27 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 4 Dec 2014 12:44:15 +0000 Message-Id: References: To: David Scott X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] refactoring Xen drivers X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gMyBEZWMgMjAxNCwgYXQgMjE6MzIsIERhdmUgU2NvdHQgPERhdmUuU2NvdHRAY2l0cml4LmNv bT4gd3JvdGU6Cj4gSeKAmW0gcGxhbm5pbmcgb24gZnVuY3RvcmlzaW5nIHNoYXJlZC1tZW1vcnkt cmluZyBvdmVyIHRoZXNlIHNpZ25hdHVyZXMgc28gd2XigJlsbCBiZSBhYmxlIHRvIHJ1biBuZXRi YWNrL25ldGZyb250IGFuZCBibGtiYWNrL2Jsa2Zyb250IGJldHdlZW4gVW5peCBwcm9jZXNzZXMg KGFuZCB0ZXN0IHRoZW0gbW9yZSB3aGlsZSB3ZeKAmXJlIGF0IGl0KS4gVGhlIOKAmG1pcmFnZeKA mSB0b29sIGNvdWxkIGdlbmVyYXRlIHRoZSBhcHByb3ByaWF0ZSBmdW5jdG9yIGFwcGxpY2F0aW9u IGRlcGVuZGluZyBvbiB0aGUgdGFyZ2V0IHBsYXRmb3JtLgo+IAo+IE9uY2Ugd2XigJl2ZSBzb3J0 ZWQgb3V0IHRoZSBhYmlsaXR5IHRvIGJ1aWxkIEMgc3R1YnMgZm9yIE1pcmFnZS9YZW4sIHRoZW4g d2UgY2FuIG1vdmUgdGhlIEMgc3R1YnMgZnJvbSBtaXJhZ2UtcGxhdGZvcm0gdG8geGVuLXtldnRj aG4sZ250fS54ZW4sIHdoaWNoIHdpbGwgbWFrZSBldmVyeXRoaW5nIGxvb2sgYSBsb3QgbW9yZSBu b3JtYWwuCj4gCj4gTGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmssCj4gRGF2ZQoKRnVsbCBzdXBw b3J0IGZyb20gbWUuICBUaGlzIHdpbGwgaGF2ZSB0aGUgcmVtYXJrYWJsZSBlZmZlY3Qgb2YgbGV0 dGluZyB1cyBiZW5jaG1hcmsgWGVuIGRldmljZSBkcml2ZXIgcGVyZm9ybWFuY2UgKGZyb20gdGhl IHBlcnNwZWN0aXZlIG9mIHJpbmcgdXRpbGlzYXRpb24gYW5kIHNvIGZvcnRoKSBmcm9tIHVzZXJz cGFjZSBpbiBNYWNPUyBYLCBhbmQgZXZlbiBidWlsZCBmcm9udGVuZC9iYWNrZW5kIGRyaXZlcnMg d2l0aG91dCBuZWVkaW5nIFhlbi4KCkF0IGEgcXVpY2sgZ2xhbmNlLCBpdCBzaG91bGQgYWxzbyBi ZSBwb3NzaWJsZSB0byBidWlsZCBhbiBYUEMgbGF5ZXIgZm9yIE1hY09TIFggc2FuZGJveGluZyBm cm9tIHlvdXIgZXZlbnQgc2lnbmF0dXJlcy4uLgoKLWFuaWwKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1p cmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0 Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 13:44:25 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 13:44:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwWhi-0006ES-Hy; Thu, 04 Dec 2014 13:44:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwWhh-0006DC-F0 for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:44:21 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 45/DA-02696-43560845; Thu, 04 Dec 2014 13:44:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1417700659!9662158!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32328 invoked from network); 4 Dec 2014 13:44:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 13:44:19 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 42c902e5; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 4 Dec 2014 13:49:29 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 4 Dec 2014 13:44:16 +0000 Message-Id: <00034F4F-D655-4238-85BA-B1D09EF90CFE@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Xen C stubs / profiling / TLS / status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks for the aggregate list below -- it's very useful. I'm currently merging the OCaml/TLS conduit changes, and will review/merge your patches straight after that goes in. -anil > On 4 Dec 2014, at 12:43, Thomas Leonard wrote: > > I'm currently working on upstreaming the profiling/tracing support for > Mirage, and also on fixing the C compilation problems on Xen/x86 > (needed for TLS on Xen). > > I now have quite a few pull requests open and managing all the various > branches is getting tricky (not least because of the Mirage practice > of keeping OASIS files and changelogs under version control, making > every PR conflict with every other). If someone could merge a few of > them, that would help a lot! (I think I have permission to do it > myself, but that seems rude and having someone else review them is > always useful) > > For example, on mirage-platform, I have: > > https://github.com/mirage/mirage-platform/pull/108 (Use monotonic time > for events) > https://github.com/mirage/mirage-platform/pull/107 (Add some more C > functions for the TLS libraries) > https://github.com/mirage/mirage-platform/pull/105 (Depend on > mirage-profile to add tracing support) > > Merging #108 would not only fix sleep on Xen/x86, but would also unblock > > https://github.com/mirage/mirage-profile/pull/2 (Remove C stubs for > adding timestamp on Xen) > > after which I could merge the mirage-profile mvars thread: > > https://github.com/mirage/mirage-profile/tree/mvars > > which would allow me to make a PR for the tracing work on tcpip. That, > in turn, would be easier to manage if these PRs were merged first: > > https://github.com/mirage/mirage-tcpip/pull/86 (Fixed race waiting for > ARP response) > https://github.com/mirage/mirage-tcpip/pull/85 (Build Xen stubs > separately, with CFLAGS from Mini-OS) > > Merging #85 would, in particular, unblock: > > https://github.com/mirage/mirage/pull/332 (Get Xen linker options from > ocamlfind xen_linkopts variables) > > (which also depends on mirage-profile/pull/2, which is blocked by > mirage-platform#108) > > Thanks! > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 13:44:25 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 13:44:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwWhi-0006ES-Hy; Thu, 04 Dec 2014 13:44:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwWhh-0006DC-F0 for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 13:44:21 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 45/DA-02696-43560845; Thu, 04 Dec 2014 13:44:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1417700659!9662158!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32328 invoked from network); 4 Dec 2014 13:44:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 13:44:19 -0000 Received: from [192.168.14.141] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 42c902e5; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 4 Dec 2014 13:49:29 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 4 Dec 2014 13:44:16 +0000 Message-Id: <00034F4F-D655-4238-85BA-B1D09EF90CFE@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Xen C stubs / profiling / TLS / status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks for the aggregate list below -- it's very useful. I'm currently merging the OCaml/TLS conduit changes, and will review/merge your patches straight after that goes in. -anil > On 4 Dec 2014, at 12:43, Thomas Leonard wrote: > > I'm currently working on upstreaming the profiling/tracing support for > Mirage, and also on fixing the C compilation problems on Xen/x86 > (needed for TLS on Xen). > > I now have quite a few pull requests open and managing all the various > branches is getting tricky (not least because of the Mirage practice > of keeping OASIS files and changelogs under version control, making > every PR conflict with every other). If someone could merge a few of > them, that would help a lot! (I think I have permission to do it > myself, but that seems rude and having someone else review them is > always useful) > > For example, on mirage-platform, I have: > > https://github.com/mirage/mirage-platform/pull/108 (Use monotonic time > for events) > https://github.com/mirage/mirage-platform/pull/107 (Add some more C > functions for the TLS libraries) > https://github.com/mirage/mirage-platform/pull/105 (Depend on > mirage-profile to add tracing support) > > Merging #108 would not only fix sleep on Xen/x86, but would also unblock > > https://github.com/mirage/mirage-profile/pull/2 (Remove C stubs for > adding timestamp on Xen) > > after which I could merge the mirage-profile mvars thread: > > https://github.com/mirage/mirage-profile/tree/mvars > > which would allow me to make a PR for the tracing work on tcpip. That, > in turn, would be easier to manage if these PRs were merged first: > > https://github.com/mirage/mirage-tcpip/pull/86 (Fixed race waiting for > ARP response) > https://github.com/mirage/mirage-tcpip/pull/85 (Build Xen stubs > separately, with CFLAGS from Mini-OS) > > Merging #85 would, in particular, unblock: > > https://github.com/mirage/mirage/pull/332 (Get Xen linker options from > ocamlfind xen_linkopts variables) > > (which also depends on mirage-profile/pull/2, which is blocked by > mirage-platform#108) > > Thanks! > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 14:36:36 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 14:36:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXWE-0000uu-TC; Thu, 04 Dec 2014 14:36:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXWD-0000uk-Kq for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:36:33 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 9B/D1-20609-17170845; Thu, 04 Dec 2014 14:36:33 +0000 X-Env-Sender: martin@lucina.net X-Msg-Ref: server-14.tower-27.messagelabs.com!1417703792!13015472!1 X-Originating-IP: [62.176.169.44] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16906 invoked from network); 4 Dec 2014 14:36:32 -0000 Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 14:36:32 -0000 Received: from dezo.moloch.sk (unknown [92.240.231.146]) by mail.moloch.sk (Postfix) with ESMTPSA id C798F18050C7; Thu, 4 Dec 2014 15:36:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201309; t=1417703791; bh=eRR43ZwsxE6v7qhSXYOPmhBLEXHFIOiB15JnAr6qq7Q=; h=Date:From:To:Cc:Subject:From; b=tiyTc+yWlEhfP2Ej4mX7DaoE2TIBbHEp3EmX+tLkZJv+JCotI7EJ5Dn7FGISDukim 8e9JBfxvoaTWNyGsFjM6vBRIUqta71GhItQtXDBUNqzFd0Skt+6m1zK+FYTQ9xPZ3g MyRwfoTl1NbJlhHNES3vg+Zyh2vA7Rb6Ta8ad1jL9R0JVa0soSfy4cEh1ZHo/YCU1y khKalHbs4FLhaDtirY0/up0YqrMfs+Op8B0pPqnrnrsuCHGP8TDOj40gkOOWQRdi5c Oe8lemIINaU6a8q/BEKz7pagzs1HLvE2I6vPYh/48UcPI2u7h16Ey2fN7hCViX6gcc 7itag+Az+k5Zg== Received: by dezo.moloch.sk (Postfix, from userid 1000) id 82415D05952E; Thu, 4 Dec 2014 15:36:31 +0100 (CET) Date: Thu, 4 Dec 2014 15:36:31 +0100 From: Martin Lucina To: Anil Madhavapeddy Message-ID: <20141204143631.GE11192@dezo.moloch.sk> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Anil, in your talk at operatingsystems.io last week (great talk, thanks!), you mentioned that you have Unikernels "booting in the time between SYN and ACK" [1]. I'm curious; is this the "raw" boot time (first instruction to serving requests) or a "full stack on Xen" boot time (domain creation to serving requests)? If it is the latter I presume you are using a custom Xen toolstack to create the domain? My measurements with rump kernels show that the "xl" toolstack is quite slow, depending on the exact Xen setup taking between 1 to 2.5 seconds to create a domain with a vif and a couple of disk devices. Following discussion with Ian Jackson, this (xl) should be be fairly easy to optimize, has/is anyone from Mirage OS looking at this? Martin [1] http://decks.openmirage.org/osio2014#/4/4 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 14:36:36 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 14:36:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXWE-0000uu-TC; Thu, 04 Dec 2014 14:36:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXWD-0000uk-Kq for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:36:33 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 9B/D1-20609-17170845; Thu, 04 Dec 2014 14:36:33 +0000 X-Env-Sender: martin@lucina.net X-Msg-Ref: server-14.tower-27.messagelabs.com!1417703792!13015472!1 X-Originating-IP: [62.176.169.44] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16906 invoked from network); 4 Dec 2014 14:36:32 -0000 Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Dec 2014 14:36:32 -0000 Received: from dezo.moloch.sk (unknown [92.240.231.146]) by mail.moloch.sk (Postfix) with ESMTPSA id C798F18050C7; Thu, 4 Dec 2014 15:36:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201309; t=1417703791; bh=eRR43ZwsxE6v7qhSXYOPmhBLEXHFIOiB15JnAr6qq7Q=; h=Date:From:To:Cc:Subject:From; b=tiyTc+yWlEhfP2Ej4mX7DaoE2TIBbHEp3EmX+tLkZJv+JCotI7EJ5Dn7FGISDukim 8e9JBfxvoaTWNyGsFjM6vBRIUqta71GhItQtXDBUNqzFd0Skt+6m1zK+FYTQ9xPZ3g MyRwfoTl1NbJlhHNES3vg+Zyh2vA7Rb6Ta8ad1jL9R0JVa0soSfy4cEh1ZHo/YCU1y khKalHbs4FLhaDtirY0/up0YqrMfs+Op8B0pPqnrnrsuCHGP8TDOj40gkOOWQRdi5c Oe8lemIINaU6a8q/BEKz7pagzs1HLvE2I6vPYh/48UcPI2u7h16Ey2fN7hCViX6gcc 7itag+Az+k5Zg== Received: by dezo.moloch.sk (Postfix, from userid 1000) id 82415D05952E; Thu, 4 Dec 2014 15:36:31 +0100 (CET) Date: Thu, 4 Dec 2014 15:36:31 +0100 From: Martin Lucina To: Anil Madhavapeddy Message-ID: <20141204143631.GE11192@dezo.moloch.sk> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Anil, in your talk at operatingsystems.io last week (great talk, thanks!), you mentioned that you have Unikernels "booting in the time between SYN and ACK" [1]. I'm curious; is this the "raw" boot time (first instruction to serving requests) or a "full stack on Xen" boot time (domain creation to serving requests)? If it is the latter I presume you are using a custom Xen toolstack to create the domain? My measurements with rump kernels show that the "xl" toolstack is quite slow, depending on the exact Xen setup taking between 1 to 2.5 seconds to create a domain with a vif and a couple of disk devices. Following discussion with Ian Jackson, this (xl) should be be fairly easy to optimize, has/is anyone from Mirage OS looking at this? Martin [1] http://decks.openmirage.org/osio2014#/4/4 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 14:41:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 14:41:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXb3-0001B1-AG; Thu, 04 Dec 2014 14:41:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXb2-0001Am-6s for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:41:32 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id CB/AA-02702-B9270845; Thu, 04 Dec 2014 14:41:31 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1417704090!13030248!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15084 invoked from network); 4 Dec 2014 14:41:30 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 14:41:30 -0000 Received: by mail-wg0-f54.google.com with SMTP id l2so22782938wgh.13 for ; Thu, 04 Dec 2014 06:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=N3YSG6CmZo19e7wdzW5VRPWjjPSdzVkIty+PAeq97lc=; b=wMW78j/Yi0HgihZ/5y2WKL9at4YRLSl8+Ix7yKkdX1yKWI4SMSfmoBEJ/H3S+C28f6 h2XJ6IzWocoi1APQPXTQDeGOV4RNpsrqrGV26hI7QLPIZCDGnMsfN2GhH9rsbyn2wdbc X8Jon59IqA+VZqHqk0ndKXfF6qhbzACvKDNw821LrYNN/WZU87OAFq/MHCPfUGtKz2aw Ah+WYj/sgVu9LNCRiwTMAIYca/4dv91D4hyJNn11fPi1YcsoKsVvDWIbpVSxMV4DyYyI CjDmcPGsKzQ+8fbedDxIhibcgq45uldwfN152iCSRH+p3UvFs00giL/WfyM2tPsMH6x1 Ejqw== MIME-Version: 1.0 X-Received: by 10.194.156.138 with SMTP id we10mr17017368wjb.72.1417704090344; Thu, 04 Dec 2014 06:41:30 -0800 (PST) Received: by 10.27.171.146 with HTTP; Thu, 4 Dec 2014 06:41:30 -0800 (PST) In-Reply-To: <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> Date: Thu, 4 Dec 2014 14:41:30 +0000 X-Google-Sender-Auth: RX6An_pUVg1xWrJ4xYkCC1h5GBs Message-ID: From: Nicolas Ojeda Bar To: Anil Madhavapeddy , Richard Mortier Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgbGlzdCwKClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIHNvIGZhci4gIEZvciBncmVhdGVyIGNs YXJpdHkgYW5kIHByZWNpc2lvbiwgSSB3cm90ZSBhCnNob3J0IGRvY3VtZW50IGV4cGxhaW5pbmcg dGhlIHJhdGlvbmFsZSBhbmQgdGhlIGRlc2lnbiBvZiB0aGUgcHJvcG9zZWQKY2hhbmdlcyB0byB0 aGUKYG1pcmFnZSBjb25maWd1cmVgIHRvb2wuCgpodHRwczovL2dpc3QuZ2l0aHViLmNvbS9ub2pi L2Y5YzI2MmQ1ZmQ2OTFlNjE3MWNhCgpBbnkgY29tbWVudHMgYXBwcmVjaWF0ZWQhCgpCZXN0IHdp c2hlcywKTmljb2xhcwoKCk9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgNDo1OCBQTSwgQW5pbCBNYWRo YXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4gT24gMiBEZWMgMjAxNCwgYXQgMTY6 NTIsIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmlsQHJlY29pbC5vcmc+IHdyb3RlOgo+Pj4gT24gMSBE ZWMgMjAxNCwgYXQgMTQ6MzEsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBlcnJhdGlx dWUuY2g+IHdyb3RlOgo+Pj4gTGUgbHVuZGksIDEgZMOpY2VtYnJlIDIwMTQgw6AgMTU6MDUsIFRo b21hcyBHYXphZ25haXJlIGEgw6ljcml0IDoKPj4+Cj4+Pj4+IE9uZSBjYW4gb2YgY291cnNlLCBt YWtlIHRoZSBuYW1lcyB1bmlxdWUgYnkgY29tYmluaW5nIHRoZSBuYW1lIG9mIHRoZQo+Pj4+PiBw YXJhbWV0ZXIgd2l0aCB0aGUgbmFtZSBvZiB0aGUgQ09ORklHVVJBQkxFIChjdXJyZW50bHkKPj4+ Pj4gc2VtaS1hbGdvcml0aG1pY2FsbHkgZ2VuZXJhdGVkIHRvIGtlZXAgdGhlbSB1bmlxdWUpLCBi dXQgdGhpcyBkb2VzIG5vdAo+Pj4+PiBzZWVtIHZlcnkgdXNlciBmcmllbmRseS4KPj4+Pgo+Pj4+ IE1heWJlIGV4cG9zZSBhID9uYW1lIHBhcmFtYXRlciB0byBhbGwgdGhlIGNvbWJpbmF0b3JzIHdo aWNoIHdpbGwgYmUgcHJlZml4ZWQgdG8gcGFyYW1ldGVyIGFyZ3VtZW50cyBpZiBuZWVkZWQuCj4+ Pgo+Pj4gSSdtIG5vdCBzdXJlIHRoYXQncyB0aGUgcHJvYmxlbS4gSWYgSSB1bmRlcnN0b29kIHdl bGwgaXQgc2VlbXMgdGhhdCBmdW5jdG9yIGFwcGxpY2F0aW9uIGRvZXMgZ2VuZXJhdGUgbmV3IGNv bmZpZ3VyYXRpb24gdmFsdWVzLgo+Pj4KPj4+IE9mIGNvdXJzZSBpZiB0aGV5IGFyZSBtZWFudCB0 byBiZSBzaGFyZWQgYW1vbmcgaW5zdGFuY2VzIGl0IG1lYW5zIHRoYXQgeW91IGFyZSBkZWNsYXJp bmcgdGhlbSBhdCB0aGUgd3JvbmcgcGxhY2UuIEJlc3Qgd291bGQgYmUgdG8gZGVmaW5lIGEgbW9k dWxlIHdpdGggInN0YW5kYXJkIiBjb25maWd1cmF0aW9uIGtleXMgKGUuZy4gaXAgYWRkcmVzcykg dG8gYmUgdXNlZCB0byBiZSB1c2VkIHRocm91Z2hvdXQgdGhlIHN5c3RlbSBhbmQgdGVsbGluZyB1 c2VycyB0byBmaXJzdCB0cnkgdG8gdXNlIHRoZSBzdGFuZGFyZCBjb25maWd1cmF0aW9uIGtleXMg YmVmb3JlIHRyeWluZyB0byBkZWZpbmUgbmV3IG9uZXMuCj4+Cj4+IE9uZSBwcm9ibGVtIGN1cnJl bnRseSBpcyB0aGF0IHdoaWxlIGZ1bmN0b3IgYXBwbGljYXRpb24gZ2VuZXJhdGVzIG5ldyBjb25m aWd1cmF0aW9uIHZhbHVlcywgdGhlIGFjdHVhbCBpbnN0YW50aWF0aW9ucyBvZiBkZXZpY2VzIG1h eSByZXVzZSB0aGUgZnVuY3RvciBhcHBsaWNhdGlvbiB3aXRoIGRpZmZlcmVudCBzdGF0ZSB2YXJp YWJsZXMuCj4+Cj4+IEZvciBpbnN0YW5jZSwgcmlnaHQgbm93IGlmIHdlIGdlbmVyYXRlIGEgSFRU UCBjbGllbnQsIHdlIG5lZWQgdGhpcyBpbiBvdXIgY29uZmlnLm1sOgo+Pgo+PiBsZXQgc3Y0ID0g c3RhY2sgZGVmYXVsdF9jb25zb2xlIGluCj4+IGxldCByZXNfZG5zID0gcmVzb2x2ZXJfZG5zIHN2 NCBpbgo+PiBsZXQgY29uZHVpdCA9IGNvbmR1aXRfZGlyZWN0IHN2NCBpbgo+Pgo+PiBUaGUgc3Rh Y2sgKHN2NCkgaXMgaW5zdGFudGlhdGVkIGFzIG9uZSBmdW5jdG9yLCBidXQgaXMgY3VycmVudGx5 IGNvbm5lY3QoKSdlZCB0d2ljZS4gIFRoZSBvYnNlcnZhYmxlIGJ1ZyBpcyB0aGF0IGl0IGlzc3Vl cyBhIERIQ1AgcXVlcnkgZm9yIGV2ZXJ5IHRpbWUgaXQgaXMgY2FsbGVkLgo+Pgo+PiBGaWxsaW5n IHRoaXMgYXQgZmlyc3QgZ2xhbmNlIHJlcXVpcmVzIGluc3RhbnRpYXRpb25zIHRvIGJlIGxhenks IHNvIHRoYXQgd2UgcmV1c2UgdGhlbS4gIEhvd2V2ZXIsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8g ZXhwbGljaXRseSBuYW1lIGRldmljZXMgc28gdGhhdCB3ZSBjYW4gc2FmZWx5IG1lbW9pc2UgbXVs dGlwbGUgc3RhY2tzIHRoYXQgc2hhcmUgdGhlIHNhbWUgZnVuY3RvciBidXQgb3RoZXJ3aXNlIGRp ZmZlciBpbiB0aGVpciBzdGF0ZSAoZS5nLiB0d28gY29tcGxldGVseSBzZXBhcmF0ZSBzdGFja3Mg dGhhdCBpc3N1ZSB0aGVpciBvd24gREhDUCByZXF1ZXN0cyB3aXRoIHRoZWlyIG93biBNQUMgYWRk cmVzc2VzLCBidXQgb3RoZXJ3aXNlIHNoYXJlIHRoZSBzYW1lIE9DYW1sIFRDUC9JUCBmdW5jdG9y cykuCj4+Cj4+IChzZWUgaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvaXNzdWVzLzMz MSBmb3IgbW9yZSkKPgo+IEFuIGFkZGVuZHVtIHRvIHRoaXMgaXMgdGhhdCB3ZSBkb24ndCB3YW50 IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1c2UgbGF6eSBhbmQgc2hhcmVkIGJ5IGRlZmF1 bHQuCj4KPiBJbiB0aGUgZXhhbXBsZSBhYm92ZSwgaXQgaXMgcGVyZmVjdGx5IHNlbnNpYmxlIHRv IHdhbnQgdG8gaGF2ZSBvbmUgSVAgc3RhY2sgZm9yIHRoZSBwdXJwb3NlcyBvZiBETlMgcmVzb2x1 dGlvbiBvbmx5LCBhbmQgYW5vdGhlciBmb3IgdGhlIHB1cnBvc2VzIG9mIG9wZW5pbmcgbmV0d29y ayBjb25uZWN0aW9ucyBmb3IgZGF0YSB0cmFuc2Zlci4gIFRoYXQncyBkaWZmaWN1bHQgdG8gc2V0 dXAgb24gbW9zdCBzeXN0ZW1zIHRvZGF5LCBidXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc2Vt YmxlIHdpdGggTWlyYWdlLgo+Cj4gLWFuaWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1k ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dp LWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 14:41:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 14:41:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXb3-0001B1-AG; Thu, 04 Dec 2014 14:41:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXb2-0001Am-6s for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 14:41:32 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id CB/AA-02702-B9270845; Thu, 04 Dec 2014 14:41:31 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1417704090!13030248!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15084 invoked from network); 4 Dec 2014 14:41:30 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 14:41:30 -0000 Received: by mail-wg0-f54.google.com with SMTP id l2so22782938wgh.13 for ; Thu, 04 Dec 2014 06:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=N3YSG6CmZo19e7wdzW5VRPWjjPSdzVkIty+PAeq97lc=; b=wMW78j/Yi0HgihZ/5y2WKL9at4YRLSl8+Ix7yKkdX1yKWI4SMSfmoBEJ/H3S+C28f6 h2XJ6IzWocoi1APQPXTQDeGOV4RNpsrqrGV26hI7QLPIZCDGnMsfN2GhH9rsbyn2wdbc X8Jon59IqA+VZqHqk0ndKXfF6qhbzACvKDNw821LrYNN/WZU87OAFq/MHCPfUGtKz2aw Ah+WYj/sgVu9LNCRiwTMAIYca/4dv91D4hyJNn11fPi1YcsoKsVvDWIbpVSxMV4DyYyI CjDmcPGsKzQ+8fbedDxIhibcgq45uldwfN152iCSRH+p3UvFs00giL/WfyM2tPsMH6x1 Ejqw== MIME-Version: 1.0 X-Received: by 10.194.156.138 with SMTP id we10mr17017368wjb.72.1417704090344; Thu, 04 Dec 2014 06:41:30 -0800 (PST) Received: by 10.27.171.146 with HTTP; Thu, 4 Dec 2014 06:41:30 -0800 (PST) In-Reply-To: <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> Date: Thu, 4 Dec 2014 14:41:30 +0000 X-Google-Sender-Auth: RX6An_pUVg1xWrJ4xYkCC1h5GBs Message-ID: From: Nicolas Ojeda Bar To: Anil Madhavapeddy , Richard Mortier Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgbGlzdCwKClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIHNvIGZhci4gIEZvciBncmVhdGVyIGNs YXJpdHkgYW5kIHByZWNpc2lvbiwgSSB3cm90ZSBhCnNob3J0IGRvY3VtZW50IGV4cGxhaW5pbmcg dGhlIHJhdGlvbmFsZSBhbmQgdGhlIGRlc2lnbiBvZiB0aGUgcHJvcG9zZWQKY2hhbmdlcyB0byB0 aGUKYG1pcmFnZSBjb25maWd1cmVgIHRvb2wuCgpodHRwczovL2dpc3QuZ2l0aHViLmNvbS9ub2pi L2Y5YzI2MmQ1ZmQ2OTFlNjE3MWNhCgpBbnkgY29tbWVudHMgYXBwcmVjaWF0ZWQhCgpCZXN0IHdp c2hlcywKTmljb2xhcwoKCk9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgNDo1OCBQTSwgQW5pbCBNYWRo YXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4gT24gMiBEZWMgMjAxNCwgYXQgMTY6 NTIsIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmlsQHJlY29pbC5vcmc+IHdyb3RlOgo+Pj4gT24gMSBE ZWMgMjAxNCwgYXQgMTQ6MzEsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBlcnJhdGlx dWUuY2g+IHdyb3RlOgo+Pj4gTGUgbHVuZGksIDEgZMOpY2VtYnJlIDIwMTQgw6AgMTU6MDUsIFRo b21hcyBHYXphZ25haXJlIGEgw6ljcml0IDoKPj4+Cj4+Pj4+IE9uZSBjYW4gb2YgY291cnNlLCBt YWtlIHRoZSBuYW1lcyB1bmlxdWUgYnkgY29tYmluaW5nIHRoZSBuYW1lIG9mIHRoZQo+Pj4+PiBw YXJhbWV0ZXIgd2l0aCB0aGUgbmFtZSBvZiB0aGUgQ09ORklHVVJBQkxFIChjdXJyZW50bHkKPj4+ Pj4gc2VtaS1hbGdvcml0aG1pY2FsbHkgZ2VuZXJhdGVkIHRvIGtlZXAgdGhlbSB1bmlxdWUpLCBi dXQgdGhpcyBkb2VzIG5vdAo+Pj4+PiBzZWVtIHZlcnkgdXNlciBmcmllbmRseS4KPj4+Pgo+Pj4+ IE1heWJlIGV4cG9zZSBhID9uYW1lIHBhcmFtYXRlciB0byBhbGwgdGhlIGNvbWJpbmF0b3JzIHdo aWNoIHdpbGwgYmUgcHJlZml4ZWQgdG8gcGFyYW1ldGVyIGFyZ3VtZW50cyBpZiBuZWVkZWQuCj4+ Pgo+Pj4gSSdtIG5vdCBzdXJlIHRoYXQncyB0aGUgcHJvYmxlbS4gSWYgSSB1bmRlcnN0b29kIHdl bGwgaXQgc2VlbXMgdGhhdCBmdW5jdG9yIGFwcGxpY2F0aW9uIGRvZXMgZ2VuZXJhdGUgbmV3IGNv bmZpZ3VyYXRpb24gdmFsdWVzLgo+Pj4KPj4+IE9mIGNvdXJzZSBpZiB0aGV5IGFyZSBtZWFudCB0 byBiZSBzaGFyZWQgYW1vbmcgaW5zdGFuY2VzIGl0IG1lYW5zIHRoYXQgeW91IGFyZSBkZWNsYXJp bmcgdGhlbSBhdCB0aGUgd3JvbmcgcGxhY2UuIEJlc3Qgd291bGQgYmUgdG8gZGVmaW5lIGEgbW9k dWxlIHdpdGggInN0YW5kYXJkIiBjb25maWd1cmF0aW9uIGtleXMgKGUuZy4gaXAgYWRkcmVzcykg dG8gYmUgdXNlZCB0byBiZSB1c2VkIHRocm91Z2hvdXQgdGhlIHN5c3RlbSBhbmQgdGVsbGluZyB1 c2VycyB0byBmaXJzdCB0cnkgdG8gdXNlIHRoZSBzdGFuZGFyZCBjb25maWd1cmF0aW9uIGtleXMg YmVmb3JlIHRyeWluZyB0byBkZWZpbmUgbmV3IG9uZXMuCj4+Cj4+IE9uZSBwcm9ibGVtIGN1cnJl bnRseSBpcyB0aGF0IHdoaWxlIGZ1bmN0b3IgYXBwbGljYXRpb24gZ2VuZXJhdGVzIG5ldyBjb25m aWd1cmF0aW9uIHZhbHVlcywgdGhlIGFjdHVhbCBpbnN0YW50aWF0aW9ucyBvZiBkZXZpY2VzIG1h eSByZXVzZSB0aGUgZnVuY3RvciBhcHBsaWNhdGlvbiB3aXRoIGRpZmZlcmVudCBzdGF0ZSB2YXJp YWJsZXMuCj4+Cj4+IEZvciBpbnN0YW5jZSwgcmlnaHQgbm93IGlmIHdlIGdlbmVyYXRlIGEgSFRU UCBjbGllbnQsIHdlIG5lZWQgdGhpcyBpbiBvdXIgY29uZmlnLm1sOgo+Pgo+PiBsZXQgc3Y0ID0g c3RhY2sgZGVmYXVsdF9jb25zb2xlIGluCj4+IGxldCByZXNfZG5zID0gcmVzb2x2ZXJfZG5zIHN2 NCBpbgo+PiBsZXQgY29uZHVpdCA9IGNvbmR1aXRfZGlyZWN0IHN2NCBpbgo+Pgo+PiBUaGUgc3Rh Y2sgKHN2NCkgaXMgaW5zdGFudGlhdGVkIGFzIG9uZSBmdW5jdG9yLCBidXQgaXMgY3VycmVudGx5 IGNvbm5lY3QoKSdlZCB0d2ljZS4gIFRoZSBvYnNlcnZhYmxlIGJ1ZyBpcyB0aGF0IGl0IGlzc3Vl cyBhIERIQ1AgcXVlcnkgZm9yIGV2ZXJ5IHRpbWUgaXQgaXMgY2FsbGVkLgo+Pgo+PiBGaWxsaW5n IHRoaXMgYXQgZmlyc3QgZ2xhbmNlIHJlcXVpcmVzIGluc3RhbnRpYXRpb25zIHRvIGJlIGxhenks IHNvIHRoYXQgd2UgcmV1c2UgdGhlbS4gIEhvd2V2ZXIsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8g ZXhwbGljaXRseSBuYW1lIGRldmljZXMgc28gdGhhdCB3ZSBjYW4gc2FmZWx5IG1lbW9pc2UgbXVs dGlwbGUgc3RhY2tzIHRoYXQgc2hhcmUgdGhlIHNhbWUgZnVuY3RvciBidXQgb3RoZXJ3aXNlIGRp ZmZlciBpbiB0aGVpciBzdGF0ZSAoZS5nLiB0d28gY29tcGxldGVseSBzZXBhcmF0ZSBzdGFja3Mg dGhhdCBpc3N1ZSB0aGVpciBvd24gREhDUCByZXF1ZXN0cyB3aXRoIHRoZWlyIG93biBNQUMgYWRk cmVzc2VzLCBidXQgb3RoZXJ3aXNlIHNoYXJlIHRoZSBzYW1lIE9DYW1sIFRDUC9JUCBmdW5jdG9y cykuCj4+Cj4+IChzZWUgaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvaXNzdWVzLzMz MSBmb3IgbW9yZSkKPgo+IEFuIGFkZGVuZHVtIHRvIHRoaXMgaXMgdGhhdCB3ZSBkb24ndCB3YW50 IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1c2UgbGF6eSBhbmQgc2hhcmVkIGJ5IGRlZmF1 bHQuCj4KPiBJbiB0aGUgZXhhbXBsZSBhYm92ZSwgaXQgaXMgcGVyZmVjdGx5IHNlbnNpYmxlIHRv IHdhbnQgdG8gaGF2ZSBvbmUgSVAgc3RhY2sgZm9yIHRoZSBwdXJwb3NlcyBvZiBETlMgcmVzb2x1 dGlvbiBvbmx5LCBhbmQgYW5vdGhlciBmb3IgdGhlIHB1cnBvc2VzIG9mIG9wZW5pbmcgbmV0d29y ayBjb25uZWN0aW9ucyBmb3IgZGF0YSB0cmFuc2Zlci4gIFRoYXQncyBkaWZmaWN1bHQgdG8gc2V0 dXAgb24gbW9zdCBzeXN0ZW1zIHRvZGF5LCBidXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc2Vt YmxlIHdpdGggTWlyYWdlLgo+Cj4gLWFuaWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1k ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dp LWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 15:02:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 15:02:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXvb-0002QC-DS; Thu, 04 Dec 2014 15:02:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXvZ-0002Q7-TN for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:02:46 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id BE/83-22819-59770845; Thu, 04 Dec 2014 15:02:45 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1417705364!11562439!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17886 invoked from network); 4 Dec 2014 15:02:44 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 15:02:44 -0000 Received: by mail-wi0-f173.google.com with SMTP id r20so35028757wiv.12 for ; Thu, 04 Dec 2014 07:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPe7YkJaKmSq1Z4nHYuqdaCv0JUj16DPhiT1RgMr3iw=; b=Ydn2Ljbf0mqnIOC8CMsChVL21UQ+tr32ZIGeHmRxKcMg0opFiJhQQqeNVWGkACuYtX jlrRRXn4mw3np2ibVL10LRw/HDL21zugCnJLrdr7WVJgYFhUjBrxIi89S6Z7Sv3qMOpk p0G2Rd3ly3dfia8CopuShzgnCCFX6ZouRb4ifVjYuGXqjDg1QUFpHbLExe3mOX0yDcM/ VqYu/FlxoITl8KgQDFCPEPYGXdxDckYU1H6O1ho/qVwMBkuYi1lqiRHB3Wrf+gB6nkhr I6C+BUv2nvVt9qoDrWeOYY3yQuNChPZ51dmyCDhjEQWLlhW3dB+71coCfsiQOXm2e6fC Obwg== X-Received: by 10.180.20.106 with SMTP id m10mr63518126wie.1.1417705363940; Thu, 04 Dec 2014 07:02:43 -0800 (PST) Received: from piana.mac.cl.cam.ac.uk (piana.mac.cl.cam.ac.uk. [128.232.56.38]) by mx.google.com with ESMTPSA id vm8sm40842966wjc.6.2014.12.04.07.02.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:02:43 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Thu, 4 Dec 2014 15:02:41 +0000 Message-Id: <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhbmtzLCB2ZXJ5IG5pY2UgcmVhZC4KCkZldyBxdWVzdGlvbnMgdGhvdWdoOgotIEkgZ3Vlc3Mg dGhlIG1haW4gZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBQYXJhbXMudCBhbmQgQ21kbGluZXIuVGVy bS50IGlzIHRoYXQgdGhlIHBhcmFtcyBhcmUgbW9yZSAibWV0YSI6IHRoZXkgbm93IGhvdyB0byBw cmludCBPQ2FtbCB2YWx1ZXMgYW5kIGZ1bmN0aW9ucyBwYXJzaW5nIE9DYW1sIHZhbHVlcyBvZiB0 aGF0IHR5cGUgKGllLiB0aGF0J3MgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9mIE1pcmFnZSBtdWx0 aS1zdGFnZSBjb21waWxhdGlvbiwgYnV0IG1heWJlIG5vdCBzbyB1c2VmdWwgaW4gYSBtb3JlIGdl bmVyaWMgY2FzZSkKLSBJcyB0aGF0IHBvc3NpYmxlIHRvIGJ1aWxkIGN1c3RvbSAnYSBjb252ZXJ0 ZXI/IE1pc3NpbmcgYW4gKGBhIG9wdGlvbiBjb252ZXJ0ZXIpIGFuZCAoaW50ezMyLDY0fSBjb252 ZXJ0ZXIpLCBldGMuLi4KCkkgYW0gbm90IHZlcnkgZm9uZCBvZiB0aGUgZGVmYXVsdCByZWZlcmVu Y2VzLCBub3Qgc3VyZSB3aHkgeW91IHdhbnQgc29tZW9uZSB0byBjaGFuZ2UgdGhlbSBnbG9iYWxs eS4KCkFsc28sIGhvdyBkb2VzIGl0IHdvcmsgd2hlbiB5b3Ugd2FudCB0byBkZWZpbmUgeW91ciBj dXN0b20gcGFyYW1ldGVycyBpbiBjb25maWcubWw/IEkgdGhpbmsgdGhhdCB3YXMgTWFnbnVzIHdh bnRlZCB0byBnZXQgaGlzIHJ1bnRpbWUgZXh0cmEgdmFsdWUuCgpUaG9tYXMKCj4gT24gNCBEZWMg MjAxNCwgYXQgMTQ6NDEsIE5pY29sYXMgT2plZGEgQmFyIDxubzI2M0BkcG1tcy5jYW0uYWMudWs+ IHdyb3RlOgo+IAo+IEhpIGxpc3QsCj4gCj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMgc28gZmFy LiAgRm9yIGdyZWF0ZXIgY2xhcml0eSBhbmQgcHJlY2lzaW9uLCBJIHdyb3RlIGEKPiBzaG9ydCBk b2N1bWVudCBleHBsYWluaW5nIHRoZSByYXRpb25hbGUgYW5kIHRoZSBkZXNpZ24gb2YgdGhlIHBy b3Bvc2VkCj4gY2hhbmdlcyB0byB0aGUKPiBgbWlyYWdlIGNvbmZpZ3VyZWAgdG9vbC4KPiAKPiBo dHRwczovL2dpc3QuZ2l0aHViLmNvbS9ub2piL2Y5YzI2MmQ1ZmQ2OTFlNjE3MWNhCj4gCj4gQW55 IGNvbW1lbnRzIGFwcHJlY2lhdGVkIQo+IAo+IEJlc3Qgd2lzaGVzLAo+IE5pY29sYXMKPiAKPiAK PiBPbiBUdWUsIERlYyAyLCAyMDE0IGF0IDQ6NTggUE0sIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmls QHJlY29pbC5vcmc+IHdyb3RlOgo+PiBPbiAyIERlYyAyMDE0LCBhdCAxNjo1MiwgQW5pbCBNYWRo YXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+Pj4gT24gMSBEZWMgMjAxNCwgYXQg MTQ6MzEsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBlcnJhdGlxdWUuY2g+IHdyb3Rl Ogo+Pj4+IExlIGx1bmRpLCAxIGTDqWNlbWJyZSAyMDE0IMOgIDE1OjA1LCBUaG9tYXMgR2F6YWdu YWlyZSBhIMOpY3JpdCA6Cj4+Pj4gCj4+Pj4+PiBPbmUgY2FuIG9mIGNvdXJzZSwgbWFrZSB0aGUg bmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0aGUgbmFtZSBvZiB0aGUKPj4+Pj4+IHBhcmFtZXRl ciB3aXRoIHRoZSBuYW1lIG9mIHRoZSBDT05GSUdVUkFCTEUgKGN1cnJlbnRseQo+Pj4+Pj4gc2Vt aS1hbGdvcml0aG1pY2FsbHkgZ2VuZXJhdGVkIHRvIGtlZXAgdGhlbSB1bmlxdWUpLCBidXQgdGhp cyBkb2VzIG5vdAo+Pj4+Pj4gc2VlbSB2ZXJ5IHVzZXIgZnJpZW5kbHkuCj4+Pj4+IAo+Pj4+PiBN YXliZSBleHBvc2UgYSA/bmFtZSBwYXJhbWF0ZXIgdG8gYWxsIHRoZSBjb21iaW5hdG9ycyB3aGlj aCB3aWxsIGJlIHByZWZpeGVkIHRvIHBhcmFtZXRlciBhcmd1bWVudHMgaWYgbmVlZGVkLgo+Pj4+ IAo+Pj4+IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0uIElmIEkgdW5kZXJzdG9vZCB3 ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBkb2VzIGdlbmVyYXRlIG5ldyBj b25maWd1cmF0aW9uIHZhbHVlcy4KPj4+PiAKPj4+PiBPZiBjb3Vyc2UgaWYgdGhleSBhcmUgbWVh bnQgdG8gYmUgc2hhcmVkIGFtb25nIGluc3RhbmNlcyBpdCBtZWFucyB0aGF0IHlvdSBhcmUgZGVj bGFyaW5nIHRoZW0gYXQgdGhlIHdyb25nIHBsYWNlLiBCZXN0IHdvdWxkIGJlIHRvIGRlZmluZSBh IG1vZHVsZSB3aXRoICJzdGFuZGFyZCIgY29uZmlndXJhdGlvbiBrZXlzIChlLmcuIGlwIGFkZHJl c3MpIHRvIGJlIHVzZWQgdG8gYmUgdXNlZCB0aHJvdWdob3V0IHRoZSBzeXN0ZW0gYW5kIHRlbGxp bmcgdXNlcnMgdG8gZmlyc3QgdHJ5IHRvIHVzZSB0aGUgc3RhbmRhcmQgY29uZmlndXJhdGlvbiBr ZXlzIGJlZm9yZSB0cnlpbmcgdG8gZGVmaW5lIG5ldyBvbmVzLgo+Pj4gCj4+PiBPbmUgcHJvYmxl bSBjdXJyZW50bHkgaXMgdGhhdCB3aGlsZSBmdW5jdG9yIGFwcGxpY2F0aW9uIGdlbmVyYXRlcyBu ZXcgY29uZmlndXJhdGlvbiB2YWx1ZXMsIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbnMgb2YgZGV2 aWNlcyBtYXkgcmV1c2UgdGhlIGZ1bmN0b3IgYXBwbGljYXRpb24gd2l0aCBkaWZmZXJlbnQgc3Rh dGUgdmFyaWFibGVzLgo+Pj4gCj4+PiBGb3IgaW5zdGFuY2UsIHJpZ2h0IG5vdyBpZiB3ZSBnZW5l cmF0ZSBhIEhUVFAgY2xpZW50LCB3ZSBuZWVkIHRoaXMgaW4gb3VyIGNvbmZpZy5tbDoKPj4+IAo+ Pj4gbGV0IHN2NCA9IHN0YWNrIGRlZmF1bHRfY29uc29sZSBpbgo+Pj4gbGV0IHJlc19kbnMgPSBy ZXNvbHZlcl9kbnMgc3Y0IGluCj4+PiBsZXQgY29uZHVpdCA9IGNvbmR1aXRfZGlyZWN0IHN2NCBp bgo+Pj4gCj4+PiBUaGUgc3RhY2sgKHN2NCkgaXMgaW5zdGFudGlhdGVkIGFzIG9uZSBmdW5jdG9y LCBidXQgaXMgY3VycmVudGx5IGNvbm5lY3QoKSdlZCB0d2ljZS4gIFRoZSBvYnNlcnZhYmxlIGJ1 ZyBpcyB0aGF0IGl0IGlzc3VlcyBhIERIQ1AgcXVlcnkgZm9yIGV2ZXJ5IHRpbWUgaXQgaXMgY2Fs bGVkLgo+Pj4gCj4+PiBGaWxsaW5nIHRoaXMgYXQgZmlyc3QgZ2xhbmNlIHJlcXVpcmVzIGluc3Rh bnRpYXRpb25zIHRvIGJlIGxhenksIHNvIHRoYXQgd2UgcmV1c2UgdGhlbS4gIEhvd2V2ZXIsIGl0 IG1heSBiZSBuZWNlc3NhcnkgdG8gZXhwbGljaXRseSBuYW1lIGRldmljZXMgc28gdGhhdCB3ZSBj YW4gc2FmZWx5IG1lbW9pc2UgbXVsdGlwbGUgc3RhY2tzIHRoYXQgc2hhcmUgdGhlIHNhbWUgZnVu Y3RvciBidXQgb3RoZXJ3aXNlIGRpZmZlciBpbiB0aGVpciBzdGF0ZSAoZS5nLiB0d28gY29tcGxl dGVseSBzZXBhcmF0ZSBzdGFja3MgdGhhdCBpc3N1ZSB0aGVpciBvd24gREhDUCByZXF1ZXN0cyB3 aXRoIHRoZWlyIG93biBNQUMgYWRkcmVzc2VzLCBidXQgb3RoZXJ3aXNlIHNoYXJlIHRoZSBzYW1l IE9DYW1sIFRDUC9JUCBmdW5jdG9ycykuCj4+PiAKPj4+IChzZWUgaHR0cHM6Ly9naXRodWIuY29t L21pcmFnZS9taXJhZ2UvaXNzdWVzLzMzMSBmb3IgbW9yZSkKPj4gCj4+IEFuIGFkZGVuZHVtIHRv IHRoaXMgaXMgdGhhdCB3ZSBkb24ndCB3YW50IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1 c2UgbGF6eSBhbmQgc2hhcmVkIGJ5IGRlZmF1bHQuCj4+IAo+PiBJbiB0aGUgZXhhbXBsZSBhYm92 ZSwgaXQgaXMgcGVyZmVjdGx5IHNlbnNpYmxlIHRvIHdhbnQgdG8gaGF2ZSBvbmUgSVAgc3RhY2sg Zm9yIHRoZSBwdXJwb3NlcyBvZiBETlMgcmVzb2x1dGlvbiBvbmx5LCBhbmQgYW5vdGhlciBmb3Ig dGhlIHB1cnBvc2VzIG9mIG9wZW5pbmcgbmV0d29yayBjb25uZWN0aW9ucyBmb3IgZGF0YSB0cmFu c2Zlci4gIFRoYXQncyBkaWZmaWN1bHQgdG8gc2V0dXAgb24gbW9zdCBzeXN0ZW1zIHRvZGF5LCBi dXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc2VtYmxlIHdpdGggTWlyYWdlLgo+PiAKPj4gLWFu aWwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJh Z2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5v cmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9t aXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 15:02:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 15:02:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXvb-0002QC-DS; Thu, 04 Dec 2014 15:02:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwXvZ-0002Q7-TN for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:02:46 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id BE/83-22819-59770845; Thu, 04 Dec 2014 15:02:45 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1417705364!11562439!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17886 invoked from network); 4 Dec 2014 15:02:44 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 15:02:44 -0000 Received: by mail-wi0-f173.google.com with SMTP id r20so35028757wiv.12 for ; Thu, 04 Dec 2014 07:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPe7YkJaKmSq1Z4nHYuqdaCv0JUj16DPhiT1RgMr3iw=; b=Ydn2Ljbf0mqnIOC8CMsChVL21UQ+tr32ZIGeHmRxKcMg0opFiJhQQqeNVWGkACuYtX jlrRRXn4mw3np2ibVL10LRw/HDL21zugCnJLrdr7WVJgYFhUjBrxIi89S6Z7Sv3qMOpk p0G2Rd3ly3dfia8CopuShzgnCCFX6ZouRb4ifVjYuGXqjDg1QUFpHbLExe3mOX0yDcM/ VqYu/FlxoITl8KgQDFCPEPYGXdxDckYU1H6O1ho/qVwMBkuYi1lqiRHB3Wrf+gB6nkhr I6C+BUv2nvVt9qoDrWeOYY3yQuNChPZ51dmyCDhjEQWLlhW3dB+71coCfsiQOXm2e6fC Obwg== X-Received: by 10.180.20.106 with SMTP id m10mr63518126wie.1.1417705363940; Thu, 04 Dec 2014 07:02:43 -0800 (PST) Received: from piana.mac.cl.cam.ac.uk (piana.mac.cl.cam.ac.uk. [128.232.56.38]) by mx.google.com with ESMTPSA id vm8sm40842966wjc.6.2014.12.04.07.02.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:02:43 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Thu, 4 Dec 2014 15:02:41 +0000 Message-Id: <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhbmtzLCB2ZXJ5IG5pY2UgcmVhZC4KCkZldyBxdWVzdGlvbnMgdGhvdWdoOgotIEkgZ3Vlc3Mg dGhlIG1haW4gZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBQYXJhbXMudCBhbmQgQ21kbGluZXIuVGVy bS50IGlzIHRoYXQgdGhlIHBhcmFtcyBhcmUgbW9yZSAibWV0YSI6IHRoZXkgbm93IGhvdyB0byBw cmludCBPQ2FtbCB2YWx1ZXMgYW5kIGZ1bmN0aW9ucyBwYXJzaW5nIE9DYW1sIHZhbHVlcyBvZiB0 aGF0IHR5cGUgKGllLiB0aGF0J3MgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9mIE1pcmFnZSBtdWx0 aS1zdGFnZSBjb21waWxhdGlvbiwgYnV0IG1heWJlIG5vdCBzbyB1c2VmdWwgaW4gYSBtb3JlIGdl bmVyaWMgY2FzZSkKLSBJcyB0aGF0IHBvc3NpYmxlIHRvIGJ1aWxkIGN1c3RvbSAnYSBjb252ZXJ0 ZXI/IE1pc3NpbmcgYW4gKGBhIG9wdGlvbiBjb252ZXJ0ZXIpIGFuZCAoaW50ezMyLDY0fSBjb252 ZXJ0ZXIpLCBldGMuLi4KCkkgYW0gbm90IHZlcnkgZm9uZCBvZiB0aGUgZGVmYXVsdCByZWZlcmVu Y2VzLCBub3Qgc3VyZSB3aHkgeW91IHdhbnQgc29tZW9uZSB0byBjaGFuZ2UgdGhlbSBnbG9iYWxs eS4KCkFsc28sIGhvdyBkb2VzIGl0IHdvcmsgd2hlbiB5b3Ugd2FudCB0byBkZWZpbmUgeW91ciBj dXN0b20gcGFyYW1ldGVycyBpbiBjb25maWcubWw/IEkgdGhpbmsgdGhhdCB3YXMgTWFnbnVzIHdh bnRlZCB0byBnZXQgaGlzIHJ1bnRpbWUgZXh0cmEgdmFsdWUuCgpUaG9tYXMKCj4gT24gNCBEZWMg MjAxNCwgYXQgMTQ6NDEsIE5pY29sYXMgT2plZGEgQmFyIDxubzI2M0BkcG1tcy5jYW0uYWMudWs+ IHdyb3RlOgo+IAo+IEhpIGxpc3QsCj4gCj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMgc28gZmFy LiAgRm9yIGdyZWF0ZXIgY2xhcml0eSBhbmQgcHJlY2lzaW9uLCBJIHdyb3RlIGEKPiBzaG9ydCBk b2N1bWVudCBleHBsYWluaW5nIHRoZSByYXRpb25hbGUgYW5kIHRoZSBkZXNpZ24gb2YgdGhlIHBy b3Bvc2VkCj4gY2hhbmdlcyB0byB0aGUKPiBgbWlyYWdlIGNvbmZpZ3VyZWAgdG9vbC4KPiAKPiBo dHRwczovL2dpc3QuZ2l0aHViLmNvbS9ub2piL2Y5YzI2MmQ1ZmQ2OTFlNjE3MWNhCj4gCj4gQW55 IGNvbW1lbnRzIGFwcHJlY2lhdGVkIQo+IAo+IEJlc3Qgd2lzaGVzLAo+IE5pY29sYXMKPiAKPiAK PiBPbiBUdWUsIERlYyAyLCAyMDE0IGF0IDQ6NTggUE0sIEFuaWwgTWFkaGF2YXBlZGR5IDxhbmls QHJlY29pbC5vcmc+IHdyb3RlOgo+PiBPbiAyIERlYyAyMDE0LCBhdCAxNjo1MiwgQW5pbCBNYWRo YXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+Pj4gT24gMSBEZWMgMjAxNCwgYXQg MTQ6MzEsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBlcnJhdGlxdWUuY2g+IHdyb3Rl Ogo+Pj4+IExlIGx1bmRpLCAxIGTDqWNlbWJyZSAyMDE0IMOgIDE1OjA1LCBUaG9tYXMgR2F6YWdu YWlyZSBhIMOpY3JpdCA6Cj4+Pj4gCj4+Pj4+PiBPbmUgY2FuIG9mIGNvdXJzZSwgbWFrZSB0aGUg bmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0aGUgbmFtZSBvZiB0aGUKPj4+Pj4+IHBhcmFtZXRl ciB3aXRoIHRoZSBuYW1lIG9mIHRoZSBDT05GSUdVUkFCTEUgKGN1cnJlbnRseQo+Pj4+Pj4gc2Vt aS1hbGdvcml0aG1pY2FsbHkgZ2VuZXJhdGVkIHRvIGtlZXAgdGhlbSB1bmlxdWUpLCBidXQgdGhp cyBkb2VzIG5vdAo+Pj4+Pj4gc2VlbSB2ZXJ5IHVzZXIgZnJpZW5kbHkuCj4+Pj4+IAo+Pj4+PiBN YXliZSBleHBvc2UgYSA/bmFtZSBwYXJhbWF0ZXIgdG8gYWxsIHRoZSBjb21iaW5hdG9ycyB3aGlj aCB3aWxsIGJlIHByZWZpeGVkIHRvIHBhcmFtZXRlciBhcmd1bWVudHMgaWYgbmVlZGVkLgo+Pj4+ IAo+Pj4+IEknbSBub3Qgc3VyZSB0aGF0J3MgdGhlIHByb2JsZW0uIElmIEkgdW5kZXJzdG9vZCB3 ZWxsIGl0IHNlZW1zIHRoYXQgZnVuY3RvciBhcHBsaWNhdGlvbiBkb2VzIGdlbmVyYXRlIG5ldyBj b25maWd1cmF0aW9uIHZhbHVlcy4KPj4+PiAKPj4+PiBPZiBjb3Vyc2UgaWYgdGhleSBhcmUgbWVh bnQgdG8gYmUgc2hhcmVkIGFtb25nIGluc3RhbmNlcyBpdCBtZWFucyB0aGF0IHlvdSBhcmUgZGVj bGFyaW5nIHRoZW0gYXQgdGhlIHdyb25nIHBsYWNlLiBCZXN0IHdvdWxkIGJlIHRvIGRlZmluZSBh IG1vZHVsZSB3aXRoICJzdGFuZGFyZCIgY29uZmlndXJhdGlvbiBrZXlzIChlLmcuIGlwIGFkZHJl c3MpIHRvIGJlIHVzZWQgdG8gYmUgdXNlZCB0aHJvdWdob3V0IHRoZSBzeXN0ZW0gYW5kIHRlbGxp bmcgdXNlcnMgdG8gZmlyc3QgdHJ5IHRvIHVzZSB0aGUgc3RhbmRhcmQgY29uZmlndXJhdGlvbiBr ZXlzIGJlZm9yZSB0cnlpbmcgdG8gZGVmaW5lIG5ldyBvbmVzLgo+Pj4gCj4+PiBPbmUgcHJvYmxl bSBjdXJyZW50bHkgaXMgdGhhdCB3aGlsZSBmdW5jdG9yIGFwcGxpY2F0aW9uIGdlbmVyYXRlcyBu ZXcgY29uZmlndXJhdGlvbiB2YWx1ZXMsIHRoZSBhY3R1YWwgaW5zdGFudGlhdGlvbnMgb2YgZGV2 aWNlcyBtYXkgcmV1c2UgdGhlIGZ1bmN0b3IgYXBwbGljYXRpb24gd2l0aCBkaWZmZXJlbnQgc3Rh dGUgdmFyaWFibGVzLgo+Pj4gCj4+PiBGb3IgaW5zdGFuY2UsIHJpZ2h0IG5vdyBpZiB3ZSBnZW5l cmF0ZSBhIEhUVFAgY2xpZW50LCB3ZSBuZWVkIHRoaXMgaW4gb3VyIGNvbmZpZy5tbDoKPj4+IAo+ Pj4gbGV0IHN2NCA9IHN0YWNrIGRlZmF1bHRfY29uc29sZSBpbgo+Pj4gbGV0IHJlc19kbnMgPSBy ZXNvbHZlcl9kbnMgc3Y0IGluCj4+PiBsZXQgY29uZHVpdCA9IGNvbmR1aXRfZGlyZWN0IHN2NCBp bgo+Pj4gCj4+PiBUaGUgc3RhY2sgKHN2NCkgaXMgaW5zdGFudGlhdGVkIGFzIG9uZSBmdW5jdG9y LCBidXQgaXMgY3VycmVudGx5IGNvbm5lY3QoKSdlZCB0d2ljZS4gIFRoZSBvYnNlcnZhYmxlIGJ1 ZyBpcyB0aGF0IGl0IGlzc3VlcyBhIERIQ1AgcXVlcnkgZm9yIGV2ZXJ5IHRpbWUgaXQgaXMgY2Fs bGVkLgo+Pj4gCj4+PiBGaWxsaW5nIHRoaXMgYXQgZmlyc3QgZ2xhbmNlIHJlcXVpcmVzIGluc3Rh bnRpYXRpb25zIHRvIGJlIGxhenksIHNvIHRoYXQgd2UgcmV1c2UgdGhlbS4gIEhvd2V2ZXIsIGl0 IG1heSBiZSBuZWNlc3NhcnkgdG8gZXhwbGljaXRseSBuYW1lIGRldmljZXMgc28gdGhhdCB3ZSBj YW4gc2FmZWx5IG1lbW9pc2UgbXVsdGlwbGUgc3RhY2tzIHRoYXQgc2hhcmUgdGhlIHNhbWUgZnVu Y3RvciBidXQgb3RoZXJ3aXNlIGRpZmZlciBpbiB0aGVpciBzdGF0ZSAoZS5nLiB0d28gY29tcGxl dGVseSBzZXBhcmF0ZSBzdGFja3MgdGhhdCBpc3N1ZSB0aGVpciBvd24gREhDUCByZXF1ZXN0cyB3 aXRoIHRoZWlyIG93biBNQUMgYWRkcmVzc2VzLCBidXQgb3RoZXJ3aXNlIHNoYXJlIHRoZSBzYW1l IE9DYW1sIFRDUC9JUCBmdW5jdG9ycykuCj4+PiAKPj4+IChzZWUgaHR0cHM6Ly9naXRodWIuY29t L21pcmFnZS9taXJhZ2UvaXNzdWVzLzMzMSBmb3IgbW9yZSkKPj4gCj4+IEFuIGFkZGVuZHVtIHRv IHRoaXMgaXMgdGhhdCB3ZSBkb24ndCB3YW50IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1 c2UgbGF6eSBhbmQgc2hhcmVkIGJ5IGRlZmF1bHQuCj4+IAo+PiBJbiB0aGUgZXhhbXBsZSBhYm92 ZSwgaXQgaXMgcGVyZmVjdGx5IHNlbnNpYmxlIHRvIHdhbnQgdG8gaGF2ZSBvbmUgSVAgc3RhY2sg Zm9yIHRoZSBwdXJwb3NlcyBvZiBETlMgcmVzb2x1dGlvbiBvbmx5LCBhbmQgYW5vdGhlciBmb3Ig dGhlIHB1cnBvc2VzIG9mIG9wZW5pbmcgbmV0d29yayBjb25uZWN0aW9ucyBmb3IgZGF0YSB0cmFu c2Zlci4gIFRoYXQncyBkaWZmaWN1bHQgdG8gc2V0dXAgb24gbW9zdCBzeXN0ZW1zIHRvZGF5LCBi dXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFzc2VtYmxlIHdpdGggTWlyYWdlLgo+PiAKPj4gLWFu aWwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJh Z2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5v cmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9t aXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 15:14:01 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 15:14:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwY6S-0003Jv-7i; Thu, 04 Dec 2014 15:14:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwY6Q-0003Jl-Py for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:13:59 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 7B/05-29352-63A70845; Thu, 04 Dec 2014 15:13:58 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1417706037!11622062!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21152 invoked from network); 4 Dec 2014 15:13:57 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 15:13:57 -0000 Received: by mail-wi0-f170.google.com with SMTP id bs8so36658089wib.5 for ; Thu, 04 Dec 2014 07:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SRr/nJfzqQ8lrELdF4HPJAR/AxXRkfoOM7j5tx+BuzY=; b=svtZwbVzKtog63Z6KZU0s1i1uxQF2dHWMS9adRZEsnaske8+9g2ov3DQrB7l+19VaK ECgrTTUxSnX19745i57EGhKU1u8dkvUkMxM6hTWOReIOo59AAyVTOUX4c4sHUlB0Csb6 GXIn5x672ps2wut2YLsB3YEyN9J5klMVScucwOrmBHDjvF2PMYCLVMNWohaMFlsHdjva m7J8H8MouHxWZS3MA5XX5FAjRBeK22O4wflIUDKNKfT57tRED5bUGStxiWZuBNoD3XMw mqEvKgGt/JsJofGyOXFZ19zoQK6Gnblo7KI0uru3IdqxMeeWNQY2aA4rnLCaTr5X4O/X 6esw== MIME-Version: 1.0 X-Received: by 10.180.73.235 with SMTP id o11mr90890911wiv.51.1417706036963; Thu, 04 Dec 2014 07:13:56 -0800 (PST) Received: by 10.27.171.146 with HTTP; Thu, 4 Dec 2014 07:13:56 -0800 (PST) In-Reply-To: <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> Date: Thu, 4 Dec 2014 15:13:56 +0000 X-Google-Sender-Auth: LPyw7HmXXvYKkRA0QiqiUgo3P48 Message-ID: From: Nicolas Ojeda Bar To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gVGh1LCBEZWMgNCwgMjAxNCBhdCAzOjAyIFBNLCBUaG9tYXMgR2F6YWduYWlyZSA8dGhvbWFz QGdhemFnbmFpcmUub3JnPiB3cm90ZToKPiBUaGFua3MsIHZlcnkgbmljZSByZWFkLgo+Cj4gRmV3 IHF1ZXN0aW9ucyB0aG91Z2g6Cj4gLSBJIGd1ZXNzIHRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGUgUGFyYW1zLnQgYW5kIENtZGxpbmVyLlRlcm0udCBpcyB0aGF0IHRoZSBwYXJhbXMgYXJl IG1vcmUgIm1ldGEiOiB0aGV5IG5vdyBob3cgdG8gcHJpbnQgT0NhbWwgdmFsdWVzIGFuZCBmdW5j dGlvbnMgcGFyc2luZyBPQ2FtbCB2YWx1ZXMgb2YgdGhhdCB0eXBlIChpZS4gdGhhdCdzIHVzZWZ1 bCBpbiB0aGUgY29udGV4dCBvZiBNaXJhZ2UgbXVsdGktc3RhZ2UgY29tcGlsYXRpb24sIGJ1dCBt YXliZSBub3Qgc28gdXNlZnVsIGluIGEgbW9yZSBnZW5lcmljIGNhc2UpCgpZZXMsIHRoZSBtYWlu IGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgYCdhIGNvbnZlcnRlcmAgdHlwZSBvZiBgUGFyYW1gCm5l ZWRzIHRvIGRvIG1vcmUuICBPdGhlciB0aGFuIHRoYXQgb25lIGNvdWxkIGFsbW9zdCByZXBsYWNl IGEgYCdhClBhcmFtLnRgIHdpdGggYSBgJ2EgQ21kbGluZXIuVGVybS50YC4KCj4gLSBJcyB0aGF0 IHBvc3NpYmxlIHRvIGJ1aWxkIGN1c3RvbSAnYSBjb252ZXJ0ZXI/IE1pc3NpbmcgYW4gKGBhIG9w dGlvbiBjb252ZXJ0ZXIpIGFuZCAoaW50ezMyLDY0fSBjb252ZXJ0ZXIpLCBldGMuLi4KClllcywg b2YgY291cnNlLiAgSSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGF0LgoKPiBJIGFtIG5vdCB2ZXJ5IGZv bmQgb2YgdGhlIGRlZmF1bHQgcmVmZXJlbmNlcywgbm90IHN1cmUgd2h5IHlvdSB3YW50IHNvbWVv bmUgdG8gY2hhbmdlIHRoZW0gZ2xvYmFsbHkuCgpBZ3JlZWQuCgo+IEFsc28sIGhvdyBkb2VzIGl0 IHdvcmsgd2hlbiB5b3Ugd2FudCB0byBkZWZpbmUgeW91ciBjdXN0b20gcGFyYW1ldGVycyBpbiBj b25maWcubWw/IEkgdGhpbmsgdGhhdCB3YXMgTWFnbnVzIHdhbnRlZCB0byBnZXQgaGlzIHJ1bnRp bWUgZXh0cmEgdmFsdWUuCgpUaGlzIHdvdWxkIGludm9sdmUgYWRkaW5nIGEgZnVuY3Rpb24gYGFk ZF90b19wYXJhbXNgIHNpbWlsYXIgdG8KYGFkZF90b19vcGFtX3BhY2thZ2VzYCBhbmQgYGFkZF90 b19vY2FtbGZpbmRfbGlicmFyaWVzYCB0byBzaWduYWwgdGhhdApzb21lIGV4dHJhIHBhcmFtcwph cmUgdXNlZCBieSB0aGUgdW5pa2VybmVsLiAgTW9yZW92ZXIgYSBtZWNoYW5pc20gaXMgbmVlZGVk IHRvIGFjY2Vzcwp0aGUgdmFsdWUgb2YgdGhvc2UgcGFyYW1ldGVycyBmcm9tIGluc2lkZSB0aGUg dW5pa2VybmVsIGNvZGUsIGJ1dCBJCmhhdmVuJ3QgZmlndXJlZCB0aGlzIG91dAp5ZXQuCgpUaGFu a3MgZm9yIHRoZSBjb21tZW50cyEKCkJlc3Qgd2lzaGVzLApOaWNvbGFzCgo+IFRob21hcwo+Cj4+ IE9uIDQgRGVjIDIwMTQsIGF0IDE0OjQxLCBOaWNvbGFzIE9qZWRhIEJhciA8bm8yNjNAZHBtbXMu Y2FtLmFjLnVrPiB3cm90ZToKPj4KPj4gSGkgbGlzdCwKPj4KPj4gVGhhbmtzIGZvciB0aGUgY29t bWVudHMgc28gZmFyLiAgRm9yIGdyZWF0ZXIgY2xhcml0eSBhbmQgcHJlY2lzaW9uLCBJIHdyb3Rl IGEKPj4gc2hvcnQgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgcmF0aW9uYWxlIGFuZCB0aGUgZGVz aWduIG9mIHRoZSBwcm9wb3NlZAo+PiBjaGFuZ2VzIHRvIHRoZQo+PiBgbWlyYWdlIGNvbmZpZ3Vy ZWAgdG9vbC4KPj4KPj4gaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vbm9qYi9mOWMyNjJkNWZkNjkx ZTYxNzFjYQo+Pgo+PiBBbnkgY29tbWVudHMgYXBwcmVjaWF0ZWQhCj4+Cj4+IEJlc3Qgd2lzaGVz LAo+PiBOaWNvbGFzCj4+Cj4+Cj4+IE9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgNDo1OCBQTSwgQW5p bCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+PiBPbiAyIERlYyAyMDE0 LCBhdCAxNjo1MiwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+ Pj4+IE9uIDEgRGVjIDIwMTQsIGF0IDE0OjMxLCBEYW5pZWwgQsO8bnpsaSA8ZGFuaWVsLmJ1ZW56 bGlAZXJyYXRpcXVlLmNoPiB3cm90ZToKPj4+Pj4gTGUgbHVuZGksIDEgZMOpY2VtYnJlIDIwMTQg w6AgMTU6MDUsIFRob21hcyBHYXphZ25haXJlIGEgw6ljcml0IDoKPj4+Pj4KPj4+Pj4+PiBPbmUg Y2FuIG9mIGNvdXJzZSwgbWFrZSB0aGUgbmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0aGUgbmFt ZSBvZiB0aGUKPj4+Pj4+PiBwYXJhbWV0ZXIgd2l0aCB0aGUgbmFtZSBvZiB0aGUgQ09ORklHVVJB QkxFIChjdXJyZW50bHkKPj4+Pj4+PiBzZW1pLWFsZ29yaXRobWljYWxseSBnZW5lcmF0ZWQgdG8g a2VlcCB0aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90Cj4+Pj4+Pj4gc2VlbSB2ZXJ5IHVz ZXIgZnJpZW5kbHkuCj4+Pj4+Pgo+Pj4+Pj4gTWF5YmUgZXhwb3NlIGEgP25hbWUgcGFyYW1hdGVy IHRvIGFsbCB0aGUgY29tYmluYXRvcnMgd2hpY2ggd2lsbCBiZSBwcmVmaXhlZCB0byBwYXJhbWV0 ZXIgYXJndW1lbnRzIGlmIG5lZWRlZC4KPj4+Pj4KPj4+Pj4gSSdtIG5vdCBzdXJlIHRoYXQncyB0 aGUgcHJvYmxlbS4gSWYgSSB1bmRlcnN0b29kIHdlbGwgaXQgc2VlbXMgdGhhdCBmdW5jdG9yIGFw cGxpY2F0aW9uIGRvZXMgZ2VuZXJhdGUgbmV3IGNvbmZpZ3VyYXRpb24gdmFsdWVzLgo+Pj4+Pgo+ Pj4+PiBPZiBjb3Vyc2UgaWYgdGhleSBhcmUgbWVhbnQgdG8gYmUgc2hhcmVkIGFtb25nIGluc3Rh bmNlcyBpdCBtZWFucyB0aGF0IHlvdSBhcmUgZGVjbGFyaW5nIHRoZW0gYXQgdGhlIHdyb25nIHBs YWNlLiBCZXN0IHdvdWxkIGJlIHRvIGRlZmluZSBhIG1vZHVsZSB3aXRoICJzdGFuZGFyZCIgY29u ZmlndXJhdGlvbiBrZXlzIChlLmcuIGlwIGFkZHJlc3MpIHRvIGJlIHVzZWQgdG8gYmUgdXNlZCB0 aHJvdWdob3V0IHRoZSBzeXN0ZW0gYW5kIHRlbGxpbmcgdXNlcnMgdG8gZmlyc3QgdHJ5IHRvIHVz ZSB0aGUgc3RhbmRhcmQgY29uZmlndXJhdGlvbiBrZXlzIGJlZm9yZSB0cnlpbmcgdG8gZGVmaW5l IG5ldyBvbmVzLgo+Pj4+Cj4+Pj4gT25lIHByb2JsZW0gY3VycmVudGx5IGlzIHRoYXQgd2hpbGUg ZnVuY3RvciBhcHBsaWNhdGlvbiBnZW5lcmF0ZXMgbmV3IGNvbmZpZ3VyYXRpb24gdmFsdWVzLCB0 aGUgYWN0dWFsIGluc3RhbnRpYXRpb25zIG9mIGRldmljZXMgbWF5IHJldXNlIHRoZSBmdW5jdG9y IGFwcGxpY2F0aW9uIHdpdGggZGlmZmVyZW50IHN0YXRlIHZhcmlhYmxlcy4KPj4+Pgo+Pj4+IEZv ciBpbnN0YW5jZSwgcmlnaHQgbm93IGlmIHdlIGdlbmVyYXRlIGEgSFRUUCBjbGllbnQsIHdlIG5l ZWQgdGhpcyBpbiBvdXIgY29uZmlnLm1sOgo+Pj4+Cj4+Pj4gbGV0IHN2NCA9IHN0YWNrIGRlZmF1 bHRfY29uc29sZSBpbgo+Pj4+IGxldCByZXNfZG5zID0gcmVzb2x2ZXJfZG5zIHN2NCBpbgo+Pj4+ IGxldCBjb25kdWl0ID0gY29uZHVpdF9kaXJlY3Qgc3Y0IGluCj4+Pj4KPj4+PiBUaGUgc3RhY2sg KHN2NCkgaXMgaW5zdGFudGlhdGVkIGFzIG9uZSBmdW5jdG9yLCBidXQgaXMgY3VycmVudGx5IGNv bm5lY3QoKSdlZCB0d2ljZS4gIFRoZSBvYnNlcnZhYmxlIGJ1ZyBpcyB0aGF0IGl0IGlzc3VlcyBh IERIQ1AgcXVlcnkgZm9yIGV2ZXJ5IHRpbWUgaXQgaXMgY2FsbGVkLgo+Pj4+Cj4+Pj4gRmlsbGlu ZyB0aGlzIGF0IGZpcnN0IGdsYW5jZSByZXF1aXJlcyBpbnN0YW50aWF0aW9ucyB0byBiZSBsYXp5 LCBzbyB0aGF0IHdlIHJldXNlIHRoZW0uICBIb3dldmVyLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRv IGV4cGxpY2l0bHkgbmFtZSBkZXZpY2VzIHNvIHRoYXQgd2UgY2FuIHNhZmVseSBtZW1vaXNlIG11 bHRpcGxlIHN0YWNrcyB0aGF0IHNoYXJlIHRoZSBzYW1lIGZ1bmN0b3IgYnV0IG90aGVyd2lzZSBk aWZmZXIgaW4gdGhlaXIgc3RhdGUgKGUuZy4gdHdvIGNvbXBsZXRlbHkgc2VwYXJhdGUgc3RhY2tz IHRoYXQgaXNzdWUgdGhlaXIgb3duIERIQ1AgcmVxdWVzdHMgd2l0aCB0aGVpciBvd24gTUFDIGFk ZHJlc3NlcywgYnV0IG90aGVyd2lzZSBzaGFyZSB0aGUgc2FtZSBPQ2FtbCBUQ1AvSVAgZnVuY3Rv cnMpLgo+Pj4+Cj4+Pj4gKHNlZSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFnZS9pc3N1 ZXMvMzMxIGZvciBtb3JlKQo+Pj4KPj4+IEFuIGFkZGVuZHVtIHRvIHRoaXMgaXMgdGhhdCB3ZSBk b24ndCB3YW50IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1c2UgbGF6eSBhbmQgc2hhcmVk IGJ5IGRlZmF1bHQuCj4+Pgo+Pj4gSW4gdGhlIGV4YW1wbGUgYWJvdmUsIGl0IGlzIHBlcmZlY3Rs eSBzZW5zaWJsZSB0byB3YW50IHRvIGhhdmUgb25lIElQIHN0YWNrIGZvciB0aGUgcHVycG9zZXMg b2YgRE5TIHJlc29sdXRpb24gb25seSwgYW5kIGFub3RoZXIgZm9yIHRoZSBwdXJwb3NlcyBvZiBv cGVuaW5nIG5ldHdvcmsgY29ubmVjdGlvbnMgZm9yIGRhdGEgdHJhbnNmZXIuICBUaGF0J3MgZGlm ZmljdWx0IHRvIHNldHVwIG9uIG1vc3Qgc3lzdGVtcyB0b2RheSwgYnV0IHNob3VsZCBiZSBwb3Nz aWJsZSB0byBhc3NlbWJsZSB3aXRoIE1pcmFnZS4KPj4+Cj4+PiAtYW5pbAo+CgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWls aW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 15:14:01 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 15:14:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwY6S-0003Jv-7i; Thu, 04 Dec 2014 15:14:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwY6Q-0003Jl-Py for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 15:13:59 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 7B/05-29352-63A70845; Thu, 04 Dec 2014 15:13:58 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1417706037!11622062!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21152 invoked from network); 4 Dec 2014 15:13:57 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 15:13:57 -0000 Received: by mail-wi0-f170.google.com with SMTP id bs8so36658089wib.5 for ; Thu, 04 Dec 2014 07:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SRr/nJfzqQ8lrELdF4HPJAR/AxXRkfoOM7j5tx+BuzY=; b=svtZwbVzKtog63Z6KZU0s1i1uxQF2dHWMS9adRZEsnaske8+9g2ov3DQrB7l+19VaK ECgrTTUxSnX19745i57EGhKU1u8dkvUkMxM6hTWOReIOo59AAyVTOUX4c4sHUlB0Csb6 GXIn5x672ps2wut2YLsB3YEyN9J5klMVScucwOrmBHDjvF2PMYCLVMNWohaMFlsHdjva m7J8H8MouHxWZS3MA5XX5FAjRBeK22O4wflIUDKNKfT57tRED5bUGStxiWZuBNoD3XMw mqEvKgGt/JsJofGyOXFZ19zoQK6Gnblo7KI0uru3IdqxMeeWNQY2aA4rnLCaTr5X4O/X 6esw== MIME-Version: 1.0 X-Received: by 10.180.73.235 with SMTP id o11mr90890911wiv.51.1417706036963; Thu, 04 Dec 2014 07:13:56 -0800 (PST) Received: by 10.27.171.146 with HTTP; Thu, 4 Dec 2014 07:13:56 -0800 (PST) In-Reply-To: <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> Date: Thu, 4 Dec 2014 15:13:56 +0000 X-Google-Sender-Auth: LPyw7HmXXvYKkRA0QiqiUgo3P48 Message-ID: From: Nicolas Ojeda Bar To: Thomas Gazagnaire Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gVGh1LCBEZWMgNCwgMjAxNCBhdCAzOjAyIFBNLCBUaG9tYXMgR2F6YWduYWlyZSA8dGhvbWFz QGdhemFnbmFpcmUub3JnPiB3cm90ZToKPiBUaGFua3MsIHZlcnkgbmljZSByZWFkLgo+Cj4gRmV3 IHF1ZXN0aW9ucyB0aG91Z2g6Cj4gLSBJIGd1ZXNzIHRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGUgUGFyYW1zLnQgYW5kIENtZGxpbmVyLlRlcm0udCBpcyB0aGF0IHRoZSBwYXJhbXMgYXJl IG1vcmUgIm1ldGEiOiB0aGV5IG5vdyBob3cgdG8gcHJpbnQgT0NhbWwgdmFsdWVzIGFuZCBmdW5j dGlvbnMgcGFyc2luZyBPQ2FtbCB2YWx1ZXMgb2YgdGhhdCB0eXBlIChpZS4gdGhhdCdzIHVzZWZ1 bCBpbiB0aGUgY29udGV4dCBvZiBNaXJhZ2UgbXVsdGktc3RhZ2UgY29tcGlsYXRpb24sIGJ1dCBt YXliZSBub3Qgc28gdXNlZnVsIGluIGEgbW9yZSBnZW5lcmljIGNhc2UpCgpZZXMsIHRoZSBtYWlu IGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgYCdhIGNvbnZlcnRlcmAgdHlwZSBvZiBgUGFyYW1gCm5l ZWRzIHRvIGRvIG1vcmUuICBPdGhlciB0aGFuIHRoYXQgb25lIGNvdWxkIGFsbW9zdCByZXBsYWNl IGEgYCdhClBhcmFtLnRgIHdpdGggYSBgJ2EgQ21kbGluZXIuVGVybS50YC4KCj4gLSBJcyB0aGF0 IHBvc3NpYmxlIHRvIGJ1aWxkIGN1c3RvbSAnYSBjb252ZXJ0ZXI/IE1pc3NpbmcgYW4gKGBhIG9w dGlvbiBjb252ZXJ0ZXIpIGFuZCAoaW50ezMyLDY0fSBjb252ZXJ0ZXIpLCBldGMuLi4KClllcywg b2YgY291cnNlLiAgSSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGF0LgoKPiBJIGFtIG5vdCB2ZXJ5IGZv bmQgb2YgdGhlIGRlZmF1bHQgcmVmZXJlbmNlcywgbm90IHN1cmUgd2h5IHlvdSB3YW50IHNvbWVv bmUgdG8gY2hhbmdlIHRoZW0gZ2xvYmFsbHkuCgpBZ3JlZWQuCgo+IEFsc28sIGhvdyBkb2VzIGl0 IHdvcmsgd2hlbiB5b3Ugd2FudCB0byBkZWZpbmUgeW91ciBjdXN0b20gcGFyYW1ldGVycyBpbiBj b25maWcubWw/IEkgdGhpbmsgdGhhdCB3YXMgTWFnbnVzIHdhbnRlZCB0byBnZXQgaGlzIHJ1bnRp bWUgZXh0cmEgdmFsdWUuCgpUaGlzIHdvdWxkIGludm9sdmUgYWRkaW5nIGEgZnVuY3Rpb24gYGFk ZF90b19wYXJhbXNgIHNpbWlsYXIgdG8KYGFkZF90b19vcGFtX3BhY2thZ2VzYCBhbmQgYGFkZF90 b19vY2FtbGZpbmRfbGlicmFyaWVzYCB0byBzaWduYWwgdGhhdApzb21lIGV4dHJhIHBhcmFtcwph cmUgdXNlZCBieSB0aGUgdW5pa2VybmVsLiAgTW9yZW92ZXIgYSBtZWNoYW5pc20gaXMgbmVlZGVk IHRvIGFjY2Vzcwp0aGUgdmFsdWUgb2YgdGhvc2UgcGFyYW1ldGVycyBmcm9tIGluc2lkZSB0aGUg dW5pa2VybmVsIGNvZGUsIGJ1dCBJCmhhdmVuJ3QgZmlndXJlZCB0aGlzIG91dAp5ZXQuCgpUaGFu a3MgZm9yIHRoZSBjb21tZW50cyEKCkJlc3Qgd2lzaGVzLApOaWNvbGFzCgo+IFRob21hcwo+Cj4+ IE9uIDQgRGVjIDIwMTQsIGF0IDE0OjQxLCBOaWNvbGFzIE9qZWRhIEJhciA8bm8yNjNAZHBtbXMu Y2FtLmFjLnVrPiB3cm90ZToKPj4KPj4gSGkgbGlzdCwKPj4KPj4gVGhhbmtzIGZvciB0aGUgY29t bWVudHMgc28gZmFyLiAgRm9yIGdyZWF0ZXIgY2xhcml0eSBhbmQgcHJlY2lzaW9uLCBJIHdyb3Rl IGEKPj4gc2hvcnQgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgcmF0aW9uYWxlIGFuZCB0aGUgZGVz aWduIG9mIHRoZSBwcm9wb3NlZAo+PiBjaGFuZ2VzIHRvIHRoZQo+PiBgbWlyYWdlIGNvbmZpZ3Vy ZWAgdG9vbC4KPj4KPj4gaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vbm9qYi9mOWMyNjJkNWZkNjkx ZTYxNzFjYQo+Pgo+PiBBbnkgY29tbWVudHMgYXBwcmVjaWF0ZWQhCj4+Cj4+IEJlc3Qgd2lzaGVz LAo+PiBOaWNvbGFzCj4+Cj4+Cj4+IE9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgNDo1OCBQTSwgQW5p bCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+PiBPbiAyIERlYyAyMDE0 LCBhdCAxNjo1MiwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+ Pj4+IE9uIDEgRGVjIDIwMTQsIGF0IDE0OjMxLCBEYW5pZWwgQsO8bnpsaSA8ZGFuaWVsLmJ1ZW56 bGlAZXJyYXRpcXVlLmNoPiB3cm90ZToKPj4+Pj4gTGUgbHVuZGksIDEgZMOpY2VtYnJlIDIwMTQg w6AgMTU6MDUsIFRob21hcyBHYXphZ25haXJlIGEgw6ljcml0IDoKPj4+Pj4KPj4+Pj4+PiBPbmUg Y2FuIG9mIGNvdXJzZSwgbWFrZSB0aGUgbmFtZXMgdW5pcXVlIGJ5IGNvbWJpbmluZyB0aGUgbmFt ZSBvZiB0aGUKPj4+Pj4+PiBwYXJhbWV0ZXIgd2l0aCB0aGUgbmFtZSBvZiB0aGUgQ09ORklHVVJB QkxFIChjdXJyZW50bHkKPj4+Pj4+PiBzZW1pLWFsZ29yaXRobWljYWxseSBnZW5lcmF0ZWQgdG8g a2VlcCB0aGVtIHVuaXF1ZSksIGJ1dCB0aGlzIGRvZXMgbm90Cj4+Pj4+Pj4gc2VlbSB2ZXJ5IHVz ZXIgZnJpZW5kbHkuCj4+Pj4+Pgo+Pj4+Pj4gTWF5YmUgZXhwb3NlIGEgP25hbWUgcGFyYW1hdGVy IHRvIGFsbCB0aGUgY29tYmluYXRvcnMgd2hpY2ggd2lsbCBiZSBwcmVmaXhlZCB0byBwYXJhbWV0 ZXIgYXJndW1lbnRzIGlmIG5lZWRlZC4KPj4+Pj4KPj4+Pj4gSSdtIG5vdCBzdXJlIHRoYXQncyB0 aGUgcHJvYmxlbS4gSWYgSSB1bmRlcnN0b29kIHdlbGwgaXQgc2VlbXMgdGhhdCBmdW5jdG9yIGFw cGxpY2F0aW9uIGRvZXMgZ2VuZXJhdGUgbmV3IGNvbmZpZ3VyYXRpb24gdmFsdWVzLgo+Pj4+Pgo+ Pj4+PiBPZiBjb3Vyc2UgaWYgdGhleSBhcmUgbWVhbnQgdG8gYmUgc2hhcmVkIGFtb25nIGluc3Rh bmNlcyBpdCBtZWFucyB0aGF0IHlvdSBhcmUgZGVjbGFyaW5nIHRoZW0gYXQgdGhlIHdyb25nIHBs YWNlLiBCZXN0IHdvdWxkIGJlIHRvIGRlZmluZSBhIG1vZHVsZSB3aXRoICJzdGFuZGFyZCIgY29u ZmlndXJhdGlvbiBrZXlzIChlLmcuIGlwIGFkZHJlc3MpIHRvIGJlIHVzZWQgdG8gYmUgdXNlZCB0 aHJvdWdob3V0IHRoZSBzeXN0ZW0gYW5kIHRlbGxpbmcgdXNlcnMgdG8gZmlyc3QgdHJ5IHRvIHVz ZSB0aGUgc3RhbmRhcmQgY29uZmlndXJhdGlvbiBrZXlzIGJlZm9yZSB0cnlpbmcgdG8gZGVmaW5l IG5ldyBvbmVzLgo+Pj4+Cj4+Pj4gT25lIHByb2JsZW0gY3VycmVudGx5IGlzIHRoYXQgd2hpbGUg ZnVuY3RvciBhcHBsaWNhdGlvbiBnZW5lcmF0ZXMgbmV3IGNvbmZpZ3VyYXRpb24gdmFsdWVzLCB0 aGUgYWN0dWFsIGluc3RhbnRpYXRpb25zIG9mIGRldmljZXMgbWF5IHJldXNlIHRoZSBmdW5jdG9y IGFwcGxpY2F0aW9uIHdpdGggZGlmZmVyZW50IHN0YXRlIHZhcmlhYmxlcy4KPj4+Pgo+Pj4+IEZv ciBpbnN0YW5jZSwgcmlnaHQgbm93IGlmIHdlIGdlbmVyYXRlIGEgSFRUUCBjbGllbnQsIHdlIG5l ZWQgdGhpcyBpbiBvdXIgY29uZmlnLm1sOgo+Pj4+Cj4+Pj4gbGV0IHN2NCA9IHN0YWNrIGRlZmF1 bHRfY29uc29sZSBpbgo+Pj4+IGxldCByZXNfZG5zID0gcmVzb2x2ZXJfZG5zIHN2NCBpbgo+Pj4+ IGxldCBjb25kdWl0ID0gY29uZHVpdF9kaXJlY3Qgc3Y0IGluCj4+Pj4KPj4+PiBUaGUgc3RhY2sg KHN2NCkgaXMgaW5zdGFudGlhdGVkIGFzIG9uZSBmdW5jdG9yLCBidXQgaXMgY3VycmVudGx5IGNv bm5lY3QoKSdlZCB0d2ljZS4gIFRoZSBvYnNlcnZhYmxlIGJ1ZyBpcyB0aGF0IGl0IGlzc3VlcyBh IERIQ1AgcXVlcnkgZm9yIGV2ZXJ5IHRpbWUgaXQgaXMgY2FsbGVkLgo+Pj4+Cj4+Pj4gRmlsbGlu ZyB0aGlzIGF0IGZpcnN0IGdsYW5jZSByZXF1aXJlcyBpbnN0YW50aWF0aW9ucyB0byBiZSBsYXp5 LCBzbyB0aGF0IHdlIHJldXNlIHRoZW0uICBIb3dldmVyLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRv IGV4cGxpY2l0bHkgbmFtZSBkZXZpY2VzIHNvIHRoYXQgd2UgY2FuIHNhZmVseSBtZW1vaXNlIG11 bHRpcGxlIHN0YWNrcyB0aGF0IHNoYXJlIHRoZSBzYW1lIGZ1bmN0b3IgYnV0IG90aGVyd2lzZSBk aWZmZXIgaW4gdGhlaXIgc3RhdGUgKGUuZy4gdHdvIGNvbXBsZXRlbHkgc2VwYXJhdGUgc3RhY2tz IHRoYXQgaXNzdWUgdGhlaXIgb3duIERIQ1AgcmVxdWVzdHMgd2l0aCB0aGVpciBvd24gTUFDIGFk ZHJlc3NlcywgYnV0IG90aGVyd2lzZSBzaGFyZSB0aGUgc2FtZSBPQ2FtbCBUQ1AvSVAgZnVuY3Rv cnMpLgo+Pj4+Cj4+Pj4gKHNlZSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFnZS9pc3N1 ZXMvMzMxIGZvciBtb3JlKQo+Pj4KPj4+IEFuIGFkZGVuZHVtIHRvIHRoaXMgaXMgdGhhdCB3ZSBk b24ndCB3YW50IHRvIGFsd2F5cyBtYWtlIGV2ZXJ5IGRldmljZSB1c2UgbGF6eSBhbmQgc2hhcmVk IGJ5IGRlZmF1bHQuCj4+Pgo+Pj4gSW4gdGhlIGV4YW1wbGUgYWJvdmUsIGl0IGlzIHBlcmZlY3Rs eSBzZW5zaWJsZSB0byB3YW50IHRvIGhhdmUgb25lIElQIHN0YWNrIGZvciB0aGUgcHVycG9zZXMg b2YgRE5TIHJlc29sdXRpb24gb25seSwgYW5kIGFub3RoZXIgZm9yIHRoZSBwdXJwb3NlcyBvZiBv cGVuaW5nIG5ldHdvcmsgY29ubmVjdGlvbnMgZm9yIGRhdGEgdHJhbnNmZXIuICBUaGF0J3MgZGlm ZmljdWx0IHRvIHNldHVwIG9uIG1vc3Qgc3lzdGVtcyB0b2RheSwgYnV0IHNob3VsZCBiZSBwb3Nz aWJsZSB0byBhc3NlbWJsZSB3aXRoIE1pcmFnZS4KPj4+Cj4+PiAtYW5pbAo+CgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWls aW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 16:12:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 16:12:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZ1P-00073V-Qx; Thu, 04 Dec 2014 16:12:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZ1O-00073P-3c for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:12:50 +0000 Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id B9/01-11581-10880845; Thu, 04 Dec 2014 16:12:49 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-4.tower-206.messagelabs.com!1417709568!11617255!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5593 invoked from network); 4 Dec 2014 16:12:48 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-4.tower-206.messagelabs.com with SMTP; 4 Dec 2014 16:12:48 -0000 Received: from [172.20.10.2] (24-224.197-178.cust.bluewin.ch [178.197.224.24]) by smtp.webfaction.com (Postfix) with ESMTP id BBFAF20792AA; Thu, 4 Dec 2014 16:12:46 +0000 (UTC) Date: Thu, 4 Dec 2014 17:12:48 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Gazagnaire Message-ID: <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> In-Reply-To: <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Nicolas Ojeda Bar , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgamV1ZGksIDQgZMOpY2VtYnJlIDIwMTQgw6AgMTY6MDIsIFRob21hcyBHYXphZ25haXJlIGEg w6ljcml0IDoKPiBJIGFtIG5vdCB2ZXJ5IGZvbmQgb2YgdGhlIGRlZmF1bHQgcmVmZXJlbmNlcywg bm90IHN1cmUgd2h5IHlvdSB3YW50IHNvbWVvbmUgdG8gY2hhbmdlIHRoZW0gZ2xvYmFsbHkuCgpT YW1lIHJlYWN0aW9uLCBjaGFuZ2luZyBkZWZhdWx0cyBieSBzaWRlIGVmZmVjdHMgaXMgYSByZWNp cGUgZm9yIGNyYXp5IGRlYnVnZ2luZyBzZXNzaW9ucy4gQWx3YXlzIGFzc3VtZSB1c2VycyB3aWxs IGFidXNlIHdoYXQgeW91IHB1dCBpbiB0aGVpciBoYW5kczsgc28gbWluaW1pemUgdGhlIGV4cG9z aXRpb24gb2YgKHVuZWNlc3NhcnkpIHNpZGUtZWZmZWN0cy4KCk90aGVyIHRoaW5nczoKCjEpIFlv dSBuZWVkIHRvIHRlbGwgdXMgc29tZXRoaW5nIGFib3V0IHNvbWUgbm90aW9uIG9mIGlkZW50aXR5 IGZvciB0aGUgcGFyYW1ldGVycy4gSG93IGlzIGl0IGRlZmluZWQKaXMgaXQgdGhlIG5hbWUgPyBX aGF0IGhhcHBlbnMgaWYgSSBkZWNsYXJlIHR3byBwYXJhbWV0ZXJzIHdpdGggdGhlIHNhbWUgbmFt ZSBbMV0gPyAgCgoyKSBJbiB0aGUgbWFucGFnZSBJIHdvdWxkIGxpc3QgdGhlIHBhcmFtZXRlcnMg dW5kZXIgYSBkaWZmZXJlbnQgc2VjdGlvbiAoZS5nLiBvbmUgY2FsbGVkIFVOSUtFUk5FTCBQQVJB TUVURVJTKS4KCjMpIEkgd291bGQgcHJlZml4IG9yIHN1ZmZpeCB0aGUgY29tbWFuZCBsaW5lIG9w dGlvbiBuYW1lIHdpdGggYSBjb25zdGFudCwgdGhpcyBlbnN1cmVzIHRoYXQgdW5pa2VybmVsIGRl dmVsb3BlcnMgd2lsbCBuZXZlciBjbGFzaCB3aXRoIG9wdGlvbnMgb2YgdGhlIG1pcmFnZSB0b29s LiBTbyBmb3IgYSBwYXJhbWV0ZXJzIG5hbWVkICJhZGRyZXNzIiB0aGUgb3B0aW9uIG5hbWVzIHNo b3VsZCBiZSAgYC0tYWRkcmVzcy1wYXJhbWAgb3IgYC0tcGFyYW0tYWRkcmVzc2AgIAoKNCkgSXMg dGhlIG5vIFtkZWZdIHdpdGggW2R5bl0gdW5zcGVjaWZpZWQgb3B0aW9uIHJ1bnRpbWUgZXJyb3Ig YSBmZWF0dXJlID8gSWYgbm90IGl0J3MgZWFzeSB0byBlbnN1cmUgc3RhdGljYWxseSB5b3UgYWx3 YXlzIGhhdmUgYSB2YWx1ZSB0byB1c2UuIEFyZSB5b3UgdXNpbmcgY21kbGluZXIncyByZXF1aXJl ZCBvcHRpb25hbCBhcmd1bWVudHMgZm9yIHRoYXQgKGl0IHNlZW1zIGEgbGVnaXRpbWF0ZSB1c2Ug Zm9yIG9uY2UsIGFzIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBtYWtlIHBvc2l0aW9uYWwgYXJn dW1lbnRzIGluIGEgY29tcG9zaXRpb25hbCBtYW5uZXIpID8gIAoKQmVzdCwKCkRhbmllbAoKUC5T LiBSYXRoZXIgdGhhbiBjb25maWd1cmF0aW9uIFBhcmFtIEkgd291bGQgdXNlIGNvbmZpZ3VyYXRp b24gS2V5IHdoaWNoIGlzIHNob3J0ZXIgYW5kIGEgZnVsbCB3b3JkLCBidXQgbmFtaW5nIGlzIHN1 YmplY3RpdmUuCgoKWzFdICBUaGF0J3M6CgpodHRwczovL2dpdGh1Yi5jb20vc2Ftb2h0L2Fzc2Vt YmxhZ2UvYmxvYi83NTdiMzZjNmI4ODBiM2E4NmI2MTc3Mjc3ZTJhNjY1NTViZmI3YWYyL2xpYi9h c3NlbWJsYWdlLm1saSNMMTA5MS1MMTA5NgoKd2hhdCBhc3NlbWJsYWdlIHNheXMgb24gdGhlIHRv cGljLiBCYXNpY2FsbHkgd2UgaGF2ZSB1aWQgaW50ZXJuYWxseSBzbyB3ZSBkb24ndCBkaXNjcmlt aW5hdGUgb24gdGhlIG5hbWUuIEhvd2V2ZXIgdGhhdCB3YXJuaW5nIGluIHRoZSBkb2N1bWVudGF0 aW9uIGlzIG92ZXIgcGVzc2ltaXN0aWMuIEluIGZhY3QgaWYgSSBnZXQgdHdvIGNvbmZpZ3VyYXRp b24ga2V5cyB3aXRoIHRoZSBzYW1lIG5hbWUgSSBlbWl0IGEgd2FybmluZyBhbmQgZ2VuZXJhdGUg YW4gYWx0ZXJuYXRlIG5hbWUgZm9yIHRoZSBvcHRpb24gb24gdGhlIGNvbW1hbmQgbGluZSAoZS5n LiAtLWR1cG5hbWV+MS1rZXkpLiBTZWUgaGVyZToKCmh0dHBzOi8vZ2l0aHViLmNvbS9zYW1vaHQv YXNzZW1ibGFnZS9ibG9iLzc1N2IzNmM2Yjg4MGIzYTg2YjYxNzcyNzdlMmE2NjU1NWJmYjdhZjIv bGliLWRyaXZlci9hc3NlbWJsYWdlX2RyaXZlci5tbCNMNDItTDUzCgoKCgoKCgogYnV0IGlmIHlv dSBoYXZlIHR3byBjb25maWd1cmF0aW9uIHdpdGggdGhlIHNhbWUgbmFtZSwgIEkgdGhpbmsgdGhh dCBpbiBhc3NlbWJsYWdlIHRoaXMgaXMgbm90IGEgcmVhbCBwcm9ibGVtICh1bmxlc3MgeW91IGxv YWQgbW9yZSB0aGFuIG9uZSBwcm9qZWN0KQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9j Z2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 16:12:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 16:12:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZ1P-00073V-Qx; Thu, 04 Dec 2014 16:12:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZ1O-00073P-3c for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:12:50 +0000 Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id B9/01-11581-10880845; Thu, 04 Dec 2014 16:12:49 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-4.tower-206.messagelabs.com!1417709568!11617255!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5593 invoked from network); 4 Dec 2014 16:12:48 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-4.tower-206.messagelabs.com with SMTP; 4 Dec 2014 16:12:48 -0000 Received: from [172.20.10.2] (24-224.197-178.cust.bluewin.ch [178.197.224.24]) by smtp.webfaction.com (Postfix) with ESMTP id BBFAF20792AA; Thu, 4 Dec 2014 16:12:46 +0000 (UTC) Date: Thu, 4 Dec 2014 17:12:48 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Gazagnaire Message-ID: <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> In-Reply-To: <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Nicolas Ojeda Bar , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgamV1ZGksIDQgZMOpY2VtYnJlIDIwMTQgw6AgMTY6MDIsIFRob21hcyBHYXphZ25haXJlIGEg w6ljcml0IDoKPiBJIGFtIG5vdCB2ZXJ5IGZvbmQgb2YgdGhlIGRlZmF1bHQgcmVmZXJlbmNlcywg bm90IHN1cmUgd2h5IHlvdSB3YW50IHNvbWVvbmUgdG8gY2hhbmdlIHRoZW0gZ2xvYmFsbHkuCgpT YW1lIHJlYWN0aW9uLCBjaGFuZ2luZyBkZWZhdWx0cyBieSBzaWRlIGVmZmVjdHMgaXMgYSByZWNp cGUgZm9yIGNyYXp5IGRlYnVnZ2luZyBzZXNzaW9ucy4gQWx3YXlzIGFzc3VtZSB1c2VycyB3aWxs IGFidXNlIHdoYXQgeW91IHB1dCBpbiB0aGVpciBoYW5kczsgc28gbWluaW1pemUgdGhlIGV4cG9z aXRpb24gb2YgKHVuZWNlc3NhcnkpIHNpZGUtZWZmZWN0cy4KCk90aGVyIHRoaW5nczoKCjEpIFlv dSBuZWVkIHRvIHRlbGwgdXMgc29tZXRoaW5nIGFib3V0IHNvbWUgbm90aW9uIG9mIGlkZW50aXR5 IGZvciB0aGUgcGFyYW1ldGVycy4gSG93IGlzIGl0IGRlZmluZWQKaXMgaXQgdGhlIG5hbWUgPyBX aGF0IGhhcHBlbnMgaWYgSSBkZWNsYXJlIHR3byBwYXJhbWV0ZXJzIHdpdGggdGhlIHNhbWUgbmFt ZSBbMV0gPyAgCgoyKSBJbiB0aGUgbWFucGFnZSBJIHdvdWxkIGxpc3QgdGhlIHBhcmFtZXRlcnMg dW5kZXIgYSBkaWZmZXJlbnQgc2VjdGlvbiAoZS5nLiBvbmUgY2FsbGVkIFVOSUtFUk5FTCBQQVJB TUVURVJTKS4KCjMpIEkgd291bGQgcHJlZml4IG9yIHN1ZmZpeCB0aGUgY29tbWFuZCBsaW5lIG9w dGlvbiBuYW1lIHdpdGggYSBjb25zdGFudCwgdGhpcyBlbnN1cmVzIHRoYXQgdW5pa2VybmVsIGRl dmVsb3BlcnMgd2lsbCBuZXZlciBjbGFzaCB3aXRoIG9wdGlvbnMgb2YgdGhlIG1pcmFnZSB0b29s LiBTbyBmb3IgYSBwYXJhbWV0ZXJzIG5hbWVkICJhZGRyZXNzIiB0aGUgb3B0aW9uIG5hbWVzIHNo b3VsZCBiZSAgYC0tYWRkcmVzcy1wYXJhbWAgb3IgYC0tcGFyYW0tYWRkcmVzc2AgIAoKNCkgSXMg dGhlIG5vIFtkZWZdIHdpdGggW2R5bl0gdW5zcGVjaWZpZWQgb3B0aW9uIHJ1bnRpbWUgZXJyb3Ig YSBmZWF0dXJlID8gSWYgbm90IGl0J3MgZWFzeSB0byBlbnN1cmUgc3RhdGljYWxseSB5b3UgYWx3 YXlzIGhhdmUgYSB2YWx1ZSB0byB1c2UuIEFyZSB5b3UgdXNpbmcgY21kbGluZXIncyByZXF1aXJl ZCBvcHRpb25hbCBhcmd1bWVudHMgZm9yIHRoYXQgKGl0IHNlZW1zIGEgbGVnaXRpbWF0ZSB1c2Ug Zm9yIG9uY2UsIGFzIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBtYWtlIHBvc2l0aW9uYWwgYXJn dW1lbnRzIGluIGEgY29tcG9zaXRpb25hbCBtYW5uZXIpID8gIAoKQmVzdCwKCkRhbmllbAoKUC5T LiBSYXRoZXIgdGhhbiBjb25maWd1cmF0aW9uIFBhcmFtIEkgd291bGQgdXNlIGNvbmZpZ3VyYXRp b24gS2V5IHdoaWNoIGlzIHNob3J0ZXIgYW5kIGEgZnVsbCB3b3JkLCBidXQgbmFtaW5nIGlzIHN1 YmplY3RpdmUuCgoKWzFdICBUaGF0J3M6CgpodHRwczovL2dpdGh1Yi5jb20vc2Ftb2h0L2Fzc2Vt YmxhZ2UvYmxvYi83NTdiMzZjNmI4ODBiM2E4NmI2MTc3Mjc3ZTJhNjY1NTViZmI3YWYyL2xpYi9h c3NlbWJsYWdlLm1saSNMMTA5MS1MMTA5NgoKd2hhdCBhc3NlbWJsYWdlIHNheXMgb24gdGhlIHRv cGljLiBCYXNpY2FsbHkgd2UgaGF2ZSB1aWQgaW50ZXJuYWxseSBzbyB3ZSBkb24ndCBkaXNjcmlt aW5hdGUgb24gdGhlIG5hbWUuIEhvd2V2ZXIgdGhhdCB3YXJuaW5nIGluIHRoZSBkb2N1bWVudGF0 aW9uIGlzIG92ZXIgcGVzc2ltaXN0aWMuIEluIGZhY3QgaWYgSSBnZXQgdHdvIGNvbmZpZ3VyYXRp b24ga2V5cyB3aXRoIHRoZSBzYW1lIG5hbWUgSSBlbWl0IGEgd2FybmluZyBhbmQgZ2VuZXJhdGUg YW4gYWx0ZXJuYXRlIG5hbWUgZm9yIHRoZSBvcHRpb24gb24gdGhlIGNvbW1hbmQgbGluZSAoZS5n LiAtLWR1cG5hbWV+MS1rZXkpLiBTZWUgaGVyZToKCmh0dHBzOi8vZ2l0aHViLmNvbS9zYW1vaHQv YXNzZW1ibGFnZS9ibG9iLzc1N2IzNmM2Yjg4MGIzYTg2YjYxNzcyNzdlMmE2NjU1NWJmYjdhZjIv bGliLWRyaXZlci9hc3NlbWJsYWdlX2RyaXZlci5tbCNMNDItTDUzCgoKCgoKCgogYnV0IGlmIHlv dSBoYXZlIHR3byBjb25maWd1cmF0aW9uIHdpdGggdGhlIHNhbWUgbmFtZSwgIEkgdGhpbmsgdGhh dCBpbiBhc3NlbWJsYWdlIHRoaXMgaXMgbm90IGEgcmVhbCBwcm9ibGVtICh1bmxlc3MgeW91IGxv YWQgbW9yZSB0aGFuIG9uZSBwcm9qZWN0KQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9j Z2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 16:37:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 16:37:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZP2-0000Zq-Vt; Thu, 04 Dec 2014 16:37:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZP2-0000Ze-9A for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:37:16 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 20/F1-27584-BBD80845; Thu, 04 Dec 2014 16:37:15 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1417711034!11622852!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17591 invoked from network); 4 Dec 2014 16:37:14 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 16:37:14 -0000 Received: by mail-wg0-f43.google.com with SMTP id l18so23010824wgh.30 for ; Thu, 04 Dec 2014 08:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bHreik9UODZy8VxlQERZ6cR4VSugIyGmmE+MPqqowzQ=; b=OMfhA3/Il0hDRNWzDW8PeHHoJ3I2IqSV7r8HPePg6N5GA19cf3ZrDJwzqdWK2k+ds3 4iXpUm5lmjOLmZHbKJyeYi7ICrfsSnsuUPRo9D5U9NnWeTIhBFUEqC+sHtaA8c6j3yFX FmQOx8eKMCHG1CnS4AO2xBfddpghMiBsMG2OZ68ilfzmCg6xNJ18IzQYQq0YvQbLI06Q 1fQ4P3ppG19Wjpvay9hRMQtV/lhl3+fkrlnScEcTYXXo2dbbPuujs4JDdVpRCE5EMM5D 5Xve5RC0Lva4mzrAUSVS6SgxzIVnSgGo2OlymYlH+XO+Dsk5x/NPb2s+G/ooTi0FJTKG xKoQ== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr23255217wic.57.1417711034553; Thu, 04 Dec 2014 08:37:14 -0800 (PST) Received: by 10.27.171.146 with HTTP; Thu, 4 Dec 2014 08:37:14 -0800 (PST) In-Reply-To: <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> Date: Thu, 4 Dec 2014 16:37:14 +0000 X-Google-Sender-Auth: QiZSExEJ0mNC4O_zXh1VdvUEaPs Message-ID: From: Nicolas Ojeda Bar To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIGNvbW1lbnRzLiBJIGFtIHJlc3BvbmRp bmcgaW5saW5lCmJlbG93LiBJIHdpbGwgYWxzbyBiZSB1cGRhdGluZyB0aGUgZG9jdW1lbnQgYW5k IHRoZSBjb2RlIHNvb24gdG8KcmVmbGVjdCB0aGUgbmV3IHN1Z2dlc3Rpb25zLgoKT24gVGh1LCBE ZWMgNCwgMjAxNCBhdCA0OjEyIFBNLCBEYW5pZWwgQsO8bnpsaQo8ZGFuaWVsLmJ1ZW56bGlAZXJy YXRpcXVlLmNoPiB3cm90ZToKPiBMZSBqZXVkaSwgNCBkw6ljZW1icmUgMjAxNCDDoCAxNjowMiwg VGhvbWFzIEdhemFnbmFpcmUgYSDDqWNyaXQgOgo+PiBJIGFtIG5vdCB2ZXJ5IGZvbmQgb2YgdGhl IGRlZmF1bHQgcmVmZXJlbmNlcywgbm90IHN1cmUgd2h5IHlvdSB3YW50IHNvbWVvbmUgdG8gY2hh bmdlIHRoZW0gZ2xvYmFsbHkuCj4KPiBTYW1lIHJlYWN0aW9uLCBjaGFuZ2luZyBkZWZhdWx0cyBi eSBzaWRlIGVmZmVjdHMgaXMgYSByZWNpcGUgZm9yIGNyYXp5IGRlYnVnZ2luZyBzZXNzaW9ucy4g QWx3YXlzIGFzc3VtZSB1c2VycyB3aWxsIGFidXNlIHdoYXQgeW91IHB1dCBpbiB0aGVpciBoYW5k czsgc28gbWluaW1pemUgdGhlIGV4cG9zaXRpb24gb2YgKHVuZWNlc3NhcnkpIHNpZGUtZWZmZWN0 cy4KCkFncmVlZC4gIFRoaXMgaXMgZ29pbmcgYXdheS4KCj4gT3RoZXIgdGhpbmdzOgo+Cj4gMSkg WW91IG5lZWQgdG8gdGVsbCB1cyBzb21ldGhpbmcgYWJvdXQgc29tZSBub3Rpb24gb2YgaWRlbnRp dHkgZm9yIHRoZSBwYXJhbWV0ZXJzLiBIb3cgaXMgaXQgZGVmaW5lZAo+IGlzIGl0IHRoZSBuYW1l ID8gV2hhdCBoYXBwZW5zIGlmIEkgZGVjbGFyZSB0d28gcGFyYW1ldGVycyB3aXRoIHRoZSBzYW1l IG5hbWUgWzFdID8KClJpZ2h0IG5vdyB0aGV5IGFyZSBkZWZpbmVkIGJ5IHRoZWlyIG5hbWUsIGFu ZCBpdCBpcyBhIGZhdGFsIGVycm9yIGlmCnlvdSB1c2UgdHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJz IHdpdGggdGhlIHNhbWUgbmFtZS4gIEJ1dCBJIGxpa2UgdGhlCmlkZWEgb2YKZW1pdHRpbmcgYSB3 YXJuaW5nIGFuZCByZW5hbWluZyB0aGUgcGFyYW1ldGVyIGlmIHRoZXJlIGlzIGEgY2xhc2guCgo+ IDIpIEluIHRoZSBtYW5wYWdlIEkgd291bGQgbGlzdCB0aGUgcGFyYW1ldGVycyB1bmRlciBhIGRp ZmZlcmVudCBzZWN0aW9uIChlLmcuIG9uZSBjYWxsZWQgVU5JS0VSTkVMIFBBUkFNRVRFUlMpLgoK R29vZCBpZGVhLiAgSSBoYWQgZm9yZ290dGVuIGFib3V0IHRoaXMgZmVhdHVyZSBvZiBgQ21kbGlu ZXJgLgoKPiAzKSBJIHdvdWxkIHByZWZpeCBvciBzdWZmaXggdGhlIGNvbW1hbmQgbGluZSBvcHRp b24gbmFtZSB3aXRoIGEgY29uc3RhbnQsIHRoaXMgZW5zdXJlcyB0aGF0IHVuaWtlcm5lbCBkZXZl bG9wZXJzIHdpbGwgbmV2ZXIgY2xhc2ggd2l0aCBvcHRpb25zIG9mIHRoZSBtaXJhZ2UgdG9vbC4g U28gZm9yIGEgcGFyYW1ldGVycyBuYW1lZCAiYWRkcmVzcyIgdGhlIG9wdGlvbiBuYW1lcyBzaG91 bGQgYmUgIGAtLWFkZHJlc3MtcGFyYW1gIG9yIGAtLXBhcmFtLWFkZHJlc3NgCgpBZ2FpbiwgSSB0 aGluayBpdCBpcyBhbiBleGNlbGxlbnQgaWRlYS4KCj4gNCkgSXMgdGhlIG5vIFtkZWZdIHdpdGgg W2R5bl0gdW5zcGVjaWZpZWQgb3B0aW9uIHJ1bnRpbWUgZXJyb3IgYSBmZWF0dXJlID8gSWYgbm90 IGl0J3MgZWFzeSB0byBlbnN1cmUgc3RhdGljYWxseSB5b3UgYWx3YXlzIGhhdmUgYSB2YWx1ZSB0 byB1c2UuIEFyZSB5b3UgdXNpbmcgY21kbGluZXIncyByZXF1aXJlZCBvcHRpb25hbCBhcmd1bWVu dHMgZm9yIHRoYXQgKGl0IHNlZW1zIGEgbGVnaXRpbWF0ZSB1c2UgZm9yIG9uY2UsIGFzIGl0IHdv dWxkIGJlIGRpZmZpY3VsdCB0byBtYWtlIHBvc2l0aW9uYWwgYXJndW1lbnRzIGluIGEgY29tcG9z aXRpb25hbCBtYW5uZXIpID8KCkkgd2FzIHRvbGQgb2YgYXQgbGVhc3Qgb25lIHVzZS1jYXNlIHdo ZXJlIGl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIHRvCnJlcXVpcmUgYSBkZWZhdWx0IHZhbHVlIGZv ciBhbiBhcmd1bWVudCB0aGF0IGlzIG1lYW50IHRvIGJlIHNldCBhdApydW4tdGltZSwgc28gSSB3 b3VsZCBsaWtlIHRvIHN1cHBvcnQgdGhpcyBhcyB3ZWxsLgoKQW5kIHllcywgcmlnaHQgbm93IEkg YW0gdXNpbmcgQ21kbGluZXIncyByZXF1aXJlZCBvcHRpb25hbCBhcmd1bWVudHMKZm9yIHRoaXMg ZmVhdHVyZS4KCj4gQmVzdCwKPgo+IERhbmllbAo+Cj4gUC5TLiBSYXRoZXIgdGhhbiBjb25maWd1 cmF0aW9uIFBhcmFtIEkgd291bGQgdXNlIGNvbmZpZ3VyYXRpb24gS2V5IHdoaWNoIGlzIHNob3J0 ZXIgYW5kIGEgZnVsbCB3b3JkLCBidXQgbmFtaW5nIGlzIHN1YmplY3RpdmUuCgpBZ3JlZWQsIHNv dW5kcyBhbmQgbG9va3MgYmV0dGVyIGFzIHdlbGwuCgpUaGFua3MhCgpCZXN0IHdpc2hlcywKTmlj b2xhcwoKPgo+IFsxXSAgVGhhdCdzOgo+Cj4gaHR0cHM6Ly9naXRodWIuY29tL3NhbW9odC9hc3Nl bWJsYWdlL2Jsb2IvNzU3YjM2YzZiODgwYjNhODZiNjE3NzI3N2UyYTY2NTU1YmZiN2FmMi9saWIv YXNzZW1ibGFnZS5tbGkjTDEwOTEtTDEwOTYKPgo+IHdoYXQgYXNzZW1ibGFnZSBzYXlzIG9uIHRo ZSB0b3BpYy4gQmFzaWNhbGx5IHdlIGhhdmUgdWlkIGludGVybmFsbHkgc28gd2UgZG9uJ3QgZGlz Y3JpbWluYXRlIG9uIHRoZSBuYW1lLiBIb3dldmVyIHRoYXQgd2FybmluZyBpbiB0aGUgZG9jdW1l bnRhdGlvbiBpcyBvdmVyIHBlc3NpbWlzdGljLiBJbiBmYWN0IGlmIEkgZ2V0IHR3byBjb25maWd1 cmF0aW9uIGtleXMgd2l0aCB0aGUgc2FtZSBuYW1lIEkgZW1pdCBhIHdhcm5pbmcgYW5kIGdlbmVy YXRlIGFuIGFsdGVybmF0ZSBuYW1lIGZvciB0aGUgb3B0aW9uIG9uIHRoZSBjb21tYW5kIGxpbmUg KGUuZy4gLS1kdXBuYW1lfjEta2V5KS4gU2VlIGhlcmU6Cj4KPiBodHRwczovL2dpdGh1Yi5jb20v c2Ftb2h0L2Fzc2VtYmxhZ2UvYmxvYi83NTdiMzZjNmI4ODBiM2E4NmI2MTc3Mjc3ZTJhNjY1NTVi ZmI3YWYyL2xpYi1kcml2ZXIvYXNzZW1ibGFnZV9kcml2ZXIubWwjTDQyLUw1Mwo+Cj4KPgo+Cj4K Pgo+Cj4gIGJ1dCBpZiB5b3UgaGF2ZSB0d28gY29uZmlndXJhdGlvbiB3aXRoIHRoZSBzYW1lIG5h bWUsICBJIHRoaW5rIHRoYXQgaW4gYXNzZW1ibGFnZSB0aGlzIGlzIG5vdCBhIHJlYWwgcHJvYmxl bSAodW5sZXNzIHlvdSBsb2FkIG1vcmUgdGhhbiBvbmUgcHJvamVjdCkKPgo+Cj4KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1h aWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlz dHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVs Cg== From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 16:37:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 16:37:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZP2-0000Zq-Vt; Thu, 04 Dec 2014 16:37:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZP2-0000Ze-9A for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 16:37:16 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 20/F1-27584-BBD80845; Thu, 04 Dec 2014 16:37:15 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1417711034!11622852!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17591 invoked from network); 4 Dec 2014 16:37:14 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Dec 2014 16:37:14 -0000 Received: by mail-wg0-f43.google.com with SMTP id l18so23010824wgh.30 for ; Thu, 04 Dec 2014 08:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bHreik9UODZy8VxlQERZ6cR4VSugIyGmmE+MPqqowzQ=; b=OMfhA3/Il0hDRNWzDW8PeHHoJ3I2IqSV7r8HPePg6N5GA19cf3ZrDJwzqdWK2k+ds3 4iXpUm5lmjOLmZHbKJyeYi7ICrfsSnsuUPRo9D5U9NnWeTIhBFUEqC+sHtaA8c6j3yFX FmQOx8eKMCHG1CnS4AO2xBfddpghMiBsMG2OZ68ilfzmCg6xNJ18IzQYQq0YvQbLI06Q 1fQ4P3ppG19Wjpvay9hRMQtV/lhl3+fkrlnScEcTYXXo2dbbPuujs4JDdVpRCE5EMM5D 5Xve5RC0Lva4mzrAUSVS6SgxzIVnSgGo2OlymYlH+XO+Dsk5x/NPb2s+G/ooTi0FJTKG xKoQ== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr23255217wic.57.1417711034553; Thu, 04 Dec 2014 08:37:14 -0800 (PST) Received: by 10.27.171.146 with HTTP; Thu, 4 Dec 2014 08:37:14 -0800 (PST) In-Reply-To: <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> Date: Thu, 4 Dec 2014 16:37:14 +0000 X-Google-Sender-Auth: QiZSExEJ0mNC4O_zXh1VdvUEaPs Message-ID: From: Nicolas Ojeda Bar To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIGNvbW1lbnRzLiBJIGFtIHJlc3BvbmRp bmcgaW5saW5lCmJlbG93LiBJIHdpbGwgYWxzbyBiZSB1cGRhdGluZyB0aGUgZG9jdW1lbnQgYW5k IHRoZSBjb2RlIHNvb24gdG8KcmVmbGVjdCB0aGUgbmV3IHN1Z2dlc3Rpb25zLgoKT24gVGh1LCBE ZWMgNCwgMjAxNCBhdCA0OjEyIFBNLCBEYW5pZWwgQsO8bnpsaQo8ZGFuaWVsLmJ1ZW56bGlAZXJy YXRpcXVlLmNoPiB3cm90ZToKPiBMZSBqZXVkaSwgNCBkw6ljZW1icmUgMjAxNCDDoCAxNjowMiwg VGhvbWFzIEdhemFnbmFpcmUgYSDDqWNyaXQgOgo+PiBJIGFtIG5vdCB2ZXJ5IGZvbmQgb2YgdGhl IGRlZmF1bHQgcmVmZXJlbmNlcywgbm90IHN1cmUgd2h5IHlvdSB3YW50IHNvbWVvbmUgdG8gY2hh bmdlIHRoZW0gZ2xvYmFsbHkuCj4KPiBTYW1lIHJlYWN0aW9uLCBjaGFuZ2luZyBkZWZhdWx0cyBi eSBzaWRlIGVmZmVjdHMgaXMgYSByZWNpcGUgZm9yIGNyYXp5IGRlYnVnZ2luZyBzZXNzaW9ucy4g QWx3YXlzIGFzc3VtZSB1c2VycyB3aWxsIGFidXNlIHdoYXQgeW91IHB1dCBpbiB0aGVpciBoYW5k czsgc28gbWluaW1pemUgdGhlIGV4cG9zaXRpb24gb2YgKHVuZWNlc3NhcnkpIHNpZGUtZWZmZWN0 cy4KCkFncmVlZC4gIFRoaXMgaXMgZ29pbmcgYXdheS4KCj4gT3RoZXIgdGhpbmdzOgo+Cj4gMSkg WW91IG5lZWQgdG8gdGVsbCB1cyBzb21ldGhpbmcgYWJvdXQgc29tZSBub3Rpb24gb2YgaWRlbnRp dHkgZm9yIHRoZSBwYXJhbWV0ZXJzLiBIb3cgaXMgaXQgZGVmaW5lZAo+IGlzIGl0IHRoZSBuYW1l ID8gV2hhdCBoYXBwZW5zIGlmIEkgZGVjbGFyZSB0d28gcGFyYW1ldGVycyB3aXRoIHRoZSBzYW1l IG5hbWUgWzFdID8KClJpZ2h0IG5vdyB0aGV5IGFyZSBkZWZpbmVkIGJ5IHRoZWlyIG5hbWUsIGFu ZCBpdCBpcyBhIGZhdGFsIGVycm9yIGlmCnlvdSB1c2UgdHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJz IHdpdGggdGhlIHNhbWUgbmFtZS4gIEJ1dCBJIGxpa2UgdGhlCmlkZWEgb2YKZW1pdHRpbmcgYSB3 YXJuaW5nIGFuZCByZW5hbWluZyB0aGUgcGFyYW1ldGVyIGlmIHRoZXJlIGlzIGEgY2xhc2guCgo+ IDIpIEluIHRoZSBtYW5wYWdlIEkgd291bGQgbGlzdCB0aGUgcGFyYW1ldGVycyB1bmRlciBhIGRp ZmZlcmVudCBzZWN0aW9uIChlLmcuIG9uZSBjYWxsZWQgVU5JS0VSTkVMIFBBUkFNRVRFUlMpLgoK R29vZCBpZGVhLiAgSSBoYWQgZm9yZ290dGVuIGFib3V0IHRoaXMgZmVhdHVyZSBvZiBgQ21kbGlu ZXJgLgoKPiAzKSBJIHdvdWxkIHByZWZpeCBvciBzdWZmaXggdGhlIGNvbW1hbmQgbGluZSBvcHRp b24gbmFtZSB3aXRoIGEgY29uc3RhbnQsIHRoaXMgZW5zdXJlcyB0aGF0IHVuaWtlcm5lbCBkZXZl bG9wZXJzIHdpbGwgbmV2ZXIgY2xhc2ggd2l0aCBvcHRpb25zIG9mIHRoZSBtaXJhZ2UgdG9vbC4g U28gZm9yIGEgcGFyYW1ldGVycyBuYW1lZCAiYWRkcmVzcyIgdGhlIG9wdGlvbiBuYW1lcyBzaG91 bGQgYmUgIGAtLWFkZHJlc3MtcGFyYW1gIG9yIGAtLXBhcmFtLWFkZHJlc3NgCgpBZ2FpbiwgSSB0 aGluayBpdCBpcyBhbiBleGNlbGxlbnQgaWRlYS4KCj4gNCkgSXMgdGhlIG5vIFtkZWZdIHdpdGgg W2R5bl0gdW5zcGVjaWZpZWQgb3B0aW9uIHJ1bnRpbWUgZXJyb3IgYSBmZWF0dXJlID8gSWYgbm90 IGl0J3MgZWFzeSB0byBlbnN1cmUgc3RhdGljYWxseSB5b3UgYWx3YXlzIGhhdmUgYSB2YWx1ZSB0 byB1c2UuIEFyZSB5b3UgdXNpbmcgY21kbGluZXIncyByZXF1aXJlZCBvcHRpb25hbCBhcmd1bWVu dHMgZm9yIHRoYXQgKGl0IHNlZW1zIGEgbGVnaXRpbWF0ZSB1c2UgZm9yIG9uY2UsIGFzIGl0IHdv dWxkIGJlIGRpZmZpY3VsdCB0byBtYWtlIHBvc2l0aW9uYWwgYXJndW1lbnRzIGluIGEgY29tcG9z aXRpb25hbCBtYW5uZXIpID8KCkkgd2FzIHRvbGQgb2YgYXQgbGVhc3Qgb25lIHVzZS1jYXNlIHdo ZXJlIGl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIHRvCnJlcXVpcmUgYSBkZWZhdWx0IHZhbHVlIGZv ciBhbiBhcmd1bWVudCB0aGF0IGlzIG1lYW50IHRvIGJlIHNldCBhdApydW4tdGltZSwgc28gSSB3 b3VsZCBsaWtlIHRvIHN1cHBvcnQgdGhpcyBhcyB3ZWxsLgoKQW5kIHllcywgcmlnaHQgbm93IEkg YW0gdXNpbmcgQ21kbGluZXIncyByZXF1aXJlZCBvcHRpb25hbCBhcmd1bWVudHMKZm9yIHRoaXMg ZmVhdHVyZS4KCj4gQmVzdCwKPgo+IERhbmllbAo+Cj4gUC5TLiBSYXRoZXIgdGhhbiBjb25maWd1 cmF0aW9uIFBhcmFtIEkgd291bGQgdXNlIGNvbmZpZ3VyYXRpb24gS2V5IHdoaWNoIGlzIHNob3J0 ZXIgYW5kIGEgZnVsbCB3b3JkLCBidXQgbmFtaW5nIGlzIHN1YmplY3RpdmUuCgpBZ3JlZWQsIHNv dW5kcyBhbmQgbG9va3MgYmV0dGVyIGFzIHdlbGwuCgpUaGFua3MhCgpCZXN0IHdpc2hlcywKTmlj b2xhcwoKPgo+IFsxXSAgVGhhdCdzOgo+Cj4gaHR0cHM6Ly9naXRodWIuY29tL3NhbW9odC9hc3Nl bWJsYWdlL2Jsb2IvNzU3YjM2YzZiODgwYjNhODZiNjE3NzI3N2UyYTY2NTU1YmZiN2FmMi9saWIv YXNzZW1ibGFnZS5tbGkjTDEwOTEtTDEwOTYKPgo+IHdoYXQgYXNzZW1ibGFnZSBzYXlzIG9uIHRo ZSB0b3BpYy4gQmFzaWNhbGx5IHdlIGhhdmUgdWlkIGludGVybmFsbHkgc28gd2UgZG9uJ3QgZGlz Y3JpbWluYXRlIG9uIHRoZSBuYW1lLiBIb3dldmVyIHRoYXQgd2FybmluZyBpbiB0aGUgZG9jdW1l bnRhdGlvbiBpcyBvdmVyIHBlc3NpbWlzdGljLiBJbiBmYWN0IGlmIEkgZ2V0IHR3byBjb25maWd1 cmF0aW9uIGtleXMgd2l0aCB0aGUgc2FtZSBuYW1lIEkgZW1pdCBhIHdhcm5pbmcgYW5kIGdlbmVy YXRlIGFuIGFsdGVybmF0ZSBuYW1lIGZvciB0aGUgb3B0aW9uIG9uIHRoZSBjb21tYW5kIGxpbmUg KGUuZy4gLS1kdXBuYW1lfjEta2V5KS4gU2VlIGhlcmU6Cj4KPiBodHRwczovL2dpdGh1Yi5jb20v c2Ftb2h0L2Fzc2VtYmxhZ2UvYmxvYi83NTdiMzZjNmI4ODBiM2E4NmI2MTc3Mjc3ZTJhNjY1NTVi ZmI3YWYyL2xpYi1kcml2ZXIvYXNzZW1ibGFnZV9kcml2ZXIubWwjTDQyLUw1Mwo+Cj4KPgo+Cj4K Pgo+Cj4gIGJ1dCBpZiB5b3UgaGF2ZSB0d28gY29uZmlndXJhdGlvbiB3aXRoIHRoZSBzYW1lIG5h bWUsICBJIHRoaW5rIHRoYXQgaW4gYXNzZW1ibGFnZSB0aGlzIGlzIG5vdCBhIHJlYWwgcHJvYmxl bSAodW5sZXNzIHlvdSBsb2FkIG1vcmUgdGhhbiBvbmUgcHJvamVjdCkKPgo+Cj4KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1h aWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlz dHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVs Cg== From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 17:00:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 17:00:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZlB-0002eI-L2; Thu, 04 Dec 2014 17:00:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZlA-0002eA-2k for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 17:00:08 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 05/7E-09842-71390845; Thu, 04 Dec 2014 17:00:07 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-5.tower-21.messagelabs.com!1417712406!13463118!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24636 invoked from network); 4 Dec 2014 17:00:07 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-5.tower-21.messagelabs.com with SMTP; 4 Dec 2014 17:00:07 -0000 Received: from [172.20.10.2] (24-224.197-178.cust.bluewin.ch [178.197.224.24]) by smtp.webfaction.com (Postfix) with ESMTP id B2BC959A36C8; Thu, 4 Dec 2014 17:00:04 +0000 (UTC) Date: Thu, 4 Dec 2014 18:00:07 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Nicolas Ojeda Bar Message-ID: <8CC92252BCE54BA5A2628E31BDA23D1F@erratique.ch> In-Reply-To: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Thomas Gazagnaire , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgamV1ZGksIDQgZMOpY2VtYnJlIDIwMTQgw6AgMTc6MzcsIE5pY29sYXMgT2plZGEgQmFyIGEg w6ljcml0IDoKPiBSaWdodCBub3cgdGhleSBhcmUgZGVmaW5lZCBieSB0aGVpciBuYW1lLCBhbmQg aXQgaXMgYSBmYXRhbCBlcnJvciBpZgo+IHlvdSB1c2UgdHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJz IHdpdGggdGhlIHNhbWUgbmFtZS4gQnV0IEkgbGlrZSB0aGUKPiBpZGVhIG9mIGVtaXR0aW5nIGEg d2FybmluZyBhbmQgcmVuYW1pbmcgdGhlIHBhcmFtZXRlciBpZiB0aGVyZSBpcyBhIGNsYXNoLgoK VGhhdCBmYXRhbCBlcnJvciBjb3VsZCBiZSB2ZXJ5IGFubm95aW5nIGl0IGdvZXMgYWdhaW5zdCBt b2R1bGFyaXR5LiBXZSByZWFsbHkgZG9uJ3Qgd2FudCB0byBiZSBzdHVjayBiZWNhdXNlIHR3byBk ZXZlbG9wZXJzIG5vdCBrbm93aW5nIGVhY2ggb3RoZXIgY2hvb3NlZCB0byB1c2UgdGhlIHNhbWUg bmFtZSBmb3IgYSBrZXkuIEp1c3QgdG8gbWFrZSBpdCBjbGVhciwgaW4gYXNzZW1ibGFnZSBJIGRv IG5vdCByZW5hbWUgdGhlICprZXkgbmFtZSosIGtleXMgYXJlIGRpc3Rpbmd1aXNoZWQgYnkgYW4g aW50ZWdlciB1aWQgYW5kIGFyZSBhbGxvd2VkIHRvIGhhdmUgZHVwbGljYXRlIG5hbWVzLiBIb3dl dmVyIEkgZG8gZmluZCBhbiBhbHRlcm5hdGUgKmNvbW1hbmQgbGluZSBvcHRpb24gbmFtZSogc28g dGhhdCB5b3UgY2FuIHN0aWxsIHNldCB0aGUgdmFsdWUgb2YgYm90aCBrZXlzIHNoYXJpbmcgdGhl IHNhbWUgbmFtZSBmcm9tIHRoZSBjb21tYW5kIGxpbmUuCgpCZXN0LAoKRGFuaWVsCgoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVs IG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8v bGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRl dmVsCg== From mirageos-devel-bounces@lists.xenproject.org Thu Dec 04 17:00:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 04 Dec 2014 17:00:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZlB-0002eI-L2; Thu, 04 Dec 2014 17:00:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XwZlA-0002eA-2k for mirageos-devel@lists.xenproject.org; Thu, 04 Dec 2014 17:00:08 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 05/7E-09842-71390845; Thu, 04 Dec 2014 17:00:07 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-5.tower-21.messagelabs.com!1417712406!13463118!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24636 invoked from network); 4 Dec 2014 17:00:07 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-5.tower-21.messagelabs.com with SMTP; 4 Dec 2014 17:00:07 -0000 Received: from [172.20.10.2] (24-224.197-178.cust.bluewin.ch [178.197.224.24]) by smtp.webfaction.com (Postfix) with ESMTP id B2BC959A36C8; Thu, 4 Dec 2014 17:00:04 +0000 (UTC) Date: Thu, 4 Dec 2014 18:00:07 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Nicolas Ojeda Bar Message-ID: <8CC92252BCE54BA5A2628E31BDA23D1F@erratique.ch> In-Reply-To: References: <48EDB842-5484-4DCB-95E7-7A2B30787684@gazagnaire.org> <1417117077.3628838.196166825.7DFC5370@webmail.messagingengine.com> <1417176100.136165.196360713.522CFFD1@webmail.messagingengine.com> <85A36DEC-DBCA-4AEE-87AD-B70FBDF6739E@recoil.org> <60834532-1CF2-463B-A693-6577423E6C24@gazagnaire.org> <608033D71EE94981A162D5D791D0658B@erratique.ch> <125E35C5-7BA7-4AA6-8770-FE596D948D58@nottingham.ac.uk> <7B6CDEC522554172849B28F963318828@erratique.ch> <6369F42F-1BA8-49D9-BD88-CF9433C10727@nottingham.ac.uk> <63E20FB5-2CF7-415F-BF6F-F726E1661665@recoil.org> <29915556-589C-4894-8DF2-AA71C0989057@recoil.org> <69EE38F4-9B1A-4D88-B3BD-6CF22F3D0393@gazagnaire.org> <89EF908689EA4266B48745DF17BCCC4B@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Thomas Gazagnaire , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] command line arguments for unikernels X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgamV1ZGksIDQgZMOpY2VtYnJlIDIwMTQgw6AgMTc6MzcsIE5pY29sYXMgT2plZGEgQmFyIGEg w6ljcml0IDoKPiBSaWdodCBub3cgdGhleSBhcmUgZGVmaW5lZCBieSB0aGVpciBuYW1lLCBhbmQg aXQgaXMgYSBmYXRhbCBlcnJvciBpZgo+IHlvdSB1c2UgdHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJz IHdpdGggdGhlIHNhbWUgbmFtZS4gQnV0IEkgbGlrZSB0aGUKPiBpZGVhIG9mIGVtaXR0aW5nIGEg d2FybmluZyBhbmQgcmVuYW1pbmcgdGhlIHBhcmFtZXRlciBpZiB0aGVyZSBpcyBhIGNsYXNoLgoK VGhhdCBmYXRhbCBlcnJvciBjb3VsZCBiZSB2ZXJ5IGFubm95aW5nIGl0IGdvZXMgYWdhaW5zdCBt b2R1bGFyaXR5LiBXZSByZWFsbHkgZG9uJ3Qgd2FudCB0byBiZSBzdHVjayBiZWNhdXNlIHR3byBk ZXZlbG9wZXJzIG5vdCBrbm93aW5nIGVhY2ggb3RoZXIgY2hvb3NlZCB0byB1c2UgdGhlIHNhbWUg bmFtZSBmb3IgYSBrZXkuIEp1c3QgdG8gbWFrZSBpdCBjbGVhciwgaW4gYXNzZW1ibGFnZSBJIGRv IG5vdCByZW5hbWUgdGhlICprZXkgbmFtZSosIGtleXMgYXJlIGRpc3Rpbmd1aXNoZWQgYnkgYW4g aW50ZWdlciB1aWQgYW5kIGFyZSBhbGxvd2VkIHRvIGhhdmUgZHVwbGljYXRlIG5hbWVzLiBIb3dl dmVyIEkgZG8gZmluZCBhbiBhbHRlcm5hdGUgKmNvbW1hbmQgbGluZSBvcHRpb24gbmFtZSogc28g dGhhdCB5b3UgY2FuIHN0aWxsIHNldCB0aGUgdmFsdWUgb2YgYm90aCBrZXlzIHNoYXJpbmcgdGhl IHNhbWUgbmFtZSBmcm9tIHRoZSBjb21tYW5kIGxpbmUuCgpCZXN0LAoKRGFuaWVsCgoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVs IG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8v bGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRl dmVsCg== From mirageos-devel-bounces@lists.xenproject.org Sun Dec 07 22:01:42 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 07 Dec 2014 22:01:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxjtW-0001th-Vy; Sun, 07 Dec 2014 22:01:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxjtU-0001tc-Pf for mirageos-devel@lists.xenproject.org; Sun, 07 Dec 2014 22:01:32 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 75/BF-17694-C3EC4845; Sun, 07 Dec 2014 22:01:32 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-31.messagelabs.com!1417989691!11666922!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11245 invoked from network); 7 Dec 2014 22:01:31 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Dec 2014 22:01:31 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 69ccc08b; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 7 Dec 2014 22:06:52 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sun, 7 Dec 2014 22:01:29 +0000 Message-Id: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 11 Nov 2014, at 15:56, Thomas Leonard wrote: > > I've been making some updates to the mirage tracing support, which is now here: > > https://github.com/mirage/mirage-profile > > > If anyone has had any success using the tracing themselves (or got > stuck), let me know! > I've got tracing output on my Mac now as well, in the form of a CTF file. What's the process of getting the HTML5 viewer working with the CTF files? It appears to be using the old marshalled format at the moment. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 07 22:01:42 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 07 Dec 2014 22:01:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxjtW-0001th-Vy; Sun, 07 Dec 2014 22:01:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxjtU-0001tc-Pf for mirageos-devel@lists.xenproject.org; Sun, 07 Dec 2014 22:01:32 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 75/BF-17694-C3EC4845; Sun, 07 Dec 2014 22:01:32 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-31.messagelabs.com!1417989691!11666922!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11245 invoked from network); 7 Dec 2014 22:01:31 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Dec 2014 22:01:31 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 69ccc08b; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 7 Dec 2014 22:06:52 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sun, 7 Dec 2014 22:01:29 +0000 Message-Id: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 11 Nov 2014, at 15:56, Thomas Leonard wrote: > > I've been making some updates to the mirage tracing support, which is now here: > > https://github.com/mirage/mirage-profile > > > If anyone has had any success using the tracing themselves (or got > stuck), let me know! > I've got tracing output on my Mac now as well, in the form of a CTF file. What's the process of getting the HTML5 viewer working with the CTF files? It appears to be using the old marshalled format at the moment. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 10:48:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 10:48:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xxvrt-000134-57; Mon, 08 Dec 2014 10:48:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xxvrs-00012x-I0 for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:48:40 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 59/D2-25276-70285845; Mon, 08 Dec 2014 10:48:39 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1418035718!13764330!1 X-Originating-IP: [209.85.220.178] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16336 invoked from network); 8 Dec 2014 10:48:39 -0000 Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com) (209.85.220.178) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Dec 2014 10:48:39 -0000 Received: by mail-vc0-f178.google.com with SMTP id hq11so2005636vcb.23 for ; Mon, 08 Dec 2014 02:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=apvpDEKovHPzrk80OcLPI4ne8/t6690UjWCcZty57Qg=; b=znEhM48pA9nXcKNvL3MOfYrzukIbV4BfkSXfznQdr6tQQaRr/EY3ODa3J83qUK294Z NYhZ1B99E+PN8+TBpLJyWQ/Vyel4YrllnvO7G+rXJaQcJ2YYCw6XVwTl+K3v95n4tZou 7DrcNHliih/64aUse4851hxAYt5ps6RYptwR5oP6dzrNf62GR3F2BtjGxynPTTbzgxj+ 5c5xjf+5i1OarmqH+p27DBvYXM+wEKb1E1c5Qti1n3bGjzFEsQdFH1G2vpJPiX9HdMBJ qVmGMsMgcGFjBc5JJCj4b7Cs/rkUddsoy53ZLXCvDqbihw1E5VFYBpKeqDhItP6jOw2j v7kw== MIME-Version: 1.0 X-Received: by 10.220.12.131 with SMTP id x3mr19216886vcx.63.1418035718204; Mon, 08 Dec 2014 02:48:38 -0800 (PST) Received: by 10.31.183.134 with HTTP; Mon, 8 Dec 2014 02:48:38 -0800 (PST) In-Reply-To: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> Date: Mon, 8 Dec 2014 10:48:38 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 7 December 2014 at 22:01, Anil Madhavapeddy wrote: > On 11 Nov 2014, at 15:56, Thomas Leonard wrote: >> >> I've been making some updates to the mirage tracing support, which is now here: >> >> https://github.com/mirage/mirage-profile >> > >> >> If anyone has had any success using the tracing themselves (or got >> stuck), let me know! >> > > I've got tracing output on my Mac now as well, in the form of a CTF file. > > What's the process of getting the HTML5 viewer working with the CTF > files? It appears to be using the old marshalled format at the moment. I've just added CTF support, so it should work now. It still needs to be made easier though. Ideally, I think it should work something like this: dom0# mirage-trace-vewier dom:www --browser Open this page in your browser to see the trace: https://cubietruck.local/oovohchi6kio0G/index.html I'd like to unify the various tools for collecting and viewing traces. We have three input methods: - snapshot a Xen guest via shared memory - snapshot a Unix process via an mmapped file - load a saved .ctf trace file and three output methods: - run the GTK viewer - generate JavaScript to post on the web - save as .ctf - serve a web-page directly (not yet implemented) If I understand correctly, building GTK on OS X is difficult (though possible, since 0install uses it), so that needs to be optional. Building support for reading from a Xen guest requires xenstore support, which is also difficult to build (requires Xen headers), so that needs to be optional too. It would also be good to be able to ship a binary of this. I might try something with Dynlink for GTK so it will still work on platforms without it (this is what 0install does). -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 10:48:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 10:48:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xxvrt-000134-57; Mon, 08 Dec 2014 10:48:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xxvrs-00012x-I0 for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 10:48:40 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 59/D2-25276-70285845; Mon, 08 Dec 2014 10:48:39 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1418035718!13764330!1 X-Originating-IP: [209.85.220.178] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16336 invoked from network); 8 Dec 2014 10:48:39 -0000 Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com) (209.85.220.178) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Dec 2014 10:48:39 -0000 Received: by mail-vc0-f178.google.com with SMTP id hq11so2005636vcb.23 for ; Mon, 08 Dec 2014 02:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=apvpDEKovHPzrk80OcLPI4ne8/t6690UjWCcZty57Qg=; b=znEhM48pA9nXcKNvL3MOfYrzukIbV4BfkSXfznQdr6tQQaRr/EY3ODa3J83qUK294Z NYhZ1B99E+PN8+TBpLJyWQ/Vyel4YrllnvO7G+rXJaQcJ2YYCw6XVwTl+K3v95n4tZou 7DrcNHliih/64aUse4851hxAYt5ps6RYptwR5oP6dzrNf62GR3F2BtjGxynPTTbzgxj+ 5c5xjf+5i1OarmqH+p27DBvYXM+wEKb1E1c5Qti1n3bGjzFEsQdFH1G2vpJPiX9HdMBJ qVmGMsMgcGFjBc5JJCj4b7Cs/rkUddsoy53ZLXCvDqbihw1E5VFYBpKeqDhItP6jOw2j v7kw== MIME-Version: 1.0 X-Received: by 10.220.12.131 with SMTP id x3mr19216886vcx.63.1418035718204; Mon, 08 Dec 2014 02:48:38 -0800 (PST) Received: by 10.31.183.134 with HTTP; Mon, 8 Dec 2014 02:48:38 -0800 (PST) In-Reply-To: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> Date: Mon, 8 Dec 2014 10:48:38 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 7 December 2014 at 22:01, Anil Madhavapeddy wrote: > On 11 Nov 2014, at 15:56, Thomas Leonard wrote: >> >> I've been making some updates to the mirage tracing support, which is now here: >> >> https://github.com/mirage/mirage-profile >> > >> >> If anyone has had any success using the tracing themselves (or got >> stuck), let me know! >> > > I've got tracing output on my Mac now as well, in the form of a CTF file. > > What's the process of getting the HTML5 viewer working with the CTF > files? It appears to be using the old marshalled format at the moment. I've just added CTF support, so it should work now. It still needs to be made easier though. Ideally, I think it should work something like this: dom0# mirage-trace-vewier dom:www --browser Open this page in your browser to see the trace: https://cubietruck.local/oovohchi6kio0G/index.html I'd like to unify the various tools for collecting and viewing traces. We have three input methods: - snapshot a Xen guest via shared memory - snapshot a Unix process via an mmapped file - load a saved .ctf trace file and three output methods: - run the GTK viewer - generate JavaScript to post on the web - save as .ctf - serve a web-page directly (not yet implemented) If I understand correctly, building GTK on OS X is difficult (though possible, since 0install uses it), so that needs to be optional. Building support for reading from a Xen guest requires xenstore support, which is also difficult to build (requires Xen headers), so that needs to be optional too. It would also be good to be able to ship a binary of this. I might try something with Dynlink for GTK so it will still work on platforms without it (this is what 0install does). -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 11:22:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 11:22:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwOe-0002wW-2f; Mon, 08 Dec 2014 11:22:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwOd-0002wK-7i for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:22:31 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 37/7E-15461-6F985845; Mon, 08 Dec 2014 11:22:30 +0000 X-Env-Sender: hannes@mehnert.org X-Msg-Ref: server-7.tower-21.messagelabs.com!1418037750!14127230!1 X-Originating-IP: [213.73.89.200] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26592 invoked from network); 8 Dec 2014 11:22:30 -0000 Received: from mail.mehnert.org (HELO mail.mehnert.org) (213.73.89.200) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 11:22:30 -0000 Received: from [192.168.1.100] (i5E86C485.versanet.de [94.134.196.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (verified OK)) by mail.mehnert.org (Postfix) with ESMTPS id 28DFF1C2D for ; Mon, 8 Dec 2014 12:22:29 +0100 (CET) Message-ID: <548589E7.8070700@mehnert.org> Date: Mon, 08 Dec 2014 12:22:15 +0100 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] talk at the 31st chaos communication congress about openmirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 hey, david kaloper and myself will present mirage (and especially crypto and security protocols) at the 31st chaos communication congress (27-30th december in hamburg, germany). a preliminary schedule is already published, find our description at https://events.ccc.de/congress/2014/Fahrplan/events/6443.html cheers, hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJUhYnnAAoJELyJZYjffCjuyUYQAIfM7U6mmROIVCQrt55AMwd/ hk9dtUFNqYQZfkE7ovkUWEiRfWPidYK5ehDy8QVGCmrLSnYk7v38N/rZ8MWwrDC8 PdCU/i/HuCXn4FutjvmJ7D09ZaBPfcZMWBeOTCE50Wnjl/yH3pLIHfEyxNtIhbB1 w19h3pLOnrjCKqUTXgQMQy/M0P1gzxv4Anp9vOPPp5JzDTsUPPoqLPcpB9Q6IxKp geR9lvvxf9CCqkj1sWws3Vt0XFbSM3z7amnSOWlA1nd6YKm6PbmlEh81vthgoT1C 83z3pNjBBSfiXndFxu3fRI90rEfpoOxSqGkyNT/N3Nx1fizcNknkyMDiZYgkfq3M bD9h9QdOLP4usvUZrwXiOLlA/VisIrZ2qlVpFgmpRoQMx51my5nW0V6vAJ6D9OIs Totl5+Pv1db/pZR+D7+ENWiF8IApiXRj9SuvO5kezaraju2sLRFXbfJSkeBn4xJo VZLXcByZ7vGQULsLu28ZSdjBFtXuSoevhrAOlh9XPCD4oy1qVPNRvo38MGF6dlZO IQxvKRgRQmP8doX2gLUMGSrv/jvqsnEi6Z3LPClmS64uXirYfdxlQPQ/0YJVK3wa OriD9Z0UtlsQhvC4amSugg6vLnAfTyWNGuPN+FljntKegAnetMS1QffJF4rgXF0y fJkiBdmRokWPQ9Q2ZoOO =4H+9 -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 11:22:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 11:22:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwOe-0002wW-2f; Mon, 08 Dec 2014 11:22:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwOd-0002wK-7i for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:22:31 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 37/7E-15461-6F985845; Mon, 08 Dec 2014 11:22:30 +0000 X-Env-Sender: hannes@mehnert.org X-Msg-Ref: server-7.tower-21.messagelabs.com!1418037750!14127230!1 X-Originating-IP: [213.73.89.200] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26592 invoked from network); 8 Dec 2014 11:22:30 -0000 Received: from mail.mehnert.org (HELO mail.mehnert.org) (213.73.89.200) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 11:22:30 -0000 Received: from [192.168.1.100] (i5E86C485.versanet.de [94.134.196.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (verified OK)) by mail.mehnert.org (Postfix) with ESMTPS id 28DFF1C2D for ; Mon, 8 Dec 2014 12:22:29 +0100 (CET) Message-ID: <548589E7.8070700@mehnert.org> Date: Mon, 08 Dec 2014 12:22:15 +0100 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] talk at the 31st chaos communication congress about openmirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 hey, david kaloper and myself will present mirage (and especially crypto and security protocols) at the 31st chaos communication congress (27-30th december in hamburg, germany). a preliminary schedule is already published, find our description at https://events.ccc.de/congress/2014/Fahrplan/events/6443.html cheers, hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJUhYnnAAoJELyJZYjffCjuyUYQAIfM7U6mmROIVCQrt55AMwd/ hk9dtUFNqYQZfkE7ovkUWEiRfWPidYK5ehDy8QVGCmrLSnYk7v38N/rZ8MWwrDC8 PdCU/i/HuCXn4FutjvmJ7D09ZaBPfcZMWBeOTCE50Wnjl/yH3pLIHfEyxNtIhbB1 w19h3pLOnrjCKqUTXgQMQy/M0P1gzxv4Anp9vOPPp5JzDTsUPPoqLPcpB9Q6IxKp geR9lvvxf9CCqkj1sWws3Vt0XFbSM3z7amnSOWlA1nd6YKm6PbmlEh81vthgoT1C 83z3pNjBBSfiXndFxu3fRI90rEfpoOxSqGkyNT/N3Nx1fizcNknkyMDiZYgkfq3M bD9h9QdOLP4usvUZrwXiOLlA/VisIrZ2qlVpFgmpRoQMx51my5nW0V6vAJ6D9OIs Totl5+Pv1db/pZR+D7+ENWiF8IApiXRj9SuvO5kezaraju2sLRFXbfJSkeBn4xJo VZLXcByZ7vGQULsLu28ZSdjBFtXuSoevhrAOlh9XPCD4oy1qVPNRvo38MGF6dlZO IQxvKRgRQmP8doX2gLUMGSrv/jvqsnEi6Z3LPClmS64uXirYfdxlQPQ/0YJVK3wa OriD9Z0UtlsQhvC4amSugg6vLnAfTyWNGuPN+FljntKegAnetMS1QffJF4rgXF0y fJkiBdmRokWPQ9Q2ZoOO =4H+9 -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 11:59:22 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 11:59:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwyF-0004HI-6s; Mon, 08 Dec 2014 11:59:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwyE-0004HD-Ek for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:59:18 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 9A/37-26858-59295845; Mon, 08 Dec 2014 11:59:17 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-4.tower-31.messagelabs.com!1418039956!11729121!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15629 invoked from network); 8 Dec 2014 11:59:16 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 11:59:16 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-176-251.eduroam.wireless.private.cam.ac.uk ([172.17.176.251]:65472) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1XxwyC-0005bT-qP (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Mon, 08 Dec 2014 11:59:16 +0000 From: Amir Chaudhry Message-Id: <6989B372-3C52-4A1C-9288-9D995F37A18F@cam.ac.uk> Date: Mon, 8 Dec 2014 11:59:18 +0000 To: "mirageos-devel@lists.xenproject.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [MirageOS-devel] Mirage fortnightly call - Wednesday 10th at **5pm** GMT X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi folks, The next Mirage call will take place this Wednesday afternoon at **5pm GMT*= * and it's open to all. Please note the slightly later time! This is also scheduled to be the last= call of 2014. You can catch up via notes from the last call at http://openmirage.org/wiki= /weekly-2014-11-26 The agenda is currently as follows: =95 IPv6 Merging =95 Entropy progress =95 MacOSX vmnet support, ocaml-vmnet and mirage-net-macosx =95 Pioneer Projects (add some!) If you have things to add/edit, please do so at https://github.com/mirage/m= irage-www/wiki/Call-Agenda GoToMeeting details are below but if there are any hiccups/delays then I'll= switch to a public Google Hangout. If that happens, I'll post the link he= re and also in the IRC channel (#mirage on freenode). Join us at **5pm** GMT on Wednesday! 1. Please join my meeting. https://www1.gotomeeting.com/join/591890401 Dial in numbers (ask if you need a specific country): United Kingdom: +44 (0) 20 3657 6778 United States: +1 (213) 493-0014 Access Code: 591-890-401 Audio PIN: Shown after joining the meeting Best wishes, Amir _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 11:59:22 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 11:59:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwyF-0004HI-6s; Mon, 08 Dec 2014 11:59:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxwyE-0004HD-Ek for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 11:59:18 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 9A/37-26858-59295845; Mon, 08 Dec 2014 11:59:17 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-4.tower-31.messagelabs.com!1418039956!11729121!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15629 invoked from network); 8 Dec 2014 11:59:16 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 11:59:16 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-176-251.eduroam.wireless.private.cam.ac.uk ([172.17.176.251]:65472) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1XxwyC-0005bT-qP (Exim 4.82_3-c0e5623) for mirageos-devel@lists.xenproject.org (return-path ); Mon, 08 Dec 2014 11:59:16 +0000 From: Amir Chaudhry Message-Id: <6989B372-3C52-4A1C-9288-9D995F37A18F@cam.ac.uk> Date: Mon, 8 Dec 2014 11:59:18 +0000 To: "mirageos-devel@lists.xenproject.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [MirageOS-devel] Mirage fortnightly call - Wednesday 10th at **5pm** GMT X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi folks, The next Mirage call will take place this Wednesday afternoon at **5pm GMT*= * and it's open to all. Please note the slightly later time! This is also scheduled to be the last= call of 2014. You can catch up via notes from the last call at http://openmirage.org/wiki= /weekly-2014-11-26 The agenda is currently as follows: =95 IPv6 Merging =95 Entropy progress =95 MacOSX vmnet support, ocaml-vmnet and mirage-net-macosx =95 Pioneer Projects (add some!) If you have things to add/edit, please do so at https://github.com/mirage/m= irage-www/wiki/Call-Agenda GoToMeeting details are below but if there are any hiccups/delays then I'll= switch to a public Google Hangout. If that happens, I'll post the link he= re and also in the IRC channel (#mirage on freenode). Join us at **5pm** GMT on Wednesday! 1. Please join my meeting. https://www1.gotomeeting.com/join/591890401 Dial in numbers (ask if you need a specific country): United Kingdom: +44 (0) 20 3657 6778 United States: +1 (213) 493-0014 Access Code: 591-890-401 Audio PIN: Shown after joining the meeting Best wishes, Amir _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 12:22:35 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 12:22:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxxKc-0005zH-9t; Mon, 08 Dec 2014 12:22:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxxKa-0005zA-3K for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 12:22:24 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id E2/4E-26740-FF795845; Mon, 08 Dec 2014 12:22:23 +0000 X-Env-Sender: crowcroft@gmail.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1418041340!11812656!1 X-Originating-IP: [209.85.192.49] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16123 invoked from network); 8 Dec 2014 12:22:21 -0000 Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 8 Dec 2014 12:22:21 -0000 Received: by mail-qg0-f49.google.com with SMTP id a108so3318576qge.8 for ; Mon, 08 Dec 2014 04:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mulKUNKmxH8D1DQmiCG7a9JD5uFpAzK7fvvM3t5msIs=; b=E8jARKNvSLocc5ANUPJcoxKQoapsMgBzeYa0JQtvOQcduZp4rENrRXzvSrhTaKzlDg cUNat/rQA21bSIs9Kk/MzPbMTsE2Y3M49ypyvX6+D5/754kDHlCM2RKyLKEv4AcMR2dg 2hknYHtYFqSPUOe/l0SIDy1OtGEd8WiHJVYMitnSWOpk5F7Q0yiew96notrK3BUy3W7y tgF6U1740GisueztjS+TXddu4jT3GJZ8ZlFuS+HgfXkzpRg2Py+9jISqDDlEdxGK8Y01 4sGNEZfav1rATGpvANdsvx+KzFu8QoaL0Sjl4lAji1pedrxq8DS/NOICHFHYNZJWEeng /Z6A== MIME-Version: 1.0 X-Received: by 10.140.100.228 with SMTP id s91mr51587777qge.31.1418041340576; Mon, 08 Dec 2014 04:22:20 -0800 (PST) Received: by 10.140.104.104 with HTTP; Mon, 8 Dec 2014 04:22:20 -0800 (PST) In-Reply-To: <6989B372-3C52-4A1C-9288-9D995F37A18F@cam.ac.uk> References: <6989B372-3C52-4A1C-9288-9D995F37A18F@cam.ac.uk> Date: Mon, 8 Dec 2014 12:22:20 +0000 X-Google-Sender-Auth: N8cT9Dzgoz8tnsjFoh-H3SWMboA Message-ID: From: Jon Crowcroft To: Amir Chaudhry Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage fortnightly call - Wednesday 10th at **5pm** GMT X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4947263741469601461==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4947263741469601461== Content-Type: multipart/alternative; boundary=001a11c16f7061cdc40509b37a21 --001a11c16f7061cdc40509b37a21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll be in brussels preparing to defend in the mighty User Centric Networking project that helps support some of our efforts - meanwhile, I may not have cell coverage, so this might apply:- http://dilbert.com/strips/comic/2014-12-08/ On Mon, Dec 8, 2014 at 11:59 AM, Amir Chaudhry wrote: > Hi folks, > > The next Mirage call will take place this Wednesday afternoon at **5pm > GMT** and it's open to all. > Please note the slightly later time! This is also scheduled to be the > last call of 2014. > > You can catch up via notes from the last call at > http://openmirage.org/wiki/weekly-2014-11-26 > > The agenda is currently as follows: > > =E2=80=A2 IPv6 Merging > =E2=80=A2 Entropy progress > =E2=80=A2 MacOSX vmnet support, ocaml-vmnet and mirage-net-macosx > =E2=80=A2 Pioneer Projects (add some!) > > If you have things to add/edit, please do so at > https://github.com/mirage/mirage-www/wiki/Call-Agenda > > GoToMeeting details are below but if there are any hiccups/delays then > I'll switch to a public Google Hangout. If that happens, I'll post the > link here and also in the IRC channel (#mirage on freenode). > > Join us at **5pm** GMT on Wednesday! > > 1. Please join my meeting. > https://www1.gotomeeting.com/join/591890401 > > Dial in numbers (ask if you need a specific country): > United Kingdom: +44 (0) 20 3657 6778 > United States: +1 (213) 493-0014 > Access Code: 591-890-401 > Audio PIN: Shown after joining the meeting > > Best wishes, > Amir > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a11c16f7061cdc40509b37a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll be in brussels preparing to defend in the mighty = User Centric Networking project that helps support some of our efforts - me= anwhile, I may not have cell coverage, so this might apply:-

On Mon, Dec 8, 2014 at 11:59 AM, Amir Chaudhry <amc79@cam= .ac.uk> wrote:
Hi folks,
The next Mirage call will take place this Wednesday afternoon at **5pm GMT*= * and it's open to all.
Please note the slightly later time!=C2=A0 This is also scheduled to be the= last call of 2014.

You can catch up via notes from the last call at http://openmirage.org/wiki= /weekly-2014-11-26

The agenda is currently as follows:

=E2=80=A2 IPv6 Merging
=E2=80=A2 Entropy progress
=E2=80=A2 MacOSX vmnet support, ocaml-vmnet and mirage-net-macosx
=E2=80=A2 Pioneer Projects (add some!)

If you have things to add/edit, please do so at https://github.com= /mirage/mirage-www/wiki/Call-Agenda

GoToMeeting details are below but if there are any hiccups/delays then I= 9;ll switch to a public Google Hangout.=C2=A0 If that happens, I'll pos= t the link here and also in the IRC channel (#mirage on freenode).

Join us at **5pm** GMT on Wednesday!

1.=C2=A0 Please join my meeting.
h= ttps://www1.gotomeeting.com/join/591890401

Dial in numbers (ask if you need a specific country):
United Kingdom: +44 (0) 20 3657 6778
United States: +1 (213) 493-0014
Access Code: 591-890-401
Audio PIN: Shown after joining the meeting

Best wishes,
Amir

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a11c16f7061cdc40509b37a21-- --===============4947263741469601461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4947263741469601461==-- From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 12:22:35 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 12:22:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxxKc-0005zH-9t; Mon, 08 Dec 2014 12:22:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxxKa-0005zA-3K for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 12:22:24 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id E2/4E-26740-FF795845; Mon, 08 Dec 2014 12:22:23 +0000 X-Env-Sender: crowcroft@gmail.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1418041340!11812656!1 X-Originating-IP: [209.85.192.49] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16123 invoked from network); 8 Dec 2014 12:22:21 -0000 Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 8 Dec 2014 12:22:21 -0000 Received: by mail-qg0-f49.google.com with SMTP id a108so3318576qge.8 for ; Mon, 08 Dec 2014 04:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mulKUNKmxH8D1DQmiCG7a9JD5uFpAzK7fvvM3t5msIs=; b=E8jARKNvSLocc5ANUPJcoxKQoapsMgBzeYa0JQtvOQcduZp4rENrRXzvSrhTaKzlDg cUNat/rQA21bSIs9Kk/MzPbMTsE2Y3M49ypyvX6+D5/754kDHlCM2RKyLKEv4AcMR2dg 2hknYHtYFqSPUOe/l0SIDy1OtGEd8WiHJVYMitnSWOpk5F7Q0yiew96notrK3BUy3W7y tgF6U1740GisueztjS+TXddu4jT3GJZ8ZlFuS+HgfXkzpRg2Py+9jISqDDlEdxGK8Y01 4sGNEZfav1rATGpvANdsvx+KzFu8QoaL0Sjl4lAji1pedrxq8DS/NOICHFHYNZJWEeng /Z6A== MIME-Version: 1.0 X-Received: by 10.140.100.228 with SMTP id s91mr51587777qge.31.1418041340576; Mon, 08 Dec 2014 04:22:20 -0800 (PST) Received: by 10.140.104.104 with HTTP; Mon, 8 Dec 2014 04:22:20 -0800 (PST) In-Reply-To: <6989B372-3C52-4A1C-9288-9D995F37A18F@cam.ac.uk> References: <6989B372-3C52-4A1C-9288-9D995F37A18F@cam.ac.uk> Date: Mon, 8 Dec 2014 12:22:20 +0000 X-Google-Sender-Auth: N8cT9Dzgoz8tnsjFoh-H3SWMboA Message-ID: From: Jon Crowcroft To: Amir Chaudhry Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage fortnightly call - Wednesday 10th at **5pm** GMT X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4947263741469601461==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4947263741469601461== Content-Type: multipart/alternative; boundary=001a11c16f7061cdc40509b37a21 --001a11c16f7061cdc40509b37a21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll be in brussels preparing to defend in the mighty User Centric Networking project that helps support some of our efforts - meanwhile, I may not have cell coverage, so this might apply:- http://dilbert.com/strips/comic/2014-12-08/ On Mon, Dec 8, 2014 at 11:59 AM, Amir Chaudhry wrote: > Hi folks, > > The next Mirage call will take place this Wednesday afternoon at **5pm > GMT** and it's open to all. > Please note the slightly later time! This is also scheduled to be the > last call of 2014. > > You can catch up via notes from the last call at > http://openmirage.org/wiki/weekly-2014-11-26 > > The agenda is currently as follows: > > =E2=80=A2 IPv6 Merging > =E2=80=A2 Entropy progress > =E2=80=A2 MacOSX vmnet support, ocaml-vmnet and mirage-net-macosx > =E2=80=A2 Pioneer Projects (add some!) > > If you have things to add/edit, please do so at > https://github.com/mirage/mirage-www/wiki/Call-Agenda > > GoToMeeting details are below but if there are any hiccups/delays then > I'll switch to a public Google Hangout. If that happens, I'll post the > link here and also in the IRC channel (#mirage on freenode). > > Join us at **5pm** GMT on Wednesday! > > 1. Please join my meeting. > https://www1.gotomeeting.com/join/591890401 > > Dial in numbers (ask if you need a specific country): > United Kingdom: +44 (0) 20 3657 6778 > United States: +1 (213) 493-0014 > Access Code: 591-890-401 > Audio PIN: Shown after joining the meeting > > Best wishes, > Amir > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a11c16f7061cdc40509b37a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll be in brussels preparing to defend in the mighty = User Centric Networking project that helps support some of our efforts - me= anwhile, I may not have cell coverage, so this might apply:-

On Mon, Dec 8, 2014 at 11:59 AM, Amir Chaudhry <amc79@cam= .ac.uk> wrote:
Hi folks,
The next Mirage call will take place this Wednesday afternoon at **5pm GMT*= * and it's open to all.
Please note the slightly later time!=C2=A0 This is also scheduled to be the= last call of 2014.

You can catch up via notes from the last call at http://openmirage.org/wiki= /weekly-2014-11-26

The agenda is currently as follows:

=E2=80=A2 IPv6 Merging
=E2=80=A2 Entropy progress
=E2=80=A2 MacOSX vmnet support, ocaml-vmnet and mirage-net-macosx
=E2=80=A2 Pioneer Projects (add some!)

If you have things to add/edit, please do so at https://github.com= /mirage/mirage-www/wiki/Call-Agenda

GoToMeeting details are below but if there are any hiccups/delays then I= 9;ll switch to a public Google Hangout.=C2=A0 If that happens, I'll pos= t the link here and also in the IRC channel (#mirage on freenode).

Join us at **5pm** GMT on Wednesday!

1.=C2=A0 Please join my meeting.
h= ttps://www1.gotomeeting.com/join/591890401

Dial in numbers (ask if you need a specific country):
United Kingdom: +44 (0) 20 3657 6778
United States: +1 (213) 493-0014
Access Code: 591-890-401
Audio PIN: Shown after joining the meeting

Best wishes,
Amir

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a11c16f7061cdc40509b37a21-- --===============4947263741469601461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4947263741469601461==-- From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 19:55:02 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 19:55:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy4OT-00011g-TV; Mon, 08 Dec 2014 19:54:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy4OS-00010P-RI for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 19:54:52 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id FC/F4-15461-C0206845; Mon, 08 Dec 2014 19:54:52 +0000 X-Env-Sender: bothwell.christopher@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1418068490!14232065!1 X-Originating-IP: [209.85.216.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16355 invoked from network); 8 Dec 2014 19:54:51 -0000 Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Dec 2014 19:54:51 -0000 Received: by mail-qc0-f169.google.com with SMTP id w7so4072604qcr.14 for ; Mon, 08 Dec 2014 11:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sNx2uN9t3hWW/LHrZLPgh+8odC9t+B28KkXGSv7nyus=; b=DPPem+V3NZmQV6aAykqzaSMk37GqNktxdj47tXdRcl4cJIlRat0YJV9jQ/4uCx2c6Y RafVpU9kWGiqBseIqx2JS+nzNq08eGar9fu03SBkedyKptuiDNTTykEseRsdG9sU0nnc mT4UI7tHscUUku0rbCgTHwoeRznakrKyOw3aVCby1dCIcEwGg8vkxZkAIaA601opEwA5 CUTdHVaEPylgAehACoRsY5m5GMe3do6AZJKOiZxIhNYWmZNLVHZSjWkTL9L2Eo2x5ntr 9uIjk6xDPN0DE5LNZka6PBIrRexKfroFzPgR+98Q7jJj34lkmxbz0IYvWHNp877hPALT IGgA== MIME-Version: 1.0 X-Received: by 10.224.94.9 with SMTP id x9mr56955970qam.45.1418068490292; Mon, 08 Dec 2014 11:54:50 -0800 (PST) Received: by 10.140.89.229 with HTTP; Mon, 8 Dec 2014 11:54:50 -0800 (PST) Date: Mon, 8 Dec 2014 13:54:50 -0600 Message-ID: From: Christopher Bothwell To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] New to Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6098330722857364205==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6098330722857364205== Content-Type: multipart/alternative; boundary=047d7b673a84a1932e0509b9cc83 --047d7b673a84a1932e0509b9cc83 Content-Type: text/plain; charset=UTF-8 Hello, My name is Christopher. I'm a Linux admin, but I've been watching this project for sometime and I'd like to get more involved with it. I'm not so proficient at coding and I'm looking for something small to get more experience with the code base and how things are done. I did notice the Pioneer Projects but the tasks as they stand now are a bit daunting with reflection to what I know. https://github.com/mirage/mirage-www/wiki/Pioneer-Projects If there a particular project that has some bugs that someone could point me in the direction of, that would be most appreciated. Mirage seems like such a large project with many repositories and it makes it a bit difficult to determine where I should be going. I also got a static blog set up on a Linode instance running a Mirage unikernel. I wrote up a tutorial on how to do it. If someone wants to try it out, I'd be curious to know if I was effective at communicating how to get started with it. http://christopherbothwell.com/ocaml/mirage/linode/2014/12/08/hello-linode.html Thank you --047d7b673a84a1932e0509b9cc83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

My name is Christopher.= I'm a Linux admin, but I've been watching this project for sometim= e and I'd like to get more involved with it.

I'm not = so proficient at coding and I'm looking for something small to get more= experience with the code base and how things are done. I did notice the Pi= oneer Projects but the tasks as they stand now are a bit daunting with refl= ection to what I know.

https://github.com/mirage/mirage-www/wiki/Pioneer-Projec= ts

If there a particular project that has some bugs that s= omeone could point me in the direction of, that would be most appreciated. = Mirage seems like such a large project with many repositories and it makes = it a bit difficult to determine where I should be going.

I al= so got a static blog set up on a Linode instance running a Mirage unikernel= . I wrote up a tutorial on how to do it. If someone wants to try it out, I&= #39;d be curious to know if I was effective at communicating how to get sta= rted with it.

http://christopherbothwell.com/ocaml= /mirage/linode/2014/12/08/hello-linode.html

Thank you
=
--047d7b673a84a1932e0509b9cc83-- --===============6098330722857364205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6098330722857364205==-- From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 19:55:02 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 19:55:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy4OT-00011g-TV; Mon, 08 Dec 2014 19:54:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy4OS-00010P-RI for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 19:54:52 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id FC/F4-15461-C0206845; Mon, 08 Dec 2014 19:54:52 +0000 X-Env-Sender: bothwell.christopher@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1418068490!14232065!1 X-Originating-IP: [209.85.216.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16355 invoked from network); 8 Dec 2014 19:54:51 -0000 Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 8 Dec 2014 19:54:51 -0000 Received: by mail-qc0-f169.google.com with SMTP id w7so4072604qcr.14 for ; Mon, 08 Dec 2014 11:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sNx2uN9t3hWW/LHrZLPgh+8odC9t+B28KkXGSv7nyus=; b=DPPem+V3NZmQV6aAykqzaSMk37GqNktxdj47tXdRcl4cJIlRat0YJV9jQ/4uCx2c6Y RafVpU9kWGiqBseIqx2JS+nzNq08eGar9fu03SBkedyKptuiDNTTykEseRsdG9sU0nnc mT4UI7tHscUUku0rbCgTHwoeRznakrKyOw3aVCby1dCIcEwGg8vkxZkAIaA601opEwA5 CUTdHVaEPylgAehACoRsY5m5GMe3do6AZJKOiZxIhNYWmZNLVHZSjWkTL9L2Eo2x5ntr 9uIjk6xDPN0DE5LNZka6PBIrRexKfroFzPgR+98Q7jJj34lkmxbz0IYvWHNp877hPALT IGgA== MIME-Version: 1.0 X-Received: by 10.224.94.9 with SMTP id x9mr56955970qam.45.1418068490292; Mon, 08 Dec 2014 11:54:50 -0800 (PST) Received: by 10.140.89.229 with HTTP; Mon, 8 Dec 2014 11:54:50 -0800 (PST) Date: Mon, 8 Dec 2014 13:54:50 -0600 Message-ID: From: Christopher Bothwell To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] New to Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6098330722857364205==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6098330722857364205== Content-Type: multipart/alternative; boundary=047d7b673a84a1932e0509b9cc83 --047d7b673a84a1932e0509b9cc83 Content-Type: text/plain; charset=UTF-8 Hello, My name is Christopher. I'm a Linux admin, but I've been watching this project for sometime and I'd like to get more involved with it. I'm not so proficient at coding and I'm looking for something small to get more experience with the code base and how things are done. I did notice the Pioneer Projects but the tasks as they stand now are a bit daunting with reflection to what I know. https://github.com/mirage/mirage-www/wiki/Pioneer-Projects If there a particular project that has some bugs that someone could point me in the direction of, that would be most appreciated. Mirage seems like such a large project with many repositories and it makes it a bit difficult to determine where I should be going. I also got a static blog set up on a Linode instance running a Mirage unikernel. I wrote up a tutorial on how to do it. If someone wants to try it out, I'd be curious to know if I was effective at communicating how to get started with it. http://christopherbothwell.com/ocaml/mirage/linode/2014/12/08/hello-linode.html Thank you --047d7b673a84a1932e0509b9cc83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

My name is Christopher.= I'm a Linux admin, but I've been watching this project for sometim= e and I'd like to get more involved with it.

I'm not = so proficient at coding and I'm looking for something small to get more= experience with the code base and how things are done. I did notice the Pi= oneer Projects but the tasks as they stand now are a bit daunting with refl= ection to what I know.

https://github.com/mirage/mirage-www/wiki/Pioneer-Projec= ts

If there a particular project that has some bugs that s= omeone could point me in the direction of, that would be most appreciated. = Mirage seems like such a large project with many repositories and it makes = it a bit difficult to determine where I should be going.

I al= so got a static blog set up on a Linode instance running a Mirage unikernel= . I wrote up a tutorial on how to do it. If someone wants to try it out, I&= #39;d be curious to know if I was effective at communicating how to get sta= rted with it.

http://christopherbothwell.com/ocaml= /mirage/linode/2014/12/08/hello-linode.html

Thank you
=
--047d7b673a84a1932e0509b9cc83-- --===============6098330722857364205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6098330722857364205==-- From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 23:05:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 23:05:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy7N9-0006tu-TK; Mon, 08 Dec 2014 23:05:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy7N9-0006ti-8Z for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:43 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 3A/B3-01660-6CE26845; Mon, 08 Dec 2014 23:05:42 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-206.messagelabs.com!1418079941!12211285!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27741 invoked from network); 8 Dec 2014 23:05:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 23:05:42 -0000 Received: from [10.192.4.255] (a5887-0145831233.pck.nerim.net [62.212.107.160]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6f3181d6; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 8 Dec 2014 23:11:07 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Mon, 8 Dec 2014 23:05:43 +0000 Message-Id: <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 8 Dec 2014, at 10:48, Thomas Leonard wrote: > > On 7 December 2014 at 22:01, Anil Madhavapeddy wrote: >> On 11 Nov 2014, at 15:56, Thomas Leonard wrote: >>> >>> I've been making some updates to the mirage tracing support, which is now here: >>> >>> https://github.com/mirage/mirage-profile >>> >> >>> >>> If anyone has had any success using the tracing themselves (or got >>> stuck), let me know! >>> >> >> I've got tracing output on my Mac now as well, in the form of a CTF file. >> >> What's the process of getting the HTML5 viewer working with the CTF >> files? It appears to be using the old marshalled format at the moment. > > I've just added CTF support, so it should work now. Great! Trying it now. > > It still needs to be made easier though. Ideally, I think it should > work something like this: > > dom0# mirage-trace-vewier dom:www --browser > Open this page in your browser to see the trace: > https://cubietruck.local/oovohchi6kio0G/index.html > > I'd like to unify the various tools for collecting and viewing traces. > We have three input methods: > > - snapshot a Xen guest via shared memory > - snapshot a Unix process via an mmapped file > - load a saved .ctf trace file > > and three output methods: > > - run the GTK viewer > - generate JavaScript to post on the web > - save as .ctf > - serve a web-page directly (not yet implemented) Agreed. > If I understand correctly, building GTK on OS X is difficult (though > possible, since 0install uses it), so that needs to be optional. Just gave this a try, and it's not too bad using Homebrew these days. $ brew install gtk+ $ brew install cairo $ export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig $ opam install lablgtk cairo > > Building support for reading from a Xen guest requires xenstore > support, which is also difficult to build (requires Xen headers), so > that needs to be optional too. Dave might comment on this -- you shouldn't need the Xen headers to build a simple Xenstore client. Maybe its the gnttab driver? > > It would also be good to be able to ship a binary of this. I might try > something with Dynlink for GTK so it will still work on platforms > without it (this is what 0install does). Are any of the other CTF trace viewers actively developed these days? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 08 23:05:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 08 Dec 2014 23:05:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy7N9-0006tu-TK; Mon, 08 Dec 2014 23:05:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xy7N9-0006ti-8Z for mirageos-devel@lists.xenproject.org; Mon, 08 Dec 2014 23:05:43 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 3A/B3-01660-6CE26845; Mon, 08 Dec 2014 23:05:42 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-206.messagelabs.com!1418079941!12211285!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27741 invoked from network); 8 Dec 2014 23:05:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2014 23:05:42 -0000 Received: from [10.192.4.255] (a5887-0145831233.pck.nerim.net [62.212.107.160]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6f3181d6; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 8 Dec 2014 23:11:07 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Mon, 8 Dec 2014 23:05:43 +0000 Message-Id: <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 8 Dec 2014, at 10:48, Thomas Leonard wrote: > > On 7 December 2014 at 22:01, Anil Madhavapeddy wrote: >> On 11 Nov 2014, at 15:56, Thomas Leonard wrote: >>> >>> I've been making some updates to the mirage tracing support, which is now here: >>> >>> https://github.com/mirage/mirage-profile >>> >> >>> >>> If anyone has had any success using the tracing themselves (or got >>> stuck), let me know! >>> >> >> I've got tracing output on my Mac now as well, in the form of a CTF file. >> >> What's the process of getting the HTML5 viewer working with the CTF >> files? It appears to be using the old marshalled format at the moment. > > I've just added CTF support, so it should work now. Great! Trying it now. > > It still needs to be made easier though. Ideally, I think it should > work something like this: > > dom0# mirage-trace-vewier dom:www --browser > Open this page in your browser to see the trace: > https://cubietruck.local/oovohchi6kio0G/index.html > > I'd like to unify the various tools for collecting and viewing traces. > We have three input methods: > > - snapshot a Xen guest via shared memory > - snapshot a Unix process via an mmapped file > - load a saved .ctf trace file > > and three output methods: > > - run the GTK viewer > - generate JavaScript to post on the web > - save as .ctf > - serve a web-page directly (not yet implemented) Agreed. > If I understand correctly, building GTK on OS X is difficult (though > possible, since 0install uses it), so that needs to be optional. Just gave this a try, and it's not too bad using Homebrew these days. $ brew install gtk+ $ brew install cairo $ export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig $ opam install lablgtk cairo > > Building support for reading from a Xen guest requires xenstore > support, which is also difficult to build (requires Xen headers), so > that needs to be optional too. Dave might comment on this -- you shouldn't need the Xen headers to build a simple Xenstore client. Maybe its the gnttab driver? > > It would also be good to be able to ship a binary of this. I might try > something with Dynlink for GTK so it will still work on platforms > without it (this is what 0install does). Are any of the other CTF trace viewers actively developed these days? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 08:48:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 08:48:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGSZ-0004tA-KF; Tue, 09 Dec 2014 08:47:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGSY-0004t1-6a for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 08:47:54 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id F2/97-25714-937B6845; Tue, 09 Dec 2014 08:47:53 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-206.messagelabs.com!1418114871!8925712!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32383 invoked from network); 9 Dec 2014 08:47:52 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 08:47:52 -0000 Received: from [10.192.4.255] (accoribisavitalie0145862650.pck.nerim.net [213.41.173.249]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 68118ff6; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 08:53:19 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 9 Dec 2014 08:47:56 +0000 Message-Id: <92D17426-9170-4B27-80B1-ED304F6E6B4D@recoil.org> References: To: Christopher Bothwell X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] New to Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360174694518879009==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1360174694518879009== Content-Type: multipart/alternative; boundary="Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF" --Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christopher, That's a splendid and easy to follow blog post about how to swap in the = Mirage kernel under Linode. Figuring out the runes to swap in a = unikernel is often a big blocker to many people that don't know Xen. I'm travelling right now, but will think through putting in more "1 = star" difficulty tasks to get started, as you're right that the ones = there are a bit large (and I encourage everyone else on the list to do = the same for their own areas and take the time to add some pioneer = projects). One immediate point that comes up is that we need to capture information = like yours on the Mirage website, so a pull request that adds this = alongside the (very skeleton) EC2 information would be most useful. I'd = quite like to get a version of the website running on Linode to ensure = we stay working on it, so any scripting automation would also be useful. cheers, Anil > On 8 Dec 2014, at 19:54, Christopher Bothwell = wrote: >=20 > Hello,=20 >=20 > My name is Christopher. I'm a Linux admin, but I've been watching this = project for sometime and I'd like to get more involved with it.=20 >=20 > I'm not so proficient at coding and I'm looking for something small to = get more experience with the code base and how things are done. I did = notice the Pioneer Projects but the tasks as they stand now are a bit = daunting with reflection to what I know.=20 >=20 > https://github.com/mirage/mirage-www/wiki/Pioneer-Projects = >=20 > If there a particular project that has some bugs that someone could = point me in the direction of, that would be most appreciated. Mirage = seems like such a large project with many repositories and it makes it a = bit difficult to determine where I should be going.=20 >=20 > I also got a static blog set up on a Linode instance running a Mirage = unikernel. I wrote up a tutorial on how to do it. If someone wants to = try it out, I'd be curious to know if I was effective at communicating = how to get started with it.=20 >=20 > = http://christopherbothwell.com/ocaml/mirage/linode/2014/12/08/hello-linode= .html = >=20 > Thank you=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Christopher,

That's a splendid and easy to follow blog post about how to = swap in the Mirage kernel under Linode.  Figuring out the runes to = swap in a unikernel is often a big blocker to many people that don't = know Xen.

I'm = travelling right now, but will think through putting in more "1 star" = difficulty tasks to get started, as you're right that the ones there are = a bit large  (and I encourage everyone else on the list to do the = same for their own areas and take the time to add some pioneer = projects).

One = immediate point that comes up is that we need to capture information = like yours on the Mirage website, so a pull request that adds this = alongside the (very skeleton) EC2 information would be most useful. =  I'd quite like to get a version of the website running on Linode = to ensure we stay working on it, so any scripting automation would also = be useful.

cheers,
Anil

On = 8 Dec 2014, at 19:54, Christopher Bothwell <bothwell.christopher@gmail.com> wrote:

Hello,

My name is Christopher. = I'm a Linux admin, but I've been watching this project for sometime and = I'd like to get more involved with it.

I'm not so proficient at coding and I'm looking for = something small to get more experience with the code base and how things = are done. I did notice the Pioneer Projects but the tasks as they stand = now are a bit daunting with reflection to what I know.

https://github.com/mirage/mirage-www/wiki/Pioneer-Projects

If there a particular project that has some bugs that = someone could point me in the direction of, that would be most = appreciated. Mirage seems like such a large project with many = repositories and it makes it a bit difficult to determine where I should = be going.

I also got a static blog = set up on a Linode instance running a Mirage unikernel. I wrote up a = tutorial on how to do it. If someone wants to try it out, I'd be curious = to know if I was effective at communicating how to get started with it. =

http://christopherbothwell.com/ocaml/mirage/linode/2014/12/08/h= ello-linode.html

Thank you
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF-- --===============1360174694518879009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1360174694518879009==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 08:48:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 08:48:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGSZ-0004tA-KF; Tue, 09 Dec 2014 08:47:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGSY-0004t1-6a for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 08:47:54 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id F2/97-25714-937B6845; Tue, 09 Dec 2014 08:47:53 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-206.messagelabs.com!1418114871!8925712!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32383 invoked from network); 9 Dec 2014 08:47:52 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 08:47:52 -0000 Received: from [10.192.4.255] (accoribisavitalie0145862650.pck.nerim.net [213.41.173.249]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 68118ff6; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 08:53:19 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Tue, 9 Dec 2014 08:47:56 +0000 Message-Id: <92D17426-9170-4B27-80B1-ED304F6E6B4D@recoil.org> References: To: Christopher Bothwell X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] New to Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360174694518879009==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1360174694518879009== Content-Type: multipart/alternative; boundary="Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF" --Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christopher, That's a splendid and easy to follow blog post about how to swap in the = Mirage kernel under Linode. Figuring out the runes to swap in a = unikernel is often a big blocker to many people that don't know Xen. I'm travelling right now, but will think through putting in more "1 = star" difficulty tasks to get started, as you're right that the ones = there are a bit large (and I encourage everyone else on the list to do = the same for their own areas and take the time to add some pioneer = projects). One immediate point that comes up is that we need to capture information = like yours on the Mirage website, so a pull request that adds this = alongside the (very skeleton) EC2 information would be most useful. I'd = quite like to get a version of the website running on Linode to ensure = we stay working on it, so any scripting automation would also be useful. cheers, Anil > On 8 Dec 2014, at 19:54, Christopher Bothwell = wrote: >=20 > Hello,=20 >=20 > My name is Christopher. I'm a Linux admin, but I've been watching this = project for sometime and I'd like to get more involved with it.=20 >=20 > I'm not so proficient at coding and I'm looking for something small to = get more experience with the code base and how things are done. I did = notice the Pioneer Projects but the tasks as they stand now are a bit = daunting with reflection to what I know.=20 >=20 > https://github.com/mirage/mirage-www/wiki/Pioneer-Projects = >=20 > If there a particular project that has some bugs that someone could = point me in the direction of, that would be most appreciated. Mirage = seems like such a large project with many repositories and it makes it a = bit difficult to determine where I should be going.=20 >=20 > I also got a static blog set up on a Linode instance running a Mirage = unikernel. I wrote up a tutorial on how to do it. If someone wants to = try it out, I'd be curious to know if I was effective at communicating = how to get started with it.=20 >=20 > = http://christopherbothwell.com/ocaml/mirage/linode/2014/12/08/hello-linode= .html = >=20 > Thank you=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Christopher,

That's a splendid and easy to follow blog post about how to = swap in the Mirage kernel under Linode.  Figuring out the runes to = swap in a unikernel is often a big blocker to many people that don't = know Xen.

I'm = travelling right now, but will think through putting in more "1 star" = difficulty tasks to get started, as you're right that the ones there are = a bit large  (and I encourage everyone else on the list to do the = same for their own areas and take the time to add some pioneer = projects).

One = immediate point that comes up is that we need to capture information = like yours on the Mirage website, so a pull request that adds this = alongside the (very skeleton) EC2 information would be most useful. =  I'd quite like to get a version of the website running on Linode = to ensure we stay working on it, so any scripting automation would also = be useful.

cheers,
Anil

On = 8 Dec 2014, at 19:54, Christopher Bothwell <bothwell.christopher@gmail.com> wrote:

Hello,

My name is Christopher. = I'm a Linux admin, but I've been watching this project for sometime and = I'd like to get more involved with it.

I'm not so proficient at coding and I'm looking for = something small to get more experience with the code base and how things = are done. I did notice the Pioneer Projects but the tasks as they stand = now are a bit daunting with reflection to what I know.

https://github.com/mirage/mirage-www/wiki/Pioneer-Projects

If there a particular project that has some bugs that = someone could point me in the direction of, that would be most = appreciated. Mirage seems like such a large project with many = repositories and it makes it a bit difficult to determine where I should = be going.

I also got a static blog = set up on a Linode instance running a Mirage unikernel. I wrote up a = tutorial on how to do it. If someone wants to try it out, I'd be curious = to know if I was effective at communicating how to get started with it. =

http://christopherbothwell.com/ocaml/mirage/linode/2014/12/08/h= ello-linode.html

Thank you
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_EA25BD7B-EF55-46DB-B33B-AF5FB14B03BF-- --===============1360174694518879009== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1360174694518879009==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 08:49:50 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 08:49:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGUJ-0004yI-Qw; Tue, 09 Dec 2014 08:49:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGUI-0004y9-Bp for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 08:49:42 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 76/6E-01660-5A7B6845; Tue, 09 Dec 2014 08:49:41 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-206.messagelabs.com!1418114978!8156420!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29905 invoked from network); 9 Dec 2014 08:49:38 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 08:49:38 -0000 Received: from [10.192.4.255] (accoribisavitalie0145862650.pck.nerim.net [213.41.173.249]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 7d34656d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 08:55:06 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <548589E7.8070700@mehnert.org> Date: Tue, 9 Dec 2014 08:49:37 +0000 Message-Id: <3D5FE13B-4ACE-4F7A-A188-89952B6768DA@recoil.org> References: <548589E7.8070700@mehnert.org> To: Hannes Mehnert X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] talk at the 31st chaos communication congress about openmirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 8 Dec 2014, at 11:22, Hannes Mehnert wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384 > > hey, > > david kaloper and myself will present mirage (and especially crypto > and security protocols) at the 31st chaos communication congress > (27-30th december in hamburg, germany). > > a preliminary schedule is already published, find our description at > https://events.ccc.de/congress/2014/Fahrplan/events/6443.html Awesome! We should comfortably have out-of-the-box HTTPS by then I think. With Thomas Leonard's latest patchset that will become Mirage 2.1.1, and (I think) an associated nocrypto change to use xen_cflags, we should be good. https://github.com/mirage/mirage/pull/332 (See wider CHANGES here https://github.com/mirage/mirage/blob/master/CHANGES ) -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 08:49:50 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 08:49:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGUJ-0004yI-Qw; Tue, 09 Dec 2014 08:49:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGUI-0004y9-Bp for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 08:49:42 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 76/6E-01660-5A7B6845; Tue, 09 Dec 2014 08:49:41 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-206.messagelabs.com!1418114978!8156420!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29905 invoked from network); 9 Dec 2014 08:49:38 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 08:49:38 -0000 Received: from [10.192.4.255] (accoribisavitalie0145862650.pck.nerim.net [213.41.173.249]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 7d34656d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 08:55:06 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <548589E7.8070700@mehnert.org> Date: Tue, 9 Dec 2014 08:49:37 +0000 Message-Id: <3D5FE13B-4ACE-4F7A-A188-89952B6768DA@recoil.org> References: <548589E7.8070700@mehnert.org> To: Hannes Mehnert X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] talk at the 31st chaos communication congress about openmirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 8 Dec 2014, at 11:22, Hannes Mehnert wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384 > > hey, > > david kaloper and myself will present mirage (and especially crypto > and security protocols) at the 31st chaos communication congress > (27-30th december in hamburg, germany). > > a preliminary schedule is already published, find our description at > https://events.ccc.de/congress/2014/Fahrplan/events/6443.html Awesome! We should comfortably have out-of-the-box HTTPS by then I think. With Thomas Leonard's latest patchset that will become Mirage 2.1.1, and (I think) an associated nocrypto change to use xen_cflags, we should be good. https://github.com/mirage/mirage/pull/332 (See wider CHANGES here https://github.com/mirage/mirage/blob/master/CHANGES ) -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 09:18:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 09:18:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGwW-00074Z-1o; Tue, 09 Dec 2014 09:18:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGwU-00074A-PP for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:18:51 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id B9/66-26858-A7EB6845; Tue, 09 Dec 2014 09:18:50 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1418116727!9552426!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26978 invoked from network); 9 Dec 2014 09:18:48 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 09:18:48 -0000 Received: by mail-pa0-f45.google.com with SMTP id lj1so187978pab.32 for ; Tue, 09 Dec 2014 01:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kiAmwQQ6vVPvhcp++93p9mz4cRlhbJLgPRmFyOmAsQw=; b=HsnKHKnz+P9cq/Q276OyxTjw0CCFlUYI0N6W58rRpwxbKqulJFoYYOw87hcroTEN0C AkL6sz+OdfOCRWrrLIbAdENRyc0C2P7PItrb3rQ2GokvW3RKQj4dhgXaImXCCtaSt+MC tRcChU8CfmhXSsuUgi47CX2QxeEz8ljQoJPJ/pYZ/uq2OLEZZ0QMBfsJ9RPMH3qzowG1 9HV9P8XrUQMLKsxh8URcQMzaEe+EBICrmxPc79q19wJWanw9aYqEZqKOMz+Te5yHqN5p 0voNukY2fmanjKfBYruKjF4D33Uskud3Gp2EJaYRAQ3GBETq7waMn33YVFXmb0ZzVDsW riqQ== MIME-Version: 1.0 X-Received: by 10.68.131.163 with SMTP id on3mr3245281pbb.169.1418116726822; Tue, 09 Dec 2014 01:18:46 -0800 (PST) Received: by 10.70.93.65 with HTTP; Tue, 9 Dec 2014 01:18:46 -0800 (PST) In-Reply-To: <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> Date: Tue, 9 Dec 2014 09:18:46 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6110190774800233633==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6110190774800233633== Content-Type: multipart/alternative; boundary=001a11c35b88c09c2e0509c507fe --001a11c35b88c09c2e0509c507fe Content-Type: text/plain; charset=UTF-8 On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy wrote: > On 8 Dec 2014, at 10:48, Thomas Leonard wrote: > Building support for reading from a Xen guest requires xenstore > > support, which is also difficult to build (requires Xen headers), so > > that needs to be optional too. > > Dave might comment on this -- you shouldn't need the Xen headers > to build a simple Xenstore client. Maybe its the gnttab driver? > A simple Xenstore client shouldn't need the Xen headers in theory, although the current package might have an accidental dependency. As part of my yak shaving^W^Wimproving the Xen driver code I've been - functorising the core logic (e.g. of vchan) to remove any hard-coded Xen (or OS.) dependency - splitting the Xen kernel and Xen userspace implementations into separate sub-packages (I noticed that I also had to move the code into different source directories to make this work -- perhaps I confused OASIS?) So far I've - split xen-evtchn - split xen-gnt - functorised and split vchan - functorise the Xenstore client (now has a nicer interface IMHO) - functorised and split shared-memory-ring This allows a vchan Unix CLI to build and run on OS X. I've still got to - functorise and split mirage-net-xen (in progress) - functorise and split mirage-block-xen - teach the mirage tool how to instantiate the new functors Hopefully the mirage tool will be able to generate code like module XS = Xenstore.Client.Make(Xenstore_kernel_ring) (* where Xenstore_kernel_ring calls C stubs to get the ring and evtchn number *) module Block = Xenblock.Front.Make(Kernel_grants)(Kernel_events)(Xenblock.ConfigureFrom(XS)) The names of the modules and functors are a bit up-in-the-air. In particular I'm torn whether to use the Xen-jargon "Front(end)" and "Back(end)" everywhere or to just do what vchan does and use the more common terms "Client" and "Server". When this refactoring is done one of the nice things that falls out is a very easy way to write a dom0 daemon which watches Xenstore for domains arriving and leaving and connects to them (via vchan or console, whichever we like) and which could be the simple heart of an entropy daemon. Cheers, Dave --001a11c35b88c09c2e0509c507fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy &l= t;anil@recoil.org&= gt; wrote:
On 8 D= ec 2014, at 10:48, Thomas Leonard <t= alex5@gmail.com> wrote:
> Building support for reading from a Xen guest requires xenstore
> support, which is also difficult to build (requires Xen headers), so > that needs to be optional too.

Dave might comment on this -- you shouldn't need the Xen headers=
to build a simple Xenstore client.=C2=A0 Maybe its the gnttab driver?

A simple Xenstore client shouldn't need = the Xen headers in theory, although the current package might have an accid= ental dependency. As part of my yak shaving^W^Wimproving the Xen driver cod= e I've been

- functorising the core logic (e.g= . of vchan) to remove any hard-coded Xen (or OS.) dependency
- sp= litting the Xen kernel and Xen userspace implementations into separate sub-= packages (I noticed that I also had to move the code into different source = directories to make this work -- perhaps I confused OASIS?)

<= /div>
So far I've

- split xen-evtchn
=
- split xen-gnt
- functorised and split vchan
- fu= nctorise the Xenstore client (now has a nicer interface IMHO)
- f= unctorised and split shared-memory-ring

This allow= s a vchan Unix CLI to build and run on OS X. I've still got to

- functorise and split mirage-net-xen (in progress)
<= div>- functorise and split mirage-block-xen
- teach the mirage to= ol how to instantiate the new functors

Hopefully t= he mirage tool will be able to generate code like

= module XS =3D Xenstore.Client.Make(Xenstore_kernel_ring)
=C2=A0 (= * where Xenstore_kernel_ring calls C stubs to get the ring and evtchn numbe= r *)

module Block =3D Xenblock.Front.Make(Kernel_g= rants)(Kernel_events)(Xenblock.ConfigureFrom(XS))

= The names of the modules and functors are a bit up-in-the-air. In particula= r I'm torn whether to use the Xen-jargon "Front(end)" and &qu= ot;Back(end)" everywhere or to just do what vchan does and use the mor= e common terms "Client" and "Server".

When this refactoring is done one of the nice things that falls out= is a very easy way to write a dom0 daemon which watches Xenstore for domai= ns arriving and leaving and connects to them (via vchan or console, whichev= er we like) and which could be the simple heart of an entropy daemon.
=

Cheers,
Dave

--001a11c35b88c09c2e0509c507fe-- --===============6110190774800233633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6110190774800233633==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 09:18:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 09:18:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGwW-00074Z-1o; Tue, 09 Dec 2014 09:18:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyGwU-00074A-PP for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 09:18:51 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id B9/66-26858-A7EB6845; Tue, 09 Dec 2014 09:18:50 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1418116727!9552426!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26978 invoked from network); 9 Dec 2014 09:18:48 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 09:18:48 -0000 Received: by mail-pa0-f45.google.com with SMTP id lj1so187978pab.32 for ; Tue, 09 Dec 2014 01:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kiAmwQQ6vVPvhcp++93p9mz4cRlhbJLgPRmFyOmAsQw=; b=HsnKHKnz+P9cq/Q276OyxTjw0CCFlUYI0N6W58rRpwxbKqulJFoYYOw87hcroTEN0C AkL6sz+OdfOCRWrrLIbAdENRyc0C2P7PItrb3rQ2GokvW3RKQj4dhgXaImXCCtaSt+MC tRcChU8CfmhXSsuUgi47CX2QxeEz8ljQoJPJ/pYZ/uq2OLEZZ0QMBfsJ9RPMH3qzowG1 9HV9P8XrUQMLKsxh8URcQMzaEe+EBICrmxPc79q19wJWanw9aYqEZqKOMz+Te5yHqN5p 0voNukY2fmanjKfBYruKjF4D33Uskud3Gp2EJaYRAQ3GBETq7waMn33YVFXmb0ZzVDsW riqQ== MIME-Version: 1.0 X-Received: by 10.68.131.163 with SMTP id on3mr3245281pbb.169.1418116726822; Tue, 09 Dec 2014 01:18:46 -0800 (PST) Received: by 10.70.93.65 with HTTP; Tue, 9 Dec 2014 01:18:46 -0800 (PST) In-Reply-To: <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> Date: Tue, 9 Dec 2014 09:18:46 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6110190774800233633==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6110190774800233633== Content-Type: multipart/alternative; boundary=001a11c35b88c09c2e0509c507fe --001a11c35b88c09c2e0509c507fe Content-Type: text/plain; charset=UTF-8 On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy wrote: > On 8 Dec 2014, at 10:48, Thomas Leonard wrote: > Building support for reading from a Xen guest requires xenstore > > support, which is also difficult to build (requires Xen headers), so > > that needs to be optional too. > > Dave might comment on this -- you shouldn't need the Xen headers > to build a simple Xenstore client. Maybe its the gnttab driver? > A simple Xenstore client shouldn't need the Xen headers in theory, although the current package might have an accidental dependency. As part of my yak shaving^W^Wimproving the Xen driver code I've been - functorising the core logic (e.g. of vchan) to remove any hard-coded Xen (or OS.) dependency - splitting the Xen kernel and Xen userspace implementations into separate sub-packages (I noticed that I also had to move the code into different source directories to make this work -- perhaps I confused OASIS?) So far I've - split xen-evtchn - split xen-gnt - functorised and split vchan - functorise the Xenstore client (now has a nicer interface IMHO) - functorised and split shared-memory-ring This allows a vchan Unix CLI to build and run on OS X. I've still got to - functorise and split mirage-net-xen (in progress) - functorise and split mirage-block-xen - teach the mirage tool how to instantiate the new functors Hopefully the mirage tool will be able to generate code like module XS = Xenstore.Client.Make(Xenstore_kernel_ring) (* where Xenstore_kernel_ring calls C stubs to get the ring and evtchn number *) module Block = Xenblock.Front.Make(Kernel_grants)(Kernel_events)(Xenblock.ConfigureFrom(XS)) The names of the modules and functors are a bit up-in-the-air. In particular I'm torn whether to use the Xen-jargon "Front(end)" and "Back(end)" everywhere or to just do what vchan does and use the more common terms "Client" and "Server". When this refactoring is done one of the nice things that falls out is a very easy way to write a dom0 daemon which watches Xenstore for domains arriving and leaving and connects to them (via vchan or console, whichever we like) and which could be the simple heart of an entropy daemon. Cheers, Dave --001a11c35b88c09c2e0509c507fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy &l= t;anil@recoil.org&= gt; wrote:
On 8 D= ec 2014, at 10:48, Thomas Leonard <t= alex5@gmail.com> wrote:
> Building support for reading from a Xen guest requires xenstore
> support, which is also difficult to build (requires Xen headers), so > that needs to be optional too.

Dave might comment on this -- you shouldn't need the Xen headers=
to build a simple Xenstore client.=C2=A0 Maybe its the gnttab driver?

A simple Xenstore client shouldn't need = the Xen headers in theory, although the current package might have an accid= ental dependency. As part of my yak shaving^W^Wimproving the Xen driver cod= e I've been

- functorising the core logic (e.g= . of vchan) to remove any hard-coded Xen (or OS.) dependency
- sp= litting the Xen kernel and Xen userspace implementations into separate sub-= packages (I noticed that I also had to move the code into different source = directories to make this work -- perhaps I confused OASIS?)

<= /div>
So far I've

- split xen-evtchn
=
- split xen-gnt
- functorised and split vchan
- fu= nctorise the Xenstore client (now has a nicer interface IMHO)
- f= unctorised and split shared-memory-ring

This allow= s a vchan Unix CLI to build and run on OS X. I've still got to

- functorise and split mirage-net-xen (in progress)
<= div>- functorise and split mirage-block-xen
- teach the mirage to= ol how to instantiate the new functors

Hopefully t= he mirage tool will be able to generate code like

= module XS =3D Xenstore.Client.Make(Xenstore_kernel_ring)
=C2=A0 (= * where Xenstore_kernel_ring calls C stubs to get the ring and evtchn numbe= r *)

module Block =3D Xenblock.Front.Make(Kernel_g= rants)(Kernel_events)(Xenblock.ConfigureFrom(XS))

= The names of the modules and functors are a bit up-in-the-air. In particula= r I'm torn whether to use the Xen-jargon "Front(end)" and &qu= ot;Back(end)" everywhere or to just do what vchan does and use the mor= e common terms "Client" and "Server".

When this refactoring is done one of the nice things that falls out= is a very easy way to write a dom0 daemon which watches Xenstore for domai= ns arriving and leaving and connects to them (via vchan or console, whichev= er we like) and which could be the simple heart of an entropy daemon.
=

Cheers,
Dave

--001a11c35b88c09c2e0509c507fe-- --===============6110190774800233633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6110190774800233633==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 10:26:00 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 10:26:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyHzM-0002DU-Ex; Tue, 09 Dec 2014 10:25:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyHzK-0002DM-Jp for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 10:25:50 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 52/FD-27785-E2EC6845; Tue, 09 Dec 2014 10:25:50 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1418120748!13795097!1 X-Originating-IP: [209.85.220.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23250 invoked from network); 9 Dec 2014 10:25:49 -0000 Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 10:25:49 -0000 Received: by mail-vc0-f172.google.com with SMTP id hq11so123365vcb.17 for ; Tue, 09 Dec 2014 02:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uLwXhaiHRl8zbHLfz2eazMah254lPangQLign5OKX2c=; b=tKsQj2vM9ob/iiR13qJ/bTkreYrUtpEa+aooZxPr1CFmMNbUuM4AZansyy2/PzKJJ3 kaDXtM8Nhtqh0j+N58ZxtEdt6PqmhsndoHezgk6FmqMIQ2wLw2mmIuQnzcvwrWSOmxrh 8k2ZCFRQ4c43nGb/z9bn4x1EC9gTTA+RQSWdSXTRMgGAZDItw+j5P4r3YbMcoT+ZClaS 3Yeov7oAwOZFaS4Cx+i0GD7yoWXTrsBw3mcS0TTkNg93eG+ZbreXmqERE5H3hi6OBmIX nZOUlpm+fJ/tzsijpMSUq8oAD1GNvg0wo1fn22G1HTYmpYwKPinooF11TqDbtGr//MsK bEYg== MIME-Version: 1.0 X-Received: by 10.53.13.204 with SMTP id fa12mr689655vdd.16.1418120747872; Tue, 09 Dec 2014 02:25:47 -0800 (PST) Received: by 10.31.183.134 with HTTP; Tue, 9 Dec 2014 02:25:47 -0800 (PST) In-Reply-To: References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> Date: Tue, 9 Dec 2014 10:25:47 +0000 Message-ID: From: Thomas Leonard To: David Scott Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 9 December 2014 at 09:18, David Scott wrote: > > > On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy wrote: >> >> On 8 Dec 2014, at 10:48, Thomas Leonard wrote: >> >> > Building support for reading from a Xen guest requires xenstore >> > support, which is also difficult to build (requires Xen headers), so >> > that needs to be optional too. >> >> Dave might comment on this -- you shouldn't need the Xen headers >> to build a simple Xenstore client. Maybe its the gnttab driver? Ah yes, looks like it's "xen-gnt.unix" I need. Without that, I get lots of link errors, e.g. /home/tal/.opam/4.01.0/build/xen-gnt.2.0.0/_build/lib/gnt.ml:105: undefined reference to `stub_gnttab_map_onto' I can't see a direct way to control whether xen-gnt.unix gets built. It seems it only gets built if the Xen headers are present. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 10:26:00 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 10:26:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyHzM-0002DU-Ex; Tue, 09 Dec 2014 10:25:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyHzK-0002DM-Jp for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 10:25:50 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 52/FD-27785-E2EC6845; Tue, 09 Dec 2014 10:25:50 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1418120748!13795097!1 X-Originating-IP: [209.85.220.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23250 invoked from network); 9 Dec 2014 10:25:49 -0000 Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 10:25:49 -0000 Received: by mail-vc0-f172.google.com with SMTP id hq11so123365vcb.17 for ; Tue, 09 Dec 2014 02:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uLwXhaiHRl8zbHLfz2eazMah254lPangQLign5OKX2c=; b=tKsQj2vM9ob/iiR13qJ/bTkreYrUtpEa+aooZxPr1CFmMNbUuM4AZansyy2/PzKJJ3 kaDXtM8Nhtqh0j+N58ZxtEdt6PqmhsndoHezgk6FmqMIQ2wLw2mmIuQnzcvwrWSOmxrh 8k2ZCFRQ4c43nGb/z9bn4x1EC9gTTA+RQSWdSXTRMgGAZDItw+j5P4r3YbMcoT+ZClaS 3Yeov7oAwOZFaS4Cx+i0GD7yoWXTrsBw3mcS0TTkNg93eG+ZbreXmqERE5H3hi6OBmIX nZOUlpm+fJ/tzsijpMSUq8oAD1GNvg0wo1fn22G1HTYmpYwKPinooF11TqDbtGr//MsK bEYg== MIME-Version: 1.0 X-Received: by 10.53.13.204 with SMTP id fa12mr689655vdd.16.1418120747872; Tue, 09 Dec 2014 02:25:47 -0800 (PST) Received: by 10.31.183.134 with HTTP; Tue, 9 Dec 2014 02:25:47 -0800 (PST) In-Reply-To: References: <45369DDD-6234-436C-A79B-33F559D1EB4C@recoil.org> <91061958-EC6C-4290-B01E-AD6F82113B44@recoil.org> Date: Tue, 9 Dec 2014 10:25:47 +0000 Message-ID: From: Thomas Leonard To: David Scott Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Mirage tracing status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 9 December 2014 at 09:18, David Scott wrote: > > > On Mon, Dec 8, 2014 at 11:05 PM, Anil Madhavapeddy wrote: >> >> On 8 Dec 2014, at 10:48, Thomas Leonard wrote: >> >> > Building support for reading from a Xen guest requires xenstore >> > support, which is also difficult to build (requires Xen headers), so >> > that needs to be optional too. >> >> Dave might comment on this -- you shouldn't need the Xen headers >> to build a simple Xenstore client. Maybe its the gnttab driver? Ah yes, looks like it's "xen-gnt.unix" I need. Without that, I get lots of link errors, e.g. /home/tal/.opam/4.01.0/build/xen-gnt.2.0.0/_build/lib/gnt.ml:105: undefined reference to `stub_gnttab_map_onto' I can't see a direct way to control whether xen-gnt.unix gets built. It seems it only gets built if the Xen headers are present. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 11:16:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 11:16:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyImT-0005Oa-Cb; Tue, 09 Dec 2014 11:16:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyImS-0005OV-3N for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:16:36 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 66/3A-02957-31AD6845; Tue, 09 Dec 2014 11:16:35 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-27.messagelabs.com!1418123794!13903489!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22135 invoked from network); 9 Dec 2014 11:16:34 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 11:16:34 -0000 Received: from [IPv6:2002:805d:3c4f::d467:7df2:1dc6:156a] (2002:805d:3c4f:0:d467:7df2:1dc6:156a [IPv6:2002:805d:3c4f:0:d467:7df2:1dc6:156a]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0c7061b2; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 11:22:02 +0000 (GMT) From: Anil Madhavapeddy Date: Tue, 9 Dec 2014 11:16:33 +0000 Message-Id: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> To: opam-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: [MirageOS-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 11:16:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 11:16:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyImT-0005Oa-Cb; Tue, 09 Dec 2014 11:16:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyImS-0005OV-3N for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:16:36 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 66/3A-02957-31AD6845; Tue, 09 Dec 2014 11:16:35 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-27.messagelabs.com!1418123794!13903489!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22135 invoked from network); 9 Dec 2014 11:16:34 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 11:16:34 -0000 Received: from [IPv6:2002:805d:3c4f::d467:7df2:1dc6:156a] (2002:805d:3c4f:0:d467:7df2:1dc6:156a [IPv6:2002:805d:3c4f:0:d467:7df2:1dc6:156a]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0c7061b2; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 11:22:02 +0000 (GMT) From: Anil Madhavapeddy Date: Tue, 9 Dec 2014 11:16:33 +0000 Message-Id: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> To: opam-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: [MirageOS-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 11:52:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 11:52:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyJLD-0008Bm-MQ; Tue, 09 Dec 2014 11:52:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyJLC-0008Bg-8x for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:52:30 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 44/83-05632-D72E6845; Tue, 09 Dec 2014 11:52:29 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1418125948!12054434!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17960 invoked from network); 9 Dec 2014 11:52:28 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 11:52:28 -0000 Received: by mail-la0-f46.google.com with SMTP id q1so356650lam.5 for ; Tue, 09 Dec 2014 03:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BH4Uo/+p/uEe47G+ODVF++dnexgHK+J6qQWWX8ZVKAw=; b=cNe+96uWbUPVepHjK+WdXCypVnRUKEGvZkl42TRycTKJhSoWGygIOREfRBeNoLsvN7 Qu96AA73aPnU0vkU5Ci6YLGcAQk6n6dyZmxqg3Ljvvj1qhO0acoFqp5O+CSszT9Glbwi SMUZQHBXTSfyFtiS6CpZBO36Yq47p6y2RskXTM0kcgSJgOFxfi/J4meR5gE1gyV+NzWT 0+EMZWHMMksLZtDqspbfckmDc3Su2Q6H4A71d7eSKrd5ktNqN5YtdBbTq8ow51vkCXJW CSUV+4f3mXS0pSa2tWj0SITAqYaUhQUK5vTMLgTXKgFUekLcfzrGVQF6UcSiQLmaLlm0 HfFg== MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr21257131lac.19.1418125947897; Tue, 09 Dec 2014 03:52:27 -0800 (PST) Received: by 10.112.202.197 with HTTP; Tue, 9 Dec 2014 03:52:27 -0800 (PST) In-Reply-To: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> Date: Tue, 9 Dec 2014 19:52:27 +0800 Message-ID: From: Luke Dunstan To: Anil Madhavapeddy Cc: opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4896827810183031156==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4896827810183031156== Content-Type: multipart/alternative; boundary=001a113409d45f0e240509c72df2 --001a113409d45f0e240509c72df2 Content-Type: text/plain; charset=UTF-8 I haven't had to do it before, but I would try running "apport-bug opam" on the failing machine. Or one of these email addresses: $ apt-cache show opam ... Maintainer: Ubuntu Developers Original-Maintainer: Debian OCaml Maintainers < debian-ocaml-maint@lists.debian.org> ... $ apt-cache show aspcud ... Maintainer: Ubuntu Developers Original-Maintainer: Ralf Treinen ... Luke On 9 December 2014 at 19:16, Anil Madhavapeddy wrote: > It looks like the latest Ubuntu has a completely broken OPAM out of the > box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 > due to a changed solver interface). > > This leads to issues such as this: > https://github.com/mirage/mirage-skeleton/issues/59 > > Does anyone know how to get in touch with Ubuntu folk to request a > backport of OPAM 1.2 to Ubuntu 14.10? > > -anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a113409d45f0e240509c72df2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't had to do it before, but I would try ru= nning "apport-bug opam" on the failing machine.

Or one of these email addresses:

$ apt-cac= he show opam
...
Maintainer: Ubuntu Developers <= ;ubuntu-devel-disc= uss@lists.ubuntu.com>
Original-Maintainer: Debian OCaml Ma= intainers <debian= -ocaml-maint@lists.debian.org>
...

$ apt-cache show aspcud
...
Maintainer: Ub= untu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Main= tainer: Ralf Treinen <treinen@debi= an.org>
...


= Luke


On 9 December 2014 at 19:16, Anil Madhavapeddy <anil@recoil.or= g> wrote:
It looks like the= latest Ubuntu has a completely broken OPAM out of the box since it ships w= ith OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed sol= ver interface).

This leads to issues such as this: https://github.com/mirage/mirage-= skeleton/issues/59

Does anyone know how to get in touch with Ubuntu folk to request a backport= of OPAM 1.2 to Ubuntu 14.10?

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a113409d45f0e240509c72df2-- --===============4896827810183031156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4896827810183031156==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 11:52:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 11:52:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyJLD-0008Bm-MQ; Tue, 09 Dec 2014 11:52:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyJLC-0008Bg-8x for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 11:52:30 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 44/83-05632-D72E6845; Tue, 09 Dec 2014 11:52:29 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1418125948!12054434!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17960 invoked from network); 9 Dec 2014 11:52:28 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 11:52:28 -0000 Received: by mail-la0-f46.google.com with SMTP id q1so356650lam.5 for ; Tue, 09 Dec 2014 03:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BH4Uo/+p/uEe47G+ODVF++dnexgHK+J6qQWWX8ZVKAw=; b=cNe+96uWbUPVepHjK+WdXCypVnRUKEGvZkl42TRycTKJhSoWGygIOREfRBeNoLsvN7 Qu96AA73aPnU0vkU5Ci6YLGcAQk6n6dyZmxqg3Ljvvj1qhO0acoFqp5O+CSszT9Glbwi SMUZQHBXTSfyFtiS6CpZBO36Yq47p6y2RskXTM0kcgSJgOFxfi/J4meR5gE1gyV+NzWT 0+EMZWHMMksLZtDqspbfckmDc3Su2Q6H4A71d7eSKrd5ktNqN5YtdBbTq8ow51vkCXJW CSUV+4f3mXS0pSa2tWj0SITAqYaUhQUK5vTMLgTXKgFUekLcfzrGVQF6UcSiQLmaLlm0 HfFg== MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr21257131lac.19.1418125947897; Tue, 09 Dec 2014 03:52:27 -0800 (PST) Received: by 10.112.202.197 with HTTP; Tue, 9 Dec 2014 03:52:27 -0800 (PST) In-Reply-To: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> Date: Tue, 9 Dec 2014 19:52:27 +0800 Message-ID: From: Luke Dunstan To: Anil Madhavapeddy Cc: opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4896827810183031156==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4896827810183031156== Content-Type: multipart/alternative; boundary=001a113409d45f0e240509c72df2 --001a113409d45f0e240509c72df2 Content-Type: text/plain; charset=UTF-8 I haven't had to do it before, but I would try running "apport-bug opam" on the failing machine. Or one of these email addresses: $ apt-cache show opam ... Maintainer: Ubuntu Developers Original-Maintainer: Debian OCaml Maintainers < debian-ocaml-maint@lists.debian.org> ... $ apt-cache show aspcud ... Maintainer: Ubuntu Developers Original-Maintainer: Ralf Treinen ... Luke On 9 December 2014 at 19:16, Anil Madhavapeddy wrote: > It looks like the latest Ubuntu has a completely broken OPAM out of the > box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 > due to a changed solver interface). > > This leads to issues such as this: > https://github.com/mirage/mirage-skeleton/issues/59 > > Does anyone know how to get in touch with Ubuntu folk to request a > backport of OPAM 1.2 to Ubuntu 14.10? > > -anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --001a113409d45f0e240509c72df2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't had to do it before, but I would try ru= nning "apport-bug opam" on the failing machine.

Or one of these email addresses:

$ apt-cac= he show opam
...
Maintainer: Ubuntu Developers <= ;ubuntu-devel-disc= uss@lists.ubuntu.com>
Original-Maintainer: Debian OCaml Ma= intainers <debian= -ocaml-maint@lists.debian.org>
...

$ apt-cache show aspcud
...
Maintainer: Ub= untu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Main= tainer: Ralf Treinen <treinen@debi= an.org>
...


= Luke


On 9 December 2014 at 19:16, Anil Madhavapeddy <anil@recoil.or= g> wrote:
It looks like the= latest Ubuntu has a completely broken OPAM out of the box since it ships w= ith OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed sol= ver interface).

This leads to issues such as this: https://github.com/mirage/mirage-= skeleton/issues/59

Does anyone know how to get in touch with Ubuntu folk to request a backport= of OPAM 1.2 to Ubuntu 14.10?

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a113409d45f0e240509c72df2-- --===============4896827810183031156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4896827810183031156==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 20:28:24 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 20:28:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyROM-0001s9-Rr; Tue, 09 Dec 2014 20:28:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyROL-0001rx-C7 for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:28:17 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id FB/95-09842-06B57845; Tue, 09 Dec 2014 20:28:16 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1418156895!11072241!1 X-Originating-IP: [209.85.215.48] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10926 invoked from network); 9 Dec 2014 20:28:15 -0000 Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 20:28:15 -0000 Received: by mail-la0-f48.google.com with SMTP id gf13so1211229lab.7 for ; Tue, 09 Dec 2014 12:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=z1f+1GPdq248VpqpcAfOdu6/FjFapjuaz0kpl3XssTo=; b=02oNftRWLKSCUXm8qRAKhurwEsG7i6ABVpXgTlBoYkbaAULalcXMDjk30KlUFKhM1M tsMPxIyjDenpJe/lRc7LwzNX+l9LZyBPcRXQ1umkndFzeRBaF/Vh58y4NnDsenMJXFCM iLsUWyDGf7rF3+VAcVHhVgO1rNwen+xHr4R8bd+G2x+PX/rakJpdAgyJWMCdpbMNcJDR nODn5pHRjy+muGV+XmNibw3Ye/Vdu7vBnhAulMrMSr4YHvsHuEm85zrHZKEJqRaz8ma/ CGCncpiQn3/J6tYdl7cjbHoxLsQ37Fr2HwTp0zsX2LPEt/lnaLMvZ5WD7iJlYHpk7PSK NWGw== MIME-Version: 1.0 X-Received: by 10.152.4.233 with SMTP id n9mr236298lan.61.1418156895209; Tue, 09 Dec 2014 12:28:15 -0800 (PST) Received: by 10.112.252.167 with HTTP; Tue, 9 Dec 2014 12:28:15 -0800 (PST) Date: Tue, 9 Dec 2014 14:28:15 -0600 Message-ID: From: Brian Brietzke To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727652679109903918==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1727652679109903918== Content-Type: multipart/alternative; boundary=089e013d1198f98cde0509ce61c5 --089e013d1198f98cde0509ce61c5 Content-Type: text/plain; charset=UTF-8 First time in a while that I have tried to create a new mirage application, and noticing all the changes I decided to go through the documentation and work my way through things that way. I updated my local opam dependencies and noticed that 2.1 came out the door! Congrats guys! I tried to build the mirage-www and then the mirage-skeleton projects and I'm getting an build error. It tries to install mirage-net-macosx, which requires vmnet and fails. I know that vmnet requires Yosemite, which I have not migrated to and probably won't be until corporate approves the upgrade ( silly infosec ). So what can I do in the meantime to use the old unix networking with mavericks? --089e013d1198f98cde0509ce61c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First time in a while that I have tried to create a new mi= rage application, and noticing all the changes I decided to go through the = documentation and work my way through things that way.

I= updated my local opam dependencies and noticed that 2.1 came out the door!= Congrats guys!

I tried to build the mirage-www an= d then the mirage-skeleton projects and I'm getting an build error.=C2= =A0 It tries to install mirage-net-macosx, which requires vmnet and fails.= =C2=A0 I know that vmnet requires Yosemite, which I have not migrated to an= d probably won't be until corporate approves the upgrade ( silly infose= c ). =C2=A0

So what can I do in the meantime to us= e the old unix networking with mavericks? =C2=A0
--089e013d1198f98cde0509ce61c5-- --===============1727652679109903918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1727652679109903918==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 20:28:24 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 20:28:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyROM-0001s9-Rr; Tue, 09 Dec 2014 20:28:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyROL-0001rx-C7 for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:28:17 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id FB/95-09842-06B57845; Tue, 09 Dec 2014 20:28:16 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1418156895!11072241!1 X-Originating-IP: [209.85.215.48] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10926 invoked from network); 9 Dec 2014 20:28:15 -0000 Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 9 Dec 2014 20:28:15 -0000 Received: by mail-la0-f48.google.com with SMTP id gf13so1211229lab.7 for ; Tue, 09 Dec 2014 12:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=z1f+1GPdq248VpqpcAfOdu6/FjFapjuaz0kpl3XssTo=; b=02oNftRWLKSCUXm8qRAKhurwEsG7i6ABVpXgTlBoYkbaAULalcXMDjk30KlUFKhM1M tsMPxIyjDenpJe/lRc7LwzNX+l9LZyBPcRXQ1umkndFzeRBaF/Vh58y4NnDsenMJXFCM iLsUWyDGf7rF3+VAcVHhVgO1rNwen+xHr4R8bd+G2x+PX/rakJpdAgyJWMCdpbMNcJDR nODn5pHRjy+muGV+XmNibw3Ye/Vdu7vBnhAulMrMSr4YHvsHuEm85zrHZKEJqRaz8ma/ CGCncpiQn3/J6tYdl7cjbHoxLsQ37Fr2HwTp0zsX2LPEt/lnaLMvZ5WD7iJlYHpk7PSK NWGw== MIME-Version: 1.0 X-Received: by 10.152.4.233 with SMTP id n9mr236298lan.61.1418156895209; Tue, 09 Dec 2014 12:28:15 -0800 (PST) Received: by 10.112.252.167 with HTTP; Tue, 9 Dec 2014 12:28:15 -0800 (PST) Date: Tue, 9 Dec 2014 14:28:15 -0600 Message-ID: From: Brian Brietzke To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727652679109903918==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1727652679109903918== Content-Type: multipart/alternative; boundary=089e013d1198f98cde0509ce61c5 --089e013d1198f98cde0509ce61c5 Content-Type: text/plain; charset=UTF-8 First time in a while that I have tried to create a new mirage application, and noticing all the changes I decided to go through the documentation and work my way through things that way. I updated my local opam dependencies and noticed that 2.1 came out the door! Congrats guys! I tried to build the mirage-www and then the mirage-skeleton projects and I'm getting an build error. It tries to install mirage-net-macosx, which requires vmnet and fails. I know that vmnet requires Yosemite, which I have not migrated to and probably won't be until corporate approves the upgrade ( silly infosec ). So what can I do in the meantime to use the old unix networking with mavericks? --089e013d1198f98cde0509ce61c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First time in a while that I have tried to create a new mi= rage application, and noticing all the changes I decided to go through the = documentation and work my way through things that way.

I= updated my local opam dependencies and noticed that 2.1 came out the door!= Congrats guys!

I tried to build the mirage-www an= d then the mirage-skeleton projects and I'm getting an build error.=C2= =A0 It tries to install mirage-net-macosx, which requires vmnet and fails.= =C2=A0 I know that vmnet requires Yosemite, which I have not migrated to an= d probably won't be until corporate approves the upgrade ( silly infose= c ). =C2=A0

So what can I do in the meantime to us= e the old unix networking with mavericks? =C2=A0
--089e013d1198f98cde0509ce61c5-- --===============1727652679109903918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1727652679109903918==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 20:45:14 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 20:45:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyRej-0002TJ-MI; Tue, 09 Dec 2014 20:45:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyRei-0002TE-NI for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:45:12 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id 73/77-02702-85F57845; Tue, 09 Dec 2014 20:45:12 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1418157911!14026931!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12687 invoked from network); 9 Dec 2014 20:45:11 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 20:45:11 -0000 Received: from [10.170.6.10] (dab-rcn1-h-85-7.dab.02.net [82.132.246.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id efd41092; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 20:50:38 +0000 (GMT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> X-Mailer: iPhone Mail (12B435) From: Anil Madhavapeddy Date: Tue, 9 Dec 2014 21:44:48 +0100 To: Brian Brietzke Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Aha! I thought of you and put in a "--target=unix" option that will force the use of Unix mode even when on MacOS X. So just do "mirage configure -t unix" for the old behaviour. What is the output of your "uname -a"? I can put a smarter check into mirage to not need this on older MacOS X. Anil > On 9 Dec 2014, at 21:28, Brian Brietzke wrote: > > First time in a while that I have tried to create a new mirage application, and noticing all the changes I decided to go through the documentation and work my way through things that way. > > I updated my local opam dependencies and noticed that 2.1 came out the door! Congrats guys! > > I tried to build the mirage-www and then the mirage-skeleton projects and I'm getting an build error. It tries to install mirage-net-macosx, which requires vmnet and fails. I know that vmnet requires Yosemite, which I have not migrated to and probably won't be until corporate approves the upgrade ( silly infosec ). > > So what can I do in the meantime to use the old unix networking with mavericks? > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 20:45:14 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 20:45:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyRej-0002TJ-MI; Tue, 09 Dec 2014 20:45:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyRei-0002TE-NI for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 20:45:12 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id 73/77-02702-85F57845; Tue, 09 Dec 2014 20:45:12 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1418157911!14026931!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12687 invoked from network); 9 Dec 2014 20:45:11 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2014 20:45:11 -0000 Received: from [10.170.6.10] (dab-rcn1-h-85-7.dab.02.net [82.132.246.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id efd41092; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 9 Dec 2014 20:50:38 +0000 (GMT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> X-Mailer: iPhone Mail (12B435) From: Anil Madhavapeddy Date: Tue, 9 Dec 2014 21:44:48 +0100 To: Brian Brietzke Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Aha! I thought of you and put in a "--target=unix" option that will force the use of Unix mode even when on MacOS X. So just do "mirage configure -t unix" for the old behaviour. What is the output of your "uname -a"? I can put a smarter check into mirage to not need this on older MacOS X. Anil > On 9 Dec 2014, at 21:28, Brian Brietzke wrote: > > First time in a while that I have tried to create a new mirage application, and noticing all the changes I decided to go through the documentation and work my way through things that way. > > I updated my local opam dependencies and noticed that 2.1 came out the door! Congrats guys! > > I tried to build the mirage-www and then the mirage-skeleton projects and I'm getting an build error. It tries to install mirage-net-macosx, which requires vmnet and fails. I know that vmnet requires Yosemite, which I have not migrated to and probably won't be until corporate approves the upgrade ( silly infosec ). > > So what can I do in the meantime to use the old unix networking with mavericks? > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 21:09:10 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 21:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyS1s-0003Ie-Sg; Tue, 09 Dec 2014 21:09:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyS1r-0003IW-TR for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 21:09:08 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 71/F5-02712-3F467845; Tue, 09 Dec 2014 21:09:07 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-16.tower-27.messagelabs.com!1418159346!8597501!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21244 invoked from network); 9 Dec 2014 21:09:06 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-16.tower-27.messagelabs.com with SMTP; 9 Dec 2014 21:09:06 -0000 Received: from [172.20.10.2] (139-236.197-178.cust.bluewin.ch [178.197.236.139]) by smtp.webfaction.com (Postfix) with ESMTP id BDA50207805F; Tue, 9 Dec 2014 21:09:01 +0000 (UTC) Date: Tue, 9 Dec 2014 22:08:57 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: <7DD57EE5694C46839EDBE8640256574A@erratique.ch> In-Reply-To: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> References: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Brian Brietzke , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbWFyZGksIDkgZMOpY2VtYnJlIDIwMTQgw6AgMjE6NDQsIEFuaWwgTWFkaGF2YXBlZGR5IGEg w6ljcml0IDoKPiBXaGF0IGlzIHRoZSBvdXRwdXQgb2YgeW91ciAidW5hbWUgLWEiPyBJIGNhbiBw dXQgYSBzbWFydGVyIGNoZWNrIGludG8gbWlyYWdlIHRvIG5vdCBuZWVkIHRoaXMgb24gb2xkZXIg TWFjT1MgWC4KCkNoZWNrIGB1bmFtZSAtcmAgPCAxNC4wLjAgIAoKQmVzdCwKCkRhbmllbAoKCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1k ZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vv cy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 09 21:09:10 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 09 Dec 2014 21:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyS1s-0003Ie-Sg; Tue, 09 Dec 2014 21:09:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyS1r-0003IW-TR for mirageos-devel@lists.xenproject.org; Tue, 09 Dec 2014 21:09:08 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 71/F5-02712-3F467845; Tue, 09 Dec 2014 21:09:07 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-16.tower-27.messagelabs.com!1418159346!8597501!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21244 invoked from network); 9 Dec 2014 21:09:06 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-16.tower-27.messagelabs.com with SMTP; 9 Dec 2014 21:09:06 -0000 Received: from [172.20.10.2] (139-236.197-178.cust.bluewin.ch [178.197.236.139]) by smtp.webfaction.com (Postfix) with ESMTP id BDA50207805F; Tue, 9 Dec 2014 21:09:01 +0000 (UTC) Date: Tue, 9 Dec 2014 22:08:57 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Anil Madhavapeddy Message-ID: <7DD57EE5694C46839EDBE8640256574A@erratique.ch> In-Reply-To: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> References: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: Brian Brietzke , "=?utf-8?Q?mirageos-devel=40lists.xenproject.org?=" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbWFyZGksIDkgZMOpY2VtYnJlIDIwMTQgw6AgMjE6NDQsIEFuaWwgTWFkaGF2YXBlZGR5IGEg w6ljcml0IDoKPiBXaGF0IGlzIHRoZSBvdXRwdXQgb2YgeW91ciAidW5hbWUgLWEiPyBJIGNhbiBw dXQgYSBzbWFydGVyIGNoZWNrIGludG8gbWlyYWdlIHRvIG5vdCBuZWVkIHRoaXMgb24gb2xkZXIg TWFjT1MgWC4KCkNoZWNrIGB1bmFtZSAtcmAgPCAxNC4wLjAgIAoKQmVzdCwKCkRhbmllbAoKCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1k ZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vv cy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 11:21:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 11:21:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyfKi-0001Mr-LM; Wed, 10 Dec 2014 11:21:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyfKh-0001Mm-OE for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 11:21:27 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 92/E6-02953-6BC28845; Wed, 10 Dec 2014 11:21:26 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1418210486!14153946!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32116 invoked from network); 10 Dec 2014 11:21:26 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 11:21:26 -0000 Received: from [192.168.15.121] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id fc775e4a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 11:26:56 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <7DD57EE5694C46839EDBE8640256574A@erratique.ch> Date: Wed, 10 Dec 2014 11:21:25 +0000 Message-Id: <09A9377F-AC63-444F-82A9-D1B200DBE56F@recoil.org> References: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> <7DD57EE5694C46839EDBE8640256574A@erratique.ch> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: Brian Brietzke , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gOSBEZWMgMjAxNCwgYXQgMjE6MDgsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBl cnJhdGlxdWUuY2g+IHdyb3RlOgo+IAo+IExlIG1hcmRpLCA5IGTDqWNlbWJyZSAyMDE0IMOgIDIx OjQ0LCBBbmlsIE1hZGhhdmFwZWRkeSBhIMOpY3JpdCA6Cj4+IFdoYXQgaXMgdGhlIG91dHB1dCBv ZiB5b3VyICJ1bmFtZSAtYSI/IEkgY2FuIHB1dCBhIHNtYXJ0ZXIgY2hlY2sgaW50byBtaXJhZ2Ug dG8gbm90IG5lZWQgdGhpcyBvbiBvbGRlciBNYWNPUyBYLgo+IAo+IENoZWNrIGB1bmFtZSAtcmAg PCAxNC4wLjAgIAo+IAoKVGhhbmtzIC0tIG5vdyBkb25lIGluOgoKaHR0cHM6Ly9naXRodWIuY29t L21pcmFnZS9taXJhZ2UvcHVsbC8zMzcKCihJZiBhbnlvbmUgdHJpZXMgdGhpcyBvbiBhbiBvbGRl ciBPU1ggbGV0IG1lIGtub3csIGJ1dCBpdCBzaG91bGQgYmUgbm8gd29yc2UKdGhhbiB3aGF0IHdl IGRvIHJpZ2h0IG5vdyBzbyBJJ2xsIGp1c3QgZ28gYWhlYWQgaWYgSSBkb24ndCBnZXQgYW55IHJl cG9ydHMpLgoKVGhlIHBhdGNoIGFsc28gcHJpbnRzIG91dCB0aGUgc2VsZWN0ZWQgdGFyZ2V0IG1v ZGUgb24gdGhlIGNvbnNvbGUgbm93IHNvIGl0J3MKbW9yZSBvYnZpb3VzIHdoYXQgaXMgZ29pbmcg b24uCgotYW5pbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5w cm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xp c3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 11:21:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 11:21:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyfKi-0001Mr-LM; Wed, 10 Dec 2014 11:21:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyfKh-0001Mm-OE for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 11:21:27 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 92/E6-02953-6BC28845; Wed, 10 Dec 2014 11:21:26 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1418210486!14153946!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32116 invoked from network); 10 Dec 2014 11:21:26 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 11:21:26 -0000 Received: from [192.168.15.121] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id fc775e4a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 11:26:56 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <7DD57EE5694C46839EDBE8640256574A@erratique.ch> Date: Wed, 10 Dec 2014 11:21:25 +0000 Message-Id: <09A9377F-AC63-444F-82A9-D1B200DBE56F@recoil.org> References: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> <7DD57EE5694C46839EDBE8640256574A@erratique.ch> To: =?utf-8?Q?Daniel_B=C3=BCnzli?= X-Mailer: Apple Mail (2.1993) Cc: Brian Brietzke , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org T24gOSBEZWMgMjAxNCwgYXQgMjE6MDgsIERhbmllbCBCw7xuemxpIDxkYW5pZWwuYnVlbnpsaUBl cnJhdGlxdWUuY2g+IHdyb3RlOgo+IAo+IExlIG1hcmRpLCA5IGTDqWNlbWJyZSAyMDE0IMOgIDIx OjQ0LCBBbmlsIE1hZGhhdmFwZWRkeSBhIMOpY3JpdCA6Cj4+IFdoYXQgaXMgdGhlIG91dHB1dCBv ZiB5b3VyICJ1bmFtZSAtYSI/IEkgY2FuIHB1dCBhIHNtYXJ0ZXIgY2hlY2sgaW50byBtaXJhZ2Ug dG8gbm90IG5lZWQgdGhpcyBvbiBvbGRlciBNYWNPUyBYLgo+IAo+IENoZWNrIGB1bmFtZSAtcmAg PCAxNC4wLjAgIAo+IAoKVGhhbmtzIC0tIG5vdyBkb25lIGluOgoKaHR0cHM6Ly9naXRodWIuY29t L21pcmFnZS9taXJhZ2UvcHVsbC8zMzcKCihJZiBhbnlvbmUgdHJpZXMgdGhpcyBvbiBhbiBvbGRl ciBPU1ggbGV0IG1lIGtub3csIGJ1dCBpdCBzaG91bGQgYmUgbm8gd29yc2UKdGhhbiB3aGF0IHdl IGRvIHJpZ2h0IG5vdyBzbyBJJ2xsIGp1c3QgZ28gYWhlYWQgaWYgSSBkb24ndCBnZXQgYW55IHJl cG9ydHMpLgoKVGhlIHBhdGNoIGFsc28gcHJpbnRzIG91dCB0aGUgc2VsZWN0ZWQgdGFyZ2V0IG1v ZGUgb24gdGhlIGNvbnNvbGUgbm93IHNvIGl0J3MKbW9yZSBvYnZpb3VzIHdoYXQgaXMgZ29pbmcg b24uCgotYW5pbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5w cm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xp c3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 12:50:20 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 12:50:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xygif-0004rJ-5c; Wed, 10 Dec 2014 12:50:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xygid-0004rE-QF for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 12:50:16 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 04/3D-23865-78148845; Wed, 10 Dec 2014 12:50:15 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-31.messagelabs.com!1418215813!9906908!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21407 invoked from network); 10 Dec 2014 12:50:14 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 12:50:14 -0000 Received: from [192.168.15.121] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id e632468a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 12:55:44 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 10 Dec 2014 12:50:11 +0000 Message-Id: <9B61F8EA-A521-4677-964A-C9428BD31554@recoil.org> References: <06A02282-D888-4140-B8B4-EA55214BFD6D@recoil.org> To: =?utf-8?Q?Andr=C3=A9_N=C3=A6ss?= X-Mailer: Apple Mail (2.1993) Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Camlp4 Stack_overflow X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SnVzdCBhbiB1cGRhdGUgb24gdGhpczogSSd2ZSBhZGRlZCBjb2RlIHRvIHRoZSBNaXJhZ2UgQ0xJ IHRvIGV4Y2x1ZGUKPHN0YXRpY18qPiBmaWxlcyAoZ2VuZXJhdGVkIGJ5IGNydW5jaCkuICBJdCds bCBiZSBpbiBNaXJhZ2UgMi4xLjE6CgpodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFnZS9w dWxsLzMzOAoKLWFuaWwKCj4gT24gOCBNYXkgMjAxNCwgYXQgMTA6NTYsIEFuZHLDqSBOw6ZzcyA8 YW5kcmUubmFlc3NAZ21haWwuY29tPiB3cm90ZToKPiAKPiBJdCBsb29rZWQgbGlrZSB0aGUgc25p cHBldCBvZiBjb2RlIEkgaW5jbHVkZWQgaW4gdGhlIGZpcnN0IHBvc3QsCj4gZXhjZXB0IHdpdGgg MjUsMDAwIHJvd3MuCj4gCj4gVGhlIF90YWdzIGZpbGUgc29sdmVkIGl0IHRob3VnaC4gSSBleGNs dWRlZCB0aGUgZmlsZSBsaWtlIHRoaXM6Cj4gPFBiLio+Oi1zeW50YXgoY2FtbHA0bykKPiAKPiBX aXRoIHRoaXMgaW4gcGxhY2UgSSBzdWNjZXNzZnVsbHkgY29tcGlsZWQgNTAwSyBlbnRyaWVzIGlu IDFtMzBzCj4geWllbGRpbmcgYSAzM01CIC54ZW4gZmlsZS4KPiAKPiBJIGNhbiBjZXJ0YWlubHkg cG9zdCBhbiBpc3N1ZSBvbiB0aGUgY2FtbHA0IGdpdGh1YiBzaXRlIGFuZCBhdHRhY2ggYW4KPiBl eGFtcGxlIGZpbGUgaWYgeW91IHRoaW5rIHRoaXMgc2hvdWxkIHJlYXNvbmFibHkgd29yay4gSSB3 b3VsZG4ndAo+IHRoaW5rIHRoaXMgcmVwcmVzZW50IGEgY29tbW9uIHVzZWNhc2UgOykKPiAKPiBP biBUaHUsIE1heSA4LCAyMDE0IGF0IDEwOjMzIEFNLCBUaG9tYXMgR2F6YWduYWlyZQo+IDx0aG9t YXNAZ2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+PiBkbyB5b3UgaGF2ZSBhbiBleGFtcGxlIG9mIHdo YXQgdGhlIGdlbmVyYXRlZCBzb3VyY2UgZmlsZSBsb29rcyBsaWtlID8KPj4gCj4+IFdvdWxkIGJl IGludGVyZXN0aW5nIHRvIHJlcG9ydCB0aGUgYnVnIHVwc3RyZWFtOiBodHRwczovL2dpdGh1Yi5j b20vb2NhbWwvY2FtbHA0L2lzc3Vlcwo+PiAKPj4gVGhvbWFzCj4+IAo+PiBPbiA3IE1heSAyMDE0 LCBhdCAyMzozOCwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+ IAo+Pj4gVG8gYWRkcmVzcyB0aGUgY2FtbHA0IHByb2JsZW0sIHlvdSBjYW4gdXNlIHRoZSBfdGFn cyBmaWxlIHRvIG1hcmsganVzdAo+Pj4gdGhlIG9uZSBzb3VyY2UgZmlsZSBhcyBub3QgcGFzc2lu ZyB0aHJvdWdoIGNhbWxwNCAodmlhIGEgJy0nIHNvbWV3aGVyZQo+Pj4gdG8gcmVtb3ZlIHRoZSB0 YWcgLS0gd2lsbCBuZWVkIHRvIGxvb2sgdXAgdGhlIGRldGFpbHMgaW4gdGhlIG1hbnVhbCkuCj4+ PiAKPj4+IFRoZSBlYXNpZXN0IHdheSB0byBzb2x2ZSB5b3VyIHByb2JsZW0gd291bGQgYmUganVz dCB0byBoYXZlIGEgY3J1bmNoZWQKPj4+IGZpbGUgY29udGFpbmluZyB0aGUgaW5mb3JtYXRpb24g aW4gQ1NWIG9yIFMtZXhwcmVzc2lvbiBmb3JtYXQsIGFuZCB0aGVuCj4+PiByZWFkaW5nIGZyb20g aXQgYXQgYXBwbGljYXRpb24gc3RhcnR1cCB0aW1lIHRvIGluaXRpYWxpemUgeW91ciBhcnJheS4K Pj4+IAo+Pj4gVGhlICdjcnVuY2gnIG1vZGUgd291bGQgY29tcGlsZSBhbGwgdGhpcyBpbnRvIGEg c3RhbmRhbG9uZSBrZXJuZWwsIG9yCj4+PiBpbiBVbml4IG1vZGUgd291bGQgYmUgYSBmaWxlc3lz dGVtIHBhc3N0aHJvdWdoIGZvciBlYXNpZXIgZGV2ZWxvcG1lbnQuCj4+PiBBbnkgcmVhc29uIHlv dSB3YW50IGl0IHRvIGJlIGEgJ2hhbmQgd3JpdHRlbicgT0NhbWwgZmlsZT8KPj4+IAo+Pj4gLWFu aWwKPj4+IAo+Pj4gT24gNyBNYXkgMjAxNCwgYXQgMTQ6MDYsIEFuZHLDqSBOw6ZzcyA8YW5kcmUu bmFlc3NAZ21haWwuY29tPiB3cm90ZToKPj4+IAo+Pj4+IEkndmUgcmV3cml0dGVuIHRoZSBnZW5l cmF0ZWQgY29kZSBzbyB0aGF0IGl0IGNyZWF0ZXMgYW4gYXJyYXkgYW5kIHRoZW4KPj4+PiBhc3Np Z25zIHRvIGluZGV4ZXMgb2YgdGhlIGFycmF5LCBiYXRjaGluZyB0aGUgYXNzaWdubWVudHMgdXNp bmcKPj4+PiBtdWx0aXBsZSBsZXQgKCkgPQo+Pj4+IAo+Pj4+IENvbXBpbGF0aW9uIHNwZWVkIGlz IGEgcHJvYmxlbSwgYW5kIGl0IHN0aWxsIGZhbGxzIG92ZXIgYXQgNTBLIGVudHJpZXMuCj4+Pj4g Cj4+Pj4gSSBzdXBwb3NlIEkgY291bGQgc29tZWhvdyB3cml0ZSB0aGUgZGF0YSB0byBhbiBpbWFn ZSBhbmQgcmVhZCBpdCBiYWNrCj4+Pj4gaW4gYXQgYXBwbGljYXRpb24gc3RhcnR1cCwgYnV0IEkg dGhpbmsgSSBhY3R1YWxseSBsaWtlIG15IGN1cnJlbnQKPj4+PiBhcHByb2FjaC4gQWxsIG9mIHRo ZSB3b3JrIGlzIGRvbmUgYXQgY29tcGlsYXRpb24gdGltZS4gVGhlIHJvd3MgYXJlCj4+Pj4gd3Jp dHRlbiBpbiBzb3J0ZWQgb3JkZXIgc28gYSBzaW1wbGUgYmluYXJ5IHNlYXJjaCBjYW4gYmUgdXNl ZC4gVGhlCj4+Pj4gcmVzdWx0aW5nIGFwcGxpY2F0aW9uIGlzIGVudGlyZWx5IHNpbmdsZS1wdXJw b3NlZC4KPj4+PiAKPj4+PiBBbnkgaWRlYXMgZm9yIG90aGVyIHdheXMgdG8gZG8gdGhpcz8gQnlw YXNzIHRoZSBjb21waWxlciBhbmQgImNvbXBpbGUiCj4+Pj4gdGhlIGRhdGEgbXlzZWxmPyBEb2Vz IHRoZXJlIGV4aXN0IHRvb2xzIHRvIGRvIHNvbWV0aGluZyBsaWtlIHRoYXQ/Cj4+Pj4gCj4+Pj4g T24gV2VkLCBNYXkgNywgMjAxNCBhdCAxOjQwIFBNLCBBbmRyw6kgTsOmc3MgPGFuZHJlLm5hZXNz QGdtYWlsLmNvbT4gd3JvdGU6Cj4+Pj4+IEhpCj4+Pj4+IAo+Pj4+PiBJJ20gdHJ5aW5nIHNvbWV0 aGluZyB0aGF0IG1pZ2h0IGJlIGEgYml0IHNpbGx5IGJ1dCBpdCdzIGp1c3QgaW50ZW5kZWQKPj4+ Pj4gYXMgYW4gaW50ZXJuYWwgZGVtbyBvZiBNaXJhZ2UgdG8gbXkgdGVhbS4gSSdtIHdyaXRpbmcg YSB0aW55IEhUVFAKPj4+Pj4gYmFzZWQgYXBwbGljYXRpb24gd2hvc2Ugb25seSBwdXJwb3NlIGlz IHRvIGFsbG93IHlvdSB0byBzZWFyY2ggYSBwaG9uZQo+Pj4+PiBib29rLgo+Pj4+PiAKPj4+Pj4g SSd2ZSBiYXNlZCBteSBhcHByb2FjaCBvbiB0aGUgYXBwcm9hY2ggeW91J3ZlIHVzZWQgZm9yIHN0 YXRpYyB3ZWJzaXRlcwo+Pj4+PiB1c2luZyBjcnVuY2ggd2hlcmUgeW91IGNvbXBpbGUgdGhlIHdl YiBwYWdlcyBpbnRvIHRoZSBleGVjdXRhYmxlLiBJbgo+Pj4+PiBteSBjYXNlIHRoYXQgbWVhbnMg SSB0YWtlIHRoZSBsaXN0IG9mIG5hbWUgYW5kIG51bWJlciBwYWlycyBhbmQgc3R1ZmYKPj4+Pj4g dGhlbSBpbnRvIGFuIGFycmF5LiBTbyBwYXJ0IG9mIG15IGNvbmZpZy5tbCBmaWxlIGVtaXRzIGEg c2luZ2xlIFBiLm1sCj4+Pj4+IGZpbGUgd2hpY2ggY29udGFpbnMgYW4gYXJyYXkgZGVjbGFyYXRp b24gbGlrZSB0aGlzOgo+Pj4+PiAKPj4+Pj4gbGV0IGRiID0gW3woIkFhcm9uIEpha3NpYyIsMTU3 MTI2OCk7Cj4+Pj4+ICgiQWFyb24gTWNkaXZpdHQiLDE0NTQ2MjkpOwo+Pj4+PiAoIkFhcm9uIFJl dWJlbiIsMTc2NTI0Nyk7Cj4+Pj4+ICgiQWFyb24gU2FyZGluaGEiLDEyMjQ4MDYpOwo+Pj4+PiAo IkFiYmV5IEdvd2VucyIsMTI2NzA4Myk7Cj4+Pj4+ICgiQWJiZXkgSGF0aGNveCIsMTMwOTQ5MCk7 Cj4+Pj4+IC4uLgo+Pj4+PiAKPj4+Pj4gQXMgdGhlIHRpdGxlIHNheSBJJ20gcnVubmluZyBpbnRv IHByb2JsZW1zIGNvbXBpbGluZyB0aGlzIHdoZW4gSQo+Pj4+PiBjcmVhdGUgYSBsYXJnZSBwaG9u ZSBib29rLCB0aGUgZXJyb3IgYmVpbmc6Cj4+Pj4+IAo+Pj4+PiBDYW1scDQ6IFVuY2F1Z2h0IGV4 Y2VwdGlvbjogU3RhY2tfb3ZlcmZsb3cKPj4+Pj4gCj4+Pj4+IFRoaXMgaGFwcGVucyB3aXRoIDI1 SyBlbnRyaWVzLCBpdCB3b3JrcyB3aXRoIDEwSyBlbnRyaWVzLgo+Pj4+PiAKPj4+Pj4gSXMgdGhl cmUgc29tZSB3YXkgSSBjYW4gcHJldmVudCBDYW1scDQgZnJvbSBiZWluZyBydW4gb24gdGhlIFBi Lm1sCj4+Pj4+IGZpbGU/IE9yIHdpbGwgSSBqdXN0IGhhdmUgdG8gZ2VuZXJhdGUgYSBmaWxlIHRo YXQgYnVpbGRzIHRoZSBhcnJheSBhdAo+Pj4+PiBydW50aW1lIHNvbWVob3c/Cj4+Pj4+IAo+Pj4+ PiBBbmRyw6kKPj4+PiAKPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+Pj4+IE1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4+IE1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCj4+Pj4gaHR0cDovL2xpc3RzLnhlbnByb2plY3Qu b3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo+Pj4gCj4+PiAKPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBNaXJh Z2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKPj4+IE1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2pl Y3Qub3JnCj4+PiBodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xp c3RpbmZvL21pcmFnZW9zLWRldmVsCj4+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Cj4gTWly YWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKPiBodHRwOi8vbGlzdHMueGVucHJvamVj dC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFp bGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 12:50:20 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 12:50:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xygif-0004rJ-5c; Wed, 10 Dec 2014 12:50:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xygid-0004rE-QF for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 12:50:16 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 04/3D-23865-78148845; Wed, 10 Dec 2014 12:50:15 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-31.messagelabs.com!1418215813!9906908!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21407 invoked from network); 10 Dec 2014 12:50:14 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 12:50:14 -0000 Received: from [192.168.15.121] (no-dns-yet.demon.co.uk [62.49.66.12]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id e632468a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 12:55:44 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 10 Dec 2014 12:50:11 +0000 Message-Id: <9B61F8EA-A521-4677-964A-C9428BD31554@recoil.org> References: <06A02282-D888-4140-B8B4-EA55214BFD6D@recoil.org> To: =?utf-8?Q?Andr=C3=A9_N=C3=A6ss?= X-Mailer: Apple Mail (2.1993) Cc: Thomas Gazagnaire , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Camlp4 Stack_overflow X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SnVzdCBhbiB1cGRhdGUgb24gdGhpczogSSd2ZSBhZGRlZCBjb2RlIHRvIHRoZSBNaXJhZ2UgQ0xJ IHRvIGV4Y2x1ZGUKPHN0YXRpY18qPiBmaWxlcyAoZ2VuZXJhdGVkIGJ5IGNydW5jaCkuICBJdCds bCBiZSBpbiBNaXJhZ2UgMi4xLjE6CgpodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL21pcmFnZS9w dWxsLzMzOAoKLWFuaWwKCj4gT24gOCBNYXkgMjAxNCwgYXQgMTA6NTYsIEFuZHLDqSBOw6ZzcyA8 YW5kcmUubmFlc3NAZ21haWwuY29tPiB3cm90ZToKPiAKPiBJdCBsb29rZWQgbGlrZSB0aGUgc25p cHBldCBvZiBjb2RlIEkgaW5jbHVkZWQgaW4gdGhlIGZpcnN0IHBvc3QsCj4gZXhjZXB0IHdpdGgg MjUsMDAwIHJvd3MuCj4gCj4gVGhlIF90YWdzIGZpbGUgc29sdmVkIGl0IHRob3VnaC4gSSBleGNs dWRlZCB0aGUgZmlsZSBsaWtlIHRoaXM6Cj4gPFBiLio+Oi1zeW50YXgoY2FtbHA0bykKPiAKPiBX aXRoIHRoaXMgaW4gcGxhY2UgSSBzdWNjZXNzZnVsbHkgY29tcGlsZWQgNTAwSyBlbnRyaWVzIGlu IDFtMzBzCj4geWllbGRpbmcgYSAzM01CIC54ZW4gZmlsZS4KPiAKPiBJIGNhbiBjZXJ0YWlubHkg cG9zdCBhbiBpc3N1ZSBvbiB0aGUgY2FtbHA0IGdpdGh1YiBzaXRlIGFuZCBhdHRhY2ggYW4KPiBl eGFtcGxlIGZpbGUgaWYgeW91IHRoaW5rIHRoaXMgc2hvdWxkIHJlYXNvbmFibHkgd29yay4gSSB3 b3VsZG4ndAo+IHRoaW5rIHRoaXMgcmVwcmVzZW50IGEgY29tbW9uIHVzZWNhc2UgOykKPiAKPiBP biBUaHUsIE1heSA4LCAyMDE0IGF0IDEwOjMzIEFNLCBUaG9tYXMgR2F6YWduYWlyZQo+IDx0aG9t YXNAZ2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+PiBkbyB5b3UgaGF2ZSBhbiBleGFtcGxlIG9mIHdo YXQgdGhlIGdlbmVyYXRlZCBzb3VyY2UgZmlsZSBsb29rcyBsaWtlID8KPj4gCj4+IFdvdWxkIGJl IGludGVyZXN0aW5nIHRvIHJlcG9ydCB0aGUgYnVnIHVwc3RyZWFtOiBodHRwczovL2dpdGh1Yi5j b20vb2NhbWwvY2FtbHA0L2lzc3Vlcwo+PiAKPj4gVGhvbWFzCj4+IAo+PiBPbiA3IE1heSAyMDE0 LCBhdCAyMzozOCwgQW5pbCBNYWRoYXZhcGVkZHkgPGFuaWxAcmVjb2lsLm9yZz4gd3JvdGU6Cj4+ IAo+Pj4gVG8gYWRkcmVzcyB0aGUgY2FtbHA0IHByb2JsZW0sIHlvdSBjYW4gdXNlIHRoZSBfdGFn cyBmaWxlIHRvIG1hcmsganVzdAo+Pj4gdGhlIG9uZSBzb3VyY2UgZmlsZSBhcyBub3QgcGFzc2lu ZyB0aHJvdWdoIGNhbWxwNCAodmlhIGEgJy0nIHNvbWV3aGVyZQo+Pj4gdG8gcmVtb3ZlIHRoZSB0 YWcgLS0gd2lsbCBuZWVkIHRvIGxvb2sgdXAgdGhlIGRldGFpbHMgaW4gdGhlIG1hbnVhbCkuCj4+ PiAKPj4+IFRoZSBlYXNpZXN0IHdheSB0byBzb2x2ZSB5b3VyIHByb2JsZW0gd291bGQgYmUganVz dCB0byBoYXZlIGEgY3J1bmNoZWQKPj4+IGZpbGUgY29udGFpbmluZyB0aGUgaW5mb3JtYXRpb24g aW4gQ1NWIG9yIFMtZXhwcmVzc2lvbiBmb3JtYXQsIGFuZCB0aGVuCj4+PiByZWFkaW5nIGZyb20g aXQgYXQgYXBwbGljYXRpb24gc3RhcnR1cCB0aW1lIHRvIGluaXRpYWxpemUgeW91ciBhcnJheS4K Pj4+IAo+Pj4gVGhlICdjcnVuY2gnIG1vZGUgd291bGQgY29tcGlsZSBhbGwgdGhpcyBpbnRvIGEg c3RhbmRhbG9uZSBrZXJuZWwsIG9yCj4+PiBpbiBVbml4IG1vZGUgd291bGQgYmUgYSBmaWxlc3lz dGVtIHBhc3N0aHJvdWdoIGZvciBlYXNpZXIgZGV2ZWxvcG1lbnQuCj4+PiBBbnkgcmVhc29uIHlv dSB3YW50IGl0IHRvIGJlIGEgJ2hhbmQgd3JpdHRlbicgT0NhbWwgZmlsZT8KPj4+IAo+Pj4gLWFu aWwKPj4+IAo+Pj4gT24gNyBNYXkgMjAxNCwgYXQgMTQ6MDYsIEFuZHLDqSBOw6ZzcyA8YW5kcmUu bmFlc3NAZ21haWwuY29tPiB3cm90ZToKPj4+IAo+Pj4+IEkndmUgcmV3cml0dGVuIHRoZSBnZW5l cmF0ZWQgY29kZSBzbyB0aGF0IGl0IGNyZWF0ZXMgYW4gYXJyYXkgYW5kIHRoZW4KPj4+PiBhc3Np Z25zIHRvIGluZGV4ZXMgb2YgdGhlIGFycmF5LCBiYXRjaGluZyB0aGUgYXNzaWdubWVudHMgdXNp bmcKPj4+PiBtdWx0aXBsZSBsZXQgKCkgPQo+Pj4+IAo+Pj4+IENvbXBpbGF0aW9uIHNwZWVkIGlz IGEgcHJvYmxlbSwgYW5kIGl0IHN0aWxsIGZhbGxzIG92ZXIgYXQgNTBLIGVudHJpZXMuCj4+Pj4g Cj4+Pj4gSSBzdXBwb3NlIEkgY291bGQgc29tZWhvdyB3cml0ZSB0aGUgZGF0YSB0byBhbiBpbWFn ZSBhbmQgcmVhZCBpdCBiYWNrCj4+Pj4gaW4gYXQgYXBwbGljYXRpb24gc3RhcnR1cCwgYnV0IEkg dGhpbmsgSSBhY3R1YWxseSBsaWtlIG15IGN1cnJlbnQKPj4+PiBhcHByb2FjaC4gQWxsIG9mIHRo ZSB3b3JrIGlzIGRvbmUgYXQgY29tcGlsYXRpb24gdGltZS4gVGhlIHJvd3MgYXJlCj4+Pj4gd3Jp dHRlbiBpbiBzb3J0ZWQgb3JkZXIgc28gYSBzaW1wbGUgYmluYXJ5IHNlYXJjaCBjYW4gYmUgdXNl ZC4gVGhlCj4+Pj4gcmVzdWx0aW5nIGFwcGxpY2F0aW9uIGlzIGVudGlyZWx5IHNpbmdsZS1wdXJw b3NlZC4KPj4+PiAKPj4+PiBBbnkgaWRlYXMgZm9yIG90aGVyIHdheXMgdG8gZG8gdGhpcz8gQnlw YXNzIHRoZSBjb21waWxlciBhbmQgImNvbXBpbGUiCj4+Pj4gdGhlIGRhdGEgbXlzZWxmPyBEb2Vz IHRoZXJlIGV4aXN0IHRvb2xzIHRvIGRvIHNvbWV0aGluZyBsaWtlIHRoYXQ/Cj4+Pj4gCj4+Pj4g T24gV2VkLCBNYXkgNywgMjAxNCBhdCAxOjQwIFBNLCBBbmRyw6kgTsOmc3MgPGFuZHJlLm5hZXNz QGdtYWlsLmNvbT4gd3JvdGU6Cj4+Pj4+IEhpCj4+Pj4+IAo+Pj4+PiBJJ20gdHJ5aW5nIHNvbWV0 aGluZyB0aGF0IG1pZ2h0IGJlIGEgYml0IHNpbGx5IGJ1dCBpdCdzIGp1c3QgaW50ZW5kZWQKPj4+ Pj4gYXMgYW4gaW50ZXJuYWwgZGVtbyBvZiBNaXJhZ2UgdG8gbXkgdGVhbS4gSSdtIHdyaXRpbmcg YSB0aW55IEhUVFAKPj4+Pj4gYmFzZWQgYXBwbGljYXRpb24gd2hvc2Ugb25seSBwdXJwb3NlIGlz IHRvIGFsbG93IHlvdSB0byBzZWFyY2ggYSBwaG9uZQo+Pj4+PiBib29rLgo+Pj4+PiAKPj4+Pj4g SSd2ZSBiYXNlZCBteSBhcHByb2FjaCBvbiB0aGUgYXBwcm9hY2ggeW91J3ZlIHVzZWQgZm9yIHN0 YXRpYyB3ZWJzaXRlcwo+Pj4+PiB1c2luZyBjcnVuY2ggd2hlcmUgeW91IGNvbXBpbGUgdGhlIHdl YiBwYWdlcyBpbnRvIHRoZSBleGVjdXRhYmxlLiBJbgo+Pj4+PiBteSBjYXNlIHRoYXQgbWVhbnMg SSB0YWtlIHRoZSBsaXN0IG9mIG5hbWUgYW5kIG51bWJlciBwYWlycyBhbmQgc3R1ZmYKPj4+Pj4g dGhlbSBpbnRvIGFuIGFycmF5LiBTbyBwYXJ0IG9mIG15IGNvbmZpZy5tbCBmaWxlIGVtaXRzIGEg c2luZ2xlIFBiLm1sCj4+Pj4+IGZpbGUgd2hpY2ggY29udGFpbnMgYW4gYXJyYXkgZGVjbGFyYXRp b24gbGlrZSB0aGlzOgo+Pj4+PiAKPj4+Pj4gbGV0IGRiID0gW3woIkFhcm9uIEpha3NpYyIsMTU3 MTI2OCk7Cj4+Pj4+ICgiQWFyb24gTWNkaXZpdHQiLDE0NTQ2MjkpOwo+Pj4+PiAoIkFhcm9uIFJl dWJlbiIsMTc2NTI0Nyk7Cj4+Pj4+ICgiQWFyb24gU2FyZGluaGEiLDEyMjQ4MDYpOwo+Pj4+PiAo IkFiYmV5IEdvd2VucyIsMTI2NzA4Myk7Cj4+Pj4+ICgiQWJiZXkgSGF0aGNveCIsMTMwOTQ5MCk7 Cj4+Pj4+IC4uLgo+Pj4+PiAKPj4+Pj4gQXMgdGhlIHRpdGxlIHNheSBJJ20gcnVubmluZyBpbnRv IHByb2JsZW1zIGNvbXBpbGluZyB0aGlzIHdoZW4gSQo+Pj4+PiBjcmVhdGUgYSBsYXJnZSBwaG9u ZSBib29rLCB0aGUgZXJyb3IgYmVpbmc6Cj4+Pj4+IAo+Pj4+PiBDYW1scDQ6IFVuY2F1Z2h0IGV4 Y2VwdGlvbjogU3RhY2tfb3ZlcmZsb3cKPj4+Pj4gCj4+Pj4+IFRoaXMgaGFwcGVucyB3aXRoIDI1 SyBlbnRyaWVzLCBpdCB3b3JrcyB3aXRoIDEwSyBlbnRyaWVzLgo+Pj4+PiAKPj4+Pj4gSXMgdGhl cmUgc29tZSB3YXkgSSBjYW4gcHJldmVudCBDYW1scDQgZnJvbSBiZWluZyBydW4gb24gdGhlIFBi Lm1sCj4+Pj4+IGZpbGU/IE9yIHdpbGwgSSBqdXN0IGhhdmUgdG8gZ2VuZXJhdGUgYSBmaWxlIHRo YXQgYnVpbGRzIHRoZSBhcnJheSBhdAo+Pj4+PiBydW50aW1lIHNvbWVob3c/Cj4+Pj4+IAo+Pj4+ PiBBbmRyw6kKPj4+PiAKPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+Pj4+IE1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4+IE1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCj4+Pj4gaHR0cDovL2xpc3RzLnhlbnByb2plY3Qu b3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo+Pj4gCj4+PiAKPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBNaXJh Z2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKPj4+IE1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2pl Y3Qub3JnCj4+PiBodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xp c3RpbmZvL21pcmFnZW9zLWRldmVsCj4+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Cj4gTWly YWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKPiBodHRwOi8vbGlzdHMueGVucHJvamVj dC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFp bGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 13:29:44 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 13:29:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyhKo-0006r6-V7; Wed, 10 Dec 2014 13:29:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyhKn-0006qy-J0 for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 13:29:41 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id 4A/CD-11608-4CA48845; Wed, 10 Dec 2014 13:29:40 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1418218179!12386958!1 X-Originating-IP: [209.85.215.49] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11156 invoked from network); 10 Dec 2014 13:29:39 -0000 Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Dec 2014 13:29:39 -0000 Received: by mail-la0-f49.google.com with SMTP id hs14so2350357lab.22 for ; Wed, 10 Dec 2014 05:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CyuADhQY+o9dfmf5HXnH9UdZMFPaLOtbq1e/H4KbOoE=; b=XvMMD1IqhiLLxXuO+LcSeSNrD24ZqIt82vr8ECiB830XV3nY/rUrGtcIRizAVY3U0H COnAW/iTWjEKFDDDfNpgr4yJfuW1ZhvmZ7cxh4Yw5SdknYYA1zOE+tB1TYkS8MEYJ6v1 ebEPKv7AoN5bIQ4ujx05AfyAVBCjdSeYIPNVgQcB2mBSlYpjchrrG1yfzBte4yl7VDV+ maLCZchiKaMuhuf0r+90Bv5R78AF/6NBowgD99B2l6UyxOkUlNLYQ8UHLfo2MYghNZBS Ipyj5eezSDxVW1RrTERJ+LErjoqwspgpgeycmSyK+bucCaqcts9pgFFV8ihCQpejeAsm cqsA== MIME-Version: 1.0 X-Received: by 10.152.205.11 with SMTP id lc11mr4197809lac.34.1418218179191; Wed, 10 Dec 2014 05:29:39 -0800 (PST) Received: by 10.112.48.65 with HTTP; Wed, 10 Dec 2014 05:29:39 -0800 (PST) In-Reply-To: <09A9377F-AC63-444F-82A9-D1B200DBE56F@recoil.org> References: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> <7DD57EE5694C46839EDBE8640256574A@erratique.ch> <09A9377F-AC63-444F-82A9-D1B200DBE56F@recoil.org> Date: Wed, 10 Dec 2014 07:29:39 -0600 Message-ID: From: Brian Brietzke To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8523724057928891791==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8523724057928891791== Content-Type: multipart/alternative; boundary=001a1133a818c8e8d30509dca637 --001a1133a818c8e8d30509dca637 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That did the job! My uname reports 13.4.0, but I think Daniel's fix is probably better fix. Thanks again. On Wed, Dec 10, 2014 at 5:21 AM, Anil Madhavapeddy wrote: > On 9 Dec 2014, at 21:08, Daniel B=C3=BCnzli > wrote: > > > > Le mardi, 9 d=C3=A9cembre 2014 =C3=A0 21:44, Anil Madhavapeddy a =C3=A9= crit : > >> What is the output of your "uname -a"? I can put a smarter check into > mirage to not need this on older MacOS X. > > > > Check `uname -r` < 14.0.0 > > > > Thanks -- now done in: > > https://github.com/mirage/mirage/pull/337 > > (If anyone tries this on an older OSX let me know, but it should be no > worse > than what we do right now so I'll just go ahead if I don't get any > reports). > > The patch also prints out the selected target mode on the console now so > it's > more obvious what is going on. > > -anil > > --001a1133a818c8e8d30509dca637 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That did the job!

My uname reports=C2= =A013.4.0, but I think Daniel's fix is probably better fix.
<= br>
Thanks again.

On Wed, Dec 10, 2014 at 5:21 AM, Anil Madhavapeddy <an= il@recoil.org> wrote:
On 9 Dec 2014, at 21:08, Daniel B=C3=BCn= zli <daniel.buenzli@errat= ique.ch> wrote:
>
> Le mardi, 9 d=C3=A9cembre 2014 =C3=A0 21:44, Anil Madhavapeddy a =C3= =A9crit :
>> What is the output of your "uname -a"? I can put a smart= er check into mirage to not need this on older MacOS X.
>
> Check `uname -r` < 14.0.0
>

Thanks -- now done in:

htt= ps://github.com/mirage/mirage/pull/337

(If anyone tries this on an older OSX let me know, but it should be no wors= e
than what we do right now so I'll just go ahead if I don't get any = reports).

The patch also prints out the selected target mode on the console now so it= 's
more obvious what is going on.

-anil


--001a1133a818c8e8d30509dca637-- --===============8523724057928891791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8523724057928891791==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 13:29:44 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 13:29:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyhKo-0006r6-V7; Wed, 10 Dec 2014 13:29:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyhKn-0006qy-J0 for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 13:29:41 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id 4A/CD-11608-4CA48845; Wed, 10 Dec 2014 13:29:40 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1418218179!12386958!1 X-Originating-IP: [209.85.215.49] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11156 invoked from network); 10 Dec 2014 13:29:39 -0000 Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Dec 2014 13:29:39 -0000 Received: by mail-la0-f49.google.com with SMTP id hs14so2350357lab.22 for ; Wed, 10 Dec 2014 05:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CyuADhQY+o9dfmf5HXnH9UdZMFPaLOtbq1e/H4KbOoE=; b=XvMMD1IqhiLLxXuO+LcSeSNrD24ZqIt82vr8ECiB830XV3nY/rUrGtcIRizAVY3U0H COnAW/iTWjEKFDDDfNpgr4yJfuW1ZhvmZ7cxh4Yw5SdknYYA1zOE+tB1TYkS8MEYJ6v1 ebEPKv7AoN5bIQ4ujx05AfyAVBCjdSeYIPNVgQcB2mBSlYpjchrrG1yfzBte4yl7VDV+ maLCZchiKaMuhuf0r+90Bv5R78AF/6NBowgD99B2l6UyxOkUlNLYQ8UHLfo2MYghNZBS Ipyj5eezSDxVW1RrTERJ+LErjoqwspgpgeycmSyK+bucCaqcts9pgFFV8ihCQpejeAsm cqsA== MIME-Version: 1.0 X-Received: by 10.152.205.11 with SMTP id lc11mr4197809lac.34.1418218179191; Wed, 10 Dec 2014 05:29:39 -0800 (PST) Received: by 10.112.48.65 with HTTP; Wed, 10 Dec 2014 05:29:39 -0800 (PST) In-Reply-To: <09A9377F-AC63-444F-82A9-D1B200DBE56F@recoil.org> References: <89B6BB4D-5EAA-4E76-9D57-60C6976221BB@recoil.org> <7DD57EE5694C46839EDBE8640256574A@erratique.ch> <09A9377F-AC63-444F-82A9-D1B200DBE56F@recoil.org> Date: Wed, 10 Dec 2014 07:29:39 -0600 Message-ID: From: Brian Brietzke To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage-Net-MacOsX and VmNet on Mavericks X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8523724057928891791==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8523724057928891791== Content-Type: multipart/alternative; boundary=001a1133a818c8e8d30509dca637 --001a1133a818c8e8d30509dca637 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That did the job! My uname reports 13.4.0, but I think Daniel's fix is probably better fix. Thanks again. On Wed, Dec 10, 2014 at 5:21 AM, Anil Madhavapeddy wrote: > On 9 Dec 2014, at 21:08, Daniel B=C3=BCnzli > wrote: > > > > Le mardi, 9 d=C3=A9cembre 2014 =C3=A0 21:44, Anil Madhavapeddy a =C3=A9= crit : > >> What is the output of your "uname -a"? I can put a smarter check into > mirage to not need this on older MacOS X. > > > > Check `uname -r` < 14.0.0 > > > > Thanks -- now done in: > > https://github.com/mirage/mirage/pull/337 > > (If anyone tries this on an older OSX let me know, but it should be no > worse > than what we do right now so I'll just go ahead if I don't get any > reports). > > The patch also prints out the selected target mode on the console now so > it's > more obvious what is going on. > > -anil > > --001a1133a818c8e8d30509dca637 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That did the job!

My uname reports=C2= =A013.4.0, but I think Daniel's fix is probably better fix.
<= br>
Thanks again.

On Wed, Dec 10, 2014 at 5:21 AM, Anil Madhavapeddy <an= il@recoil.org> wrote:
On 9 Dec 2014, at 21:08, Daniel B=C3=BCn= zli <daniel.buenzli@errat= ique.ch> wrote:
>
> Le mardi, 9 d=C3=A9cembre 2014 =C3=A0 21:44, Anil Madhavapeddy a =C3= =A9crit :
>> What is the output of your "uname -a"? I can put a smart= er check into mirage to not need this on older MacOS X.
>
> Check `uname -r` < 14.0.0
>

Thanks -- now done in:

htt= ps://github.com/mirage/mirage/pull/337

(If anyone tries this on an older OSX let me know, but it should be no wors= e
than what we do right now so I'll just go ahead if I don't get any = reports).

The patch also prints out the selected target mode on the console now so it= 's
more obvious what is going on.

-anil


--001a1133a818c8e8d30509dca637-- --===============8523724057928891791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8523724057928891791==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 14:54:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 14:54:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyif9-0003O9-L3; Wed, 10 Dec 2014 14:54:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyif7-0003O2-K7 for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 14:54:45 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 61/DE-02712-3BE58845; Wed, 10 Dec 2014 14:54:43 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1418223280!14222340!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12641 invoked from network); 10 Dec 2014 14:54:41 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 14:54:41 -0000 Received: from dhcp-172-17-153-118.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 18dd0916; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 15:00:12 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5416267.uz7Mnlar5D@agaric> Date: Wed, 10 Dec 2014 14:54:39 +0000 Message-Id: <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> To: Louis Gesbert X-Mailer: Apple Mail (2.1993) Cc: opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I just reproduced it by following the referenced bug report. >From a fresh Ubuntu 14.10, if I do: $ sudo apt-get install opam camlp4-extra aspcud $ opam init -a $ opam install mirage -y $ eval `opam config env` At this point some packages have been installed and mirage is installed. Now however, if I use mirage it invokes opam install again and packages are reinstalled as a duplicate. See below: opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan [NOTE] Package mirage-types is already installed (current version is 2.1.0). [NOTE] Package lwt is already installed (current version is 2.4.6). [NOTE] Package io-page is already installed (current version is 1.1.1). [NOTE] Package cstruct is already installed (current version is 1.4.0). [NOTE] Package crunch is already installed (current version is 1.3.0). [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile The following actions will be performed: - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] - install base-bigarray.base [required by cowabloga] - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] - install xmlm.1.2.0 [required by cowabloga] - install uutf.0.9.3 [required by cowabloga] - install stringext.1.1.0 [required by cowabloga, mirage-http] - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] - install re.1.2.2 [required by cowabloga, mirage-http] - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] - install hex.0.1.0 [required by cowabloga] - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] - install base64.1.0.0 [required by cowabloga, mirage-http] - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] - install ulex.1.1 [required by cowabloga] - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] - install omd.1.2.3 [required by cowabloga] - install jsonm.0.9.1 [required by cowabloga] - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] - install crunch.1.3.0 - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] - install fieldslib.109.20.03 [required by cowabloga, mirage-http] - install dyntype.0.9.0 [required by cowabloga] - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] - install uri.1.7.2 [required by cowabloga, mirage-http] I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe Any inspiration from there from the CUDF interactions in the above gist? -anil > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > I've been trying to reproduce the issue, but things seem fine, sort of: > > From what I could gather: > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > ``` > ===== ERROR while installing ocamlfind.1.5.5 ===== > Internal error: > "ocamlfind": command not found. > ``` > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > Cheers, > Louis > > > [1] https://github.com/ocaml/opam/issues/1683 > [2] https://github.com/ocaml/opam/issues/1658 > > - Anil Madhavapeddy, 09/12/2014 11:16 - >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >> >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >> >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >> >> -anil >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 14:54:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 14:54:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyif9-0003O9-L3; Wed, 10 Dec 2014 14:54:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyif7-0003O2-K7 for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 14:54:45 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 61/DE-02712-3BE58845; Wed, 10 Dec 2014 14:54:43 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1418223280!14222340!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12641 invoked from network); 10 Dec 2014 14:54:41 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 14:54:41 -0000 Received: from dhcp-172-17-153-118.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 18dd0916; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 15:00:12 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5416267.uz7Mnlar5D@agaric> Date: Wed, 10 Dec 2014 14:54:39 +0000 Message-Id: <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> To: Louis Gesbert X-Mailer: Apple Mail (2.1993) Cc: opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I just reproduced it by following the referenced bug report. >From a fresh Ubuntu 14.10, if I do: $ sudo apt-get install opam camlp4-extra aspcud $ opam init -a $ opam install mirage -y $ eval `opam config env` At this point some packages have been installed and mirage is installed. Now however, if I use mirage it invokes opam install again and packages are reinstalled as a duplicate. See below: opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan [NOTE] Package mirage-types is already installed (current version is 2.1.0). [NOTE] Package lwt is already installed (current version is 2.4.6). [NOTE] Package io-page is already installed (current version is 1.1.1). [NOTE] Package cstruct is already installed (current version is 1.4.0). [NOTE] Package crunch is already installed (current version is 1.3.0). [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile The following actions will be performed: - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] - install base-bigarray.base [required by cowabloga] - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] - install xmlm.1.2.0 [required by cowabloga] - install uutf.0.9.3 [required by cowabloga] - install stringext.1.1.0 [required by cowabloga, mirage-http] - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] - install re.1.2.2 [required by cowabloga, mirage-http] - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] - install hex.0.1.0 [required by cowabloga] - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] - install base64.1.0.0 [required by cowabloga, mirage-http] - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] - install ulex.1.1 [required by cowabloga] - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] - install omd.1.2.3 [required by cowabloga] - install jsonm.0.9.1 [required by cowabloga] - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] - install crunch.1.3.0 - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] - install fieldslib.109.20.03 [required by cowabloga, mirage-http] - install dyntype.0.9.0 [required by cowabloga] - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] - install uri.1.7.2 [required by cowabloga, mirage-http] I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe Any inspiration from there from the CUDF interactions in the above gist? -anil > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > I've been trying to reproduce the issue, but things seem fine, sort of: > > From what I could gather: > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > ``` > ===== ERROR while installing ocamlfind.1.5.5 ===== > Internal error: > "ocamlfind": command not found. > ``` > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > Cheers, > Louis > > > [1] https://github.com/ocaml/opam/issues/1683 > [2] https://github.com/ocaml/opam/issues/1658 > > - Anil Madhavapeddy, 09/12/2014 11:16 - >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >> >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >> >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >> >> -anil >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 15:00:49 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 15:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyikz-0003S2-4U; Wed, 10 Dec 2014 15:00:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyikx-0003Rv-MS for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 15:00:48 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 40/6C-03145-E1068845; Wed, 10 Dec 2014 15:00:46 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1418223644!14223664!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18931 invoked from network); 10 Dec 2014 15:00:44 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 15:00:44 -0000 Received: from dhcp-172-17-153-118.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 2620f24a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 15:06:16 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141210071631.GA4391@traveler> Date: Wed, 10 Dec 2014 15:00:43 +0000 Message-Id: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <20141210071631.GA4391@traveler> To: Roberto Di Cosmo X-Mailer: Apple Mail (2.1993) Cc: Louis Gesbert , opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org See my previous mail for more debug information -- hope that's useful. It may also be the version of Gringo or Clasp that is incompatible with Aspcud. This happened before on MacOS X when clasp was upgraded before Aspcud: https://github.com/Homebrew/homebrew/pull/27871 I also note that Ubuntu's opam package only installs ocaml as a dependency and not ocaml-native-compilers and camlp4-extra, both of which are pretty much necessary for modern OCaml operation. Any thoughts on making this a harder dependency in the opam package? -anil On 10 Dec 2014, at 07:16, Roberto Di Cosmo wrote: > > Thanks Louis for looking into this. > > As for aspcud 1.9, I also have trouble understanding what the issue could be. > The version in utopic [1] is exactly the same as the one I use in Debian [2], > and it is backward compatible with 1.8: the old preference criteria are still > there, just do > > $ /usr/local/bin/cudf2lp --help > > and you will see this text among the rest > > --criteria,-c : Preprocess for specific optimization criteria > Default: none > Valid: none, paranoid, trendy, -|+\(,-|+\)* > : count() | sum(,) | unsat_recommends() > | aligned(,,) | notuptodate() > : CUDF attribute name > : solution | changed | new | removed | up | down > | installrequest | upgraderequest | request > For backwards compatibility: > new = count(new) > removed = count(removed) > changed = count(changed) > notuptodate = notuptodate(solution) > unsat_recommends = unsat_recommends(solution) > sum(name) = sum(name,solution) > > Anil, may you provide a more precise bug report? > > [1] http://packages.ubuntu.com/fr/utopic/aspcud > [2] https://packages.debian.org/fr/jessie/aspcud > > On Wed, Dec 10, 2014 at 10:15:37AM +0900, Louis Gesbert wrote: >> I've been trying to reproduce the issue, but things seem fine, sort of: >> >>> From what I could gather: >> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine >> * utopic (14.10, latest) has 1.1 and aspcud 1.9 >> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too >> >> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). >> >> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with >> ``` >> ===== ERROR while installing ocamlfind.1.5.5 ===== >> Internal error: >> "ocamlfind": command not found. >> ``` >> >> so it would still be nice if they could backport (so that there is a better error) or recommend m4. >> >> Cheers, >> Louis >> >> >> [1] https://github.com/ocaml/opam/issues/1683 >> [2] https://github.com/ocaml/opam/issues/1658 >> >> - Anil Madhavapeddy, 09/12/2014 11:16 - >>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >>> >>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >>> >>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >>> >>> -anil >>> _______________________________________________ >>> opam-devel mailing list >>> opam-devel@lists.ocaml.org >>> http://lists.ocaml.org/listinfo/opam-devel >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > > -- > Roberto Di Cosmo > > ------------------------------------------------------------------ > Professeur En delegation a l'INRIA > PPS E-mail: roberto@dicosmo.org > Universite Paris Diderot WWW : http://www.dicosmo.org > Case 7014 Tel : ++33-(0)1-57 27 92 20 > 5, Rue Thomas Mann > F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo > FRANCE. Twitter: http://twitter.com/rdicosmo > ------------------------------------------------------------------ > Attachments: > MIME accepted, Word deprecated > http://www.gnu.org/philosophy/no-word-attachments.html > ------------------------------------------------------------------ > Office location: > > Bureau 3020 (3rd floor) > Batiment Sophie Germain > Avenue de France > Metro Bibliotheque Francois Mitterrand, ligne 14/RER C > ----------------------------------------------------------------- > GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 15:00:49 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 15:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyikz-0003S2-4U; Wed, 10 Dec 2014 15:00:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyikx-0003Rv-MS for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 15:00:48 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 40/6C-03145-E1068845; Wed, 10 Dec 2014 15:00:46 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1418223644!14223664!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18931 invoked from network); 10 Dec 2014 15:00:44 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 15:00:44 -0000 Received: from dhcp-172-17-153-118.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 2620f24a; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 15:06:16 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141210071631.GA4391@traveler> Date: Wed, 10 Dec 2014 15:00:43 +0000 Message-Id: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <20141210071631.GA4391@traveler> To: Roberto Di Cosmo X-Mailer: Apple Mail (2.1993) Cc: Louis Gesbert , opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org See my previous mail for more debug information -- hope that's useful. It may also be the version of Gringo or Clasp that is incompatible with Aspcud. This happened before on MacOS X when clasp was upgraded before Aspcud: https://github.com/Homebrew/homebrew/pull/27871 I also note that Ubuntu's opam package only installs ocaml as a dependency and not ocaml-native-compilers and camlp4-extra, both of which are pretty much necessary for modern OCaml operation. Any thoughts on making this a harder dependency in the opam package? -anil On 10 Dec 2014, at 07:16, Roberto Di Cosmo wrote: > > Thanks Louis for looking into this. > > As for aspcud 1.9, I also have trouble understanding what the issue could be. > The version in utopic [1] is exactly the same as the one I use in Debian [2], > and it is backward compatible with 1.8: the old preference criteria are still > there, just do > > $ /usr/local/bin/cudf2lp --help > > and you will see this text among the rest > > --criteria,-c : Preprocess for specific optimization criteria > Default: none > Valid: none, paranoid, trendy, -|+\(,-|+\)* > : count() | sum(,) | unsat_recommends() > | aligned(,,) | notuptodate() > : CUDF attribute name > : solution | changed | new | removed | up | down > | installrequest | upgraderequest | request > For backwards compatibility: > new = count(new) > removed = count(removed) > changed = count(changed) > notuptodate = notuptodate(solution) > unsat_recommends = unsat_recommends(solution) > sum(name) = sum(name,solution) > > Anil, may you provide a more precise bug report? > > [1] http://packages.ubuntu.com/fr/utopic/aspcud > [2] https://packages.debian.org/fr/jessie/aspcud > > On Wed, Dec 10, 2014 at 10:15:37AM +0900, Louis Gesbert wrote: >> I've been trying to reproduce the issue, but things seem fine, sort of: >> >>> From what I could gather: >> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine >> * utopic (14.10, latest) has 1.1 and aspcud 1.9 >> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too >> >> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). >> >> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with >> ``` >> ===== ERROR while installing ocamlfind.1.5.5 ===== >> Internal error: >> "ocamlfind": command not found. >> ``` >> >> so it would still be nice if they could backport (so that there is a better error) or recommend m4. >> >> Cheers, >> Louis >> >> >> [1] https://github.com/ocaml/opam/issues/1683 >> [2] https://github.com/ocaml/opam/issues/1658 >> >> - Anil Madhavapeddy, 09/12/2014 11:16 - >>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >>> >>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >>> >>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >>> >>> -anil >>> _______________________________________________ >>> opam-devel mailing list >>> opam-devel@lists.ocaml.org >>> http://lists.ocaml.org/listinfo/opam-devel >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > > -- > Roberto Di Cosmo > > ------------------------------------------------------------------ > Professeur En delegation a l'INRIA > PPS E-mail: roberto@dicosmo.org > Universite Paris Diderot WWW : http://www.dicosmo.org > Case 7014 Tel : ++33-(0)1-57 27 92 20 > 5, Rue Thomas Mann > F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo > FRANCE. Twitter: http://twitter.com/rdicosmo > ------------------------------------------------------------------ > Attachments: > MIME accepted, Word deprecated > http://www.gnu.org/philosophy/no-word-attachments.html > ------------------------------------------------------------------ > Office location: > > Bureau 3020 (3rd floor) > Batiment Sophie Germain > Avenue de France > Metro Bibliotheque Francois Mitterrand, ligne 14/RER C > ----------------------------------------------------------------- > GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 15:18:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 15:18:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyj2M-0004BF-UT; Wed, 10 Dec 2014 15:18:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyj2L-0004B9-2a for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 15:18:45 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 74/EB-22819-45468845; Wed, 10 Dec 2014 15:18:44 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-206.messagelabs.com!1418224722!9264957!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1002 invoked from network); 10 Dec 2014 15:18:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 15:18:42 -0000 Received: from dhcp-172-17-153-118.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 3485e1e4; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 15:24:14 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> Date: Wed, 10 Dec 2014 15:18:41 +0000 Message-Id: <3EC5765F-4802-4BA6-B52F-83B32F6934E6@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> To: Louis Gesbert X-Mailer: Apple Mail (2.1993) Cc: opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I wonder if this is due to the OPAM 1.1 repository redirect, which leads to lots of errors in the initial `opam init` and subsequently caused the base packages to not be installed... However, doing an `opam update -u` and letting the repository update didnt work, nor did `opam init https://opam.ocaml.org/1.1` make a difference. I'll stop trying random things now and let the CUDF experts speak :-) -anil > On 10 Dec 2014, at 14:54, Anil Madhavapeddy wrote: > > I just reproduced it by following the referenced bug report. > > From a fresh Ubuntu 14.10, if I do: > > $ sudo apt-get install opam camlp4-extra aspcud > $ opam init -a > $ opam install mirage -y > $ eval `opam config env` > > At this point some packages have been installed and mirage is installed. > > Now however, if I use mirage it invokes opam install again and packages > are reinstalled as a duplicate. See below: > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > [NOTE] Package lwt is already installed (current version is 2.4.6). > [NOTE] Package io-page is already installed (current version is 1.1.1). > [NOTE] Package cstruct is already installed (current version is 1.4.0). > [NOTE] Package crunch is already installed (current version is 1.3.0). > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > The following actions will be performed: > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-bigarray.base [required by cowabloga] > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install xmlm.1.2.0 [required by cowabloga] > - install uutf.0.9.3 [required by cowabloga] > - install stringext.1.1.0 [required by cowabloga, mirage-http] > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install re.1.2.2 [required by cowabloga, mirage-http] > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install hex.0.1.0 [required by cowabloga] > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > - install base64.1.0.0 [required by cowabloga, mirage-http] > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > - install ulex.1.1 [required by cowabloga] > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install omd.1.2.3 [required by cowabloga] > - install jsonm.0.9.1 [required by cowabloga] > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install crunch.1.3.0 > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > - install dyntype.0.9.0 [required by cowabloga] > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install uri.1.7.2 [required by cowabloga, mirage-http] > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > Any inspiration from there from the CUDF interactions in the above gist? > > -anil > >> On 10 Dec 2014, at 01:15, Louis Gesbert wrote: >> >> I've been trying to reproduce the issue, but things seem fine, sort of: >> >> From what I could gather: >> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine >> * utopic (14.10, latest) has 1.1 and aspcud 1.9 >> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too >> >> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). >> >> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with >> ``` >> ===== ERROR while installing ocamlfind.1.5.5 ===== >> Internal error: >> "ocamlfind": command not found. >> ``` >> >> so it would still be nice if they could backport (so that there is a better error) or recommend m4. >> >> Cheers, >> Louis >> >> >> [1] https://github.com/ocaml/opam/issues/1683 >> [2] https://github.com/ocaml/opam/issues/1658 >> >> - Anil Madhavapeddy, 09/12/2014 11:16 - >>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >>> >>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >>> >>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >>> >>> -anil >>> _______________________________________________ >>> opam-devel mailing list >>> opam-devel@lists.ocaml.org >>> http://lists.ocaml.org/listinfo/opam-devel >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 15:18:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 15:18:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyj2M-0004BF-UT; Wed, 10 Dec 2014 15:18:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyj2L-0004B9-2a for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 15:18:45 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 74/EB-22819-45468845; Wed, 10 Dec 2014 15:18:44 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-206.messagelabs.com!1418224722!9264957!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1002 invoked from network); 10 Dec 2014 15:18:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Dec 2014 15:18:42 -0000 Received: from dhcp-172-17-153-118.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 3485e1e4; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 10 Dec 2014 15:24:14 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> Date: Wed, 10 Dec 2014 15:18:41 +0000 Message-Id: <3EC5765F-4802-4BA6-B52F-83B32F6934E6@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> To: Louis Gesbert X-Mailer: Apple Mail (2.1993) Cc: opam-devel , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I wonder if this is due to the OPAM 1.1 repository redirect, which leads to lots of errors in the initial `opam init` and subsequently caused the base packages to not be installed... However, doing an `opam update -u` and letting the repository update didnt work, nor did `opam init https://opam.ocaml.org/1.1` make a difference. I'll stop trying random things now and let the CUDF experts speak :-) -anil > On 10 Dec 2014, at 14:54, Anil Madhavapeddy wrote: > > I just reproduced it by following the referenced bug report. > > From a fresh Ubuntu 14.10, if I do: > > $ sudo apt-get install opam camlp4-extra aspcud > $ opam init -a > $ opam install mirage -y > $ eval `opam config env` > > At this point some packages have been installed and mirage is installed. > > Now however, if I use mirage it invokes opam install again and packages > are reinstalled as a duplicate. See below: > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > [NOTE] Package lwt is already installed (current version is 2.4.6). > [NOTE] Package io-page is already installed (current version is 1.1.1). > [NOTE] Package cstruct is already installed (current version is 1.4.0). > [NOTE] Package crunch is already installed (current version is 1.3.0). > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > The following actions will be performed: > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-bigarray.base [required by cowabloga] > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install xmlm.1.2.0 [required by cowabloga] > - install uutf.0.9.3 [required by cowabloga] > - install stringext.1.1.0 [required by cowabloga, mirage-http] > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install re.1.2.2 [required by cowabloga, mirage-http] > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install hex.0.1.0 [required by cowabloga] > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > - install base64.1.0.0 [required by cowabloga, mirage-http] > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > - install ulex.1.1 [required by cowabloga] > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install omd.1.2.3 [required by cowabloga] > - install jsonm.0.9.1 [required by cowabloga] > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install crunch.1.3.0 > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > - install dyntype.0.9.0 [required by cowabloga] > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install uri.1.7.2 [required by cowabloga, mirage-http] > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > Any inspiration from there from the CUDF interactions in the above gist? > > -anil > >> On 10 Dec 2014, at 01:15, Louis Gesbert wrote: >> >> I've been trying to reproduce the issue, but things seem fine, sort of: >> >> From what I could gather: >> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine >> * utopic (14.10, latest) has 1.1 and aspcud 1.9 >> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too >> >> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). >> >> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with >> ``` >> ===== ERROR while installing ocamlfind.1.5.5 ===== >> Internal error: >> "ocamlfind": command not found. >> ``` >> >> so it would still be nice if they could backport (so that there is a better error) or recommend m4. >> >> Cheers, >> Louis >> >> >> [1] https://github.com/ocaml/opam/issues/1683 >> [2] https://github.com/ocaml/opam/issues/1658 >> >> - Anil Madhavapeddy, 09/12/2014 11:16 - >>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >>> >>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >>> >>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >>> >>> -anil >>> _______________________________________________ >>> opam-devel mailing list >>> opam-devel@lists.ocaml.org >>> http://lists.ocaml.org/listinfo/opam-devel >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 19:58:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 19:58:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XynOm-0004Y5-4j; Wed, 10 Dec 2014 19:58:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XynOk-0004Y0-Mg for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 19:58:10 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id B9/44-03148-1D5A8845; Wed, 10 Dec 2014 19:58:09 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1418241488!14287164!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23700 invoked from network); 10 Dec 2014 19:58:09 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Dec 2014 19:58:09 -0000 Received: by mail-lb0-f173.google.com with SMTP id z12so2936311lbi.32 for ; Wed, 10 Dec 2014 11:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WGxgWuFAYukNf42Tc2mcoyQsmNNdohqFBeZIF+qpvq4=; b=NI7x8+7SuLtePDyjrXZVAUVYyKkHrYgPVskJ3pOP4DuH7/yj4hRNA5/DWvkSUaIDZB YKLa/hP2XmB2C+d3td/WoHSqodnl6HCdvCPghmogt0lT+cZVc8c+Dxb/BMu7bDPvGOT5 4/d3pHNBBNgmP9kc1Il7+KijTCwjh+Uy5qG+HZZkKYNnAQ89qqV4shlwmmqleWS1LYBs OBKEQj5WHRj3DK8yH/iHbGVeUY4DIIGpsA3SckX06SKyXzlVZXXK6r7vRLptwLfwGVgf d8wusbn8uhMYTLyJvn7Xoni1/U5GrK25GIVHarc3lQEY1ub2bJ8e9XStsqudY7Msr+BP dPdw== MIME-Version: 1.0 X-Received: by 10.152.1.131 with SMTP id 3mr5791424lam.89.1418241488209; Wed, 10 Dec 2014 11:58:08 -0800 (PST) Received: by 10.112.48.65 with HTTP; Wed, 10 Dec 2014 11:58:08 -0800 (PST) Date: Wed, 10 Dec 2014 13:58:08 -0600 Message-ID: From: Brian Brietzke To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6535195465669138054==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6535195465669138054== Content-Type: multipart/alternative; boundary=089e013c62b81c4c620509e2141b --089e013c62b81c4c620509e2141b Content-Type: text/plain; charset=UTF-8 I think I may have my own answer, but I thought I would ask anyways. I would like to be able to interface the Mirage images ( either running on xen or just through unix ) to be able to contact external data storage systems ( i.e. postgresql, mysql, redis, mongodb ) so that it can some data processing. I tried using sqlite3 with the bindings for OCaml, and it gave me an error that it can't load then extensions, which makes perfect sense. The files the library is looking don't exist inside the tiny world of the Mirage virtual machine. That means that we would have to use a client library which is totally written in OCaml, no linkages to external dependencies. That severally limits the number of client libraries available, which could or could not be a bad thing. Is this assumption correct? I'm assuming that it would be a very difficult ( if not an impossible ) task to make the C libraries available from postgresql or sqlite into the Mirage OS. Thanks again for humoring me! --089e013c62b81c4c620509e2141b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I may have my own answer, but I thought I would as= k anyways. =C2=A0

I would like to be able to interface t= he Mirage images ( either running on xen or just through unix ) to be able = to contact external data storage systems ( i.e. postgresql, mysql, redis, m= ongodb ) so that it can some data processing. =C2=A0

I tried using sqlite3 with the bindings for=C2=A0OCaml, and it gave me a= n error that it can't load then extensions,=C2=A0which makes perfect se= nse.=C2=A0 The files the library is looking don't exist inside the tiny= world of the Mirage virtual machine. =C2=A0

That = means that we would have to use a client library which is totally written i= n OCaml, no linkages to external dependencies.=C2=A0 That severally limits = the number of client libraries available, which could or could not be a bad= thing. =C2=A0

Is this assumption correct? =C2=A0<= /div>

I'm assuming that it would be a very difficult= ( if not an impossible ) task to make the C libraries available from postg= resql or sqlite into the Mirage OS. =C2=A0

Thanks = again for humoring me!
--089e013c62b81c4c620509e2141b-- --===============6535195465669138054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6535195465669138054==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 19:58:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 19:58:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XynOm-0004Y5-4j; Wed, 10 Dec 2014 19:58:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XynOk-0004Y0-Mg for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 19:58:10 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id B9/44-03148-1D5A8845; Wed, 10 Dec 2014 19:58:09 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1418241488!14287164!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23700 invoked from network); 10 Dec 2014 19:58:09 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Dec 2014 19:58:09 -0000 Received: by mail-lb0-f173.google.com with SMTP id z12so2936311lbi.32 for ; Wed, 10 Dec 2014 11:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WGxgWuFAYukNf42Tc2mcoyQsmNNdohqFBeZIF+qpvq4=; b=NI7x8+7SuLtePDyjrXZVAUVYyKkHrYgPVskJ3pOP4DuH7/yj4hRNA5/DWvkSUaIDZB YKLa/hP2XmB2C+d3td/WoHSqodnl6HCdvCPghmogt0lT+cZVc8c+Dxb/BMu7bDPvGOT5 4/d3pHNBBNgmP9kc1Il7+KijTCwjh+Uy5qG+HZZkKYNnAQ89qqV4shlwmmqleWS1LYBs OBKEQj5WHRj3DK8yH/iHbGVeUY4DIIGpsA3SckX06SKyXzlVZXXK6r7vRLptwLfwGVgf d8wusbn8uhMYTLyJvn7Xoni1/U5GrK25GIVHarc3lQEY1ub2bJ8e9XStsqudY7Msr+BP dPdw== MIME-Version: 1.0 X-Received: by 10.152.1.131 with SMTP id 3mr5791424lam.89.1418241488209; Wed, 10 Dec 2014 11:58:08 -0800 (PST) Received: by 10.112.48.65 with HTTP; Wed, 10 Dec 2014 11:58:08 -0800 (PST) Date: Wed, 10 Dec 2014 13:58:08 -0600 Message-ID: From: Brian Brietzke To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6535195465669138054==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6535195465669138054== Content-Type: multipart/alternative; boundary=089e013c62b81c4c620509e2141b --089e013c62b81c4c620509e2141b Content-Type: text/plain; charset=UTF-8 I think I may have my own answer, but I thought I would ask anyways. I would like to be able to interface the Mirage images ( either running on xen or just through unix ) to be able to contact external data storage systems ( i.e. postgresql, mysql, redis, mongodb ) so that it can some data processing. I tried using sqlite3 with the bindings for OCaml, and it gave me an error that it can't load then extensions, which makes perfect sense. The files the library is looking don't exist inside the tiny world of the Mirage virtual machine. That means that we would have to use a client library which is totally written in OCaml, no linkages to external dependencies. That severally limits the number of client libraries available, which could or could not be a bad thing. Is this assumption correct? I'm assuming that it would be a very difficult ( if not an impossible ) task to make the C libraries available from postgresql or sqlite into the Mirage OS. Thanks again for humoring me! --089e013c62b81c4c620509e2141b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I may have my own answer, but I thought I would as= k anyways. =C2=A0

I would like to be able to interface t= he Mirage images ( either running on xen or just through unix ) to be able = to contact external data storage systems ( i.e. postgresql, mysql, redis, m= ongodb ) so that it can some data processing. =C2=A0

I tried using sqlite3 with the bindings for=C2=A0OCaml, and it gave me a= n error that it can't load then extensions,=C2=A0which makes perfect se= nse.=C2=A0 The files the library is looking don't exist inside the tiny= world of the Mirage virtual machine. =C2=A0

That = means that we would have to use a client library which is totally written i= n OCaml, no linkages to external dependencies.=C2=A0 That severally limits = the number of client libraries available, which could or could not be a bad= thing. =C2=A0

Is this assumption correct? =C2=A0<= /div>

I'm assuming that it would be a very difficult= ( if not an impossible ) task to make the C libraries available from postg= resql or sqlite into the Mirage OS. =C2=A0

Thanks = again for humoring me!
--089e013c62b81c4c620509e2141b-- --===============6535195465669138054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6535195465669138054==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 21:20:38 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 21:20:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyogS-0007tZ-SW; Wed, 10 Dec 2014 21:20:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyogR-0007tU-2H for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 21:20:31 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id E9/B2-03148-E19B8845; Wed, 10 Dec 2014 21:20:30 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-9.tower-27.messagelabs.com!1418246429!14259664!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12839 invoked from network); 10 Dec 2014 21:20:29 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-9.tower-27.messagelabs.com with SMTP; 10 Dec 2014 21:20:29 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B099441950C_488B91CB for ; Wed, 10 Dec 2014 21:20:28 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 6C53D401C53_488B91CF for ; Wed, 10 Dec 2014 21:20:28 +0000 (GMT) Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1XyogO-0003Sx-Cq; Wed, 10 Dec 2014 21:20:28 +0000 From: Richard Mortier To: Brian Brietzke Date: Wed, 10 Dec 2014 21:20:26 +0000 Thread-Topic: [MirageOS-devel] Mirage and External Data Storage Thread-Index: AdAUvx6UwLxuxGMaRiak4j95cowINw== Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2679807587152965559==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2679807587152965559== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609 Content-Type: multipart/alternative; boundary="Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06" --Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10 Dec 2014, at 19:58, Brian Brietzke wrote: > I think I may have my own answer, but I thought I would ask anyways.=20= =20 >=20 > I would like to be able to interface the Mirage images ( either running o= n xen or just through unix ) to be able to contact external data storage sy= stems ( i.e. postgresql, mysql, redis, mongodb ) so that it can some data p= rocessing.=20=20 >=20 > I tried using sqlite3 with the bindings for OCaml, and it gave me an erro= r that it can't load then extensions, which makes perfect sense. The files= the library is looking don't exist inside the tiny world of the Mirage vir= tual machine.=20=20 >=20 > That means that we would have to use a client library which is totally wr= itten in OCaml, no linkages to external dependencies. That severally limit= s the number of client libraries available, which could or could not be a b= ad thing.=20=20 >=20 > Is this assumption correct?=20=20 yes, that sound right to me. you can depend on mirage libs but not on exter= nal libraries that pull in OS dependencies via the filesystem, threading, p= rocesses, whatever. > I'm assuming that it would be a very difficult ( if not an impossible ) t= ask to make the C libraries available from postgresql or sqlite into the Mi= rage OS.=20=20 tricky but technically not impossible i think. the trick is to remove all e= xternal (POSIX) dependencies... :) another option might be to interface using a network protocol-- i'm not par= ticularly familiar with those storage systems directly, but if any support = (e.g.) an http or other network protocol api, implementing that for mirage = (ie., in pure ocaml) *might* be a more straightforward option... --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=
On 10 Dec 2014, at 19:58, Brian Brietzke <bbrietzke@gmail.com> wrote:
I think I may have my own answer, but I thought I would ask= anyways.  

I woul= d like to be able to interface the Mirage images ( either running on xen or= just through unix ) to be able to contact external data storage systems ( = i.e. postgresql, mysql, redis, mongodb ) so that it can some data processin= g.  

I tried= using sqlite3 with the bindings for OCaml, and it gave me an error th= at it can't load then extensions, which makes perfect sense.  The= files the library is looking don't exist inside the tiny world of the Mira= ge virtual machine.  

That means that we would have to use a client library which is to= tally written in OCaml, no linkages to external dependencies.  That se= verally limits the number of client libraries available, which could or cou= ld not be a bad thing.  

Is this assumption correct?  

yes, that sound right to me. you can depend on mirag= e libs but not on external libraries that pull in OS dependencies via the f= ilesystem, threading, processes, whatever.

I'm assuming= that it would be a very difficult ( if not an impossible ) task to make th= e C libraries available from postgresql or sqlite into the Mirage OS.  = ;

tricky but technic= ally not impossible i think. the trick is to remove all external (POSIX) de= pendencies... :)

another option might b= e to interface using a network protocol-- i'm not particularly familiar wit= h those storage systems directly, but if any support (e.g.) an http or othe= r network protocol api, implementing that for mirage (ie., in pure ocaml) *= might* be a more straightforward option...

-- 
Cheers,

R.

[ T= his address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ]





This message and any attachment are intended solely for the addressee and m=
ay contain confidential information. If you have received this message in e=
rror, please send it back to me, and immediately delete it.   Please do not=
 use, copy or disclose the information contained in this message or in any =
attachment.  Any views or opinions expressed by the author of this email do=
 not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment=
 may still contain software viruses which could damage your computer system=
, you are advised to perform your own checks. Email communications with the=
 University of Nottingham may be monitored as permitted by UK legislation.
= --Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06-- --Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUiLkaAAoJEOLF27JWwSg37jsP/RUYtJ/mJ/ZlkXEQq9o7wQLx zFdKCzysgeRABcvlLxQSey5PaZuJJ/dkPJ9WrW0E7rNZMtrdQubith9TZhfmQLpe a4n2jcuWNdzt1VGd9ryleWTj+kE7IcfqJN+O9TRvvMyyW7H69UWmEf6UbpyVGMzs DfTJc77JxfIHFt9MZUOzeeORfHux7UdZaph/4RBXFvc02MTDu3GF3SCuXm5P5UxT YhKS3PhcU9/5WNq3Tyt1u0fVouZRy3tYq1C/ISZmkKOJdta8jXgsxAdvdYKk0bAd bCFGQbXAQe53XgHakiAQDSO4sLBUyXSkQkPCsI+iotl0BgzwjcuUJQ72wlfqNid/ jgsB0UwncZQBrsWcJWlh+s+llEIu+mGKFi6szBzRzEFGE1+LwubO98W87bYQOazs JNr+TmPgdvwMAjJMWcejuVEqccpdzewoXaUEYjv44xghLZQeWOqwkBo/qYRBMiwt 7limH/PCtXDLOsvRuTznBgL6HoUjAsYf3EPw+Kur1tamppm/0kjMYhkUM2VjG1bx ufsk8I//5JsVfbn07h9hzsH75Gxzh+0NsYnncuq7LQz6agLoh96Dav/XCEbGtN8r H/mUOkWpmMeTRpNojxvr1R++xxARGWCcE8MAWPth0WdHKgOxkxTw12z6d3AKWNNE /HM41biI1zx+InQkiwq9 =u37/ -----END PGP SIGNATURE----- --Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609-- --===============2679807587152965559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2679807587152965559==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 10 21:20:38 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 10 Dec 2014 21:20:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyogS-0007tZ-SW; Wed, 10 Dec 2014 21:20:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyogR-0007tU-2H for mirageos-devel@lists.xenproject.org; Wed, 10 Dec 2014 21:20:31 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id E9/B2-03148-E19B8845; Wed, 10 Dec 2014 21:20:30 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-9.tower-27.messagelabs.com!1418246429!14259664!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12839 invoked from network); 10 Dec 2014 21:20:29 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-9.tower-27.messagelabs.com with SMTP; 10 Dec 2014 21:20:29 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B099441950C_488B91CB for ; Wed, 10 Dec 2014 21:20:28 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 6C53D401C53_488B91CF for ; Wed, 10 Dec 2014 21:20:28 +0000 (GMT) Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1XyogO-0003Sx-Cq; Wed, 10 Dec 2014 21:20:28 +0000 From: Richard Mortier To: Brian Brietzke Date: Wed, 10 Dec 2014 21:20:26 +0000 Thread-Topic: [MirageOS-devel] Mirage and External Data Storage Thread-Index: AdAUvx6UwLxuxGMaRiak4j95cowINw== Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2679807587152965559==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2679807587152965559== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609 Content-Type: multipart/alternative; boundary="Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06" --Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10 Dec 2014, at 19:58, Brian Brietzke wrote: > I think I may have my own answer, but I thought I would ask anyways.=20= =20 >=20 > I would like to be able to interface the Mirage images ( either running o= n xen or just through unix ) to be able to contact external data storage sy= stems ( i.e. postgresql, mysql, redis, mongodb ) so that it can some data p= rocessing.=20=20 >=20 > I tried using sqlite3 with the bindings for OCaml, and it gave me an erro= r that it can't load then extensions, which makes perfect sense. The files= the library is looking don't exist inside the tiny world of the Mirage vir= tual machine.=20=20 >=20 > That means that we would have to use a client library which is totally wr= itten in OCaml, no linkages to external dependencies. That severally limit= s the number of client libraries available, which could or could not be a b= ad thing.=20=20 >=20 > Is this assumption correct?=20=20 yes, that sound right to me. you can depend on mirage libs but not on exter= nal libraries that pull in OS dependencies via the filesystem, threading, p= rocesses, whatever. > I'm assuming that it would be a very difficult ( if not an impossible ) t= ask to make the C libraries available from postgresql or sqlite into the Mi= rage OS.=20=20 tricky but technically not impossible i think. the trick is to remove all e= xternal (POSIX) dependencies... :) another option might be to interface using a network protocol-- i'm not par= ticularly familiar with those storage systems directly, but if any support = (e.g.) an http or other network protocol api, implementing that for mirage = (ie., in pure ocaml) *might* be a more straightforward option... --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=
On 10 Dec 2014, at 19:58, Brian Brietzke <bbrietzke@gmail.com> wrote:
I think I may have my own answer, but I thought I would ask= anyways.  

I woul= d like to be able to interface the Mirage images ( either running on xen or= just through unix ) to be able to contact external data storage systems ( = i.e. postgresql, mysql, redis, mongodb ) so that it can some data processin= g.  

I tried= using sqlite3 with the bindings for OCaml, and it gave me an error th= at it can't load then extensions, which makes perfect sense.  The= files the library is looking don't exist inside the tiny world of the Mira= ge virtual machine.  

That means that we would have to use a client library which is to= tally written in OCaml, no linkages to external dependencies.  That se= verally limits the number of client libraries available, which could or cou= ld not be a bad thing.  

Is this assumption correct?  

yes, that sound right to me. you can depend on mirag= e libs but not on external libraries that pull in OS dependencies via the f= ilesystem, threading, processes, whatever.

I'm assuming= that it would be a very difficult ( if not an impossible ) task to make th= e C libraries available from postgresql or sqlite into the Mirage OS.  = ;

tricky but technic= ally not impossible i think. the trick is to remove all external (POSIX) de= pendencies... :)

another option might b= e to interface using a network protocol-- i'm not particularly familiar wit= h those storage systems directly, but if any support (e.g.) an http or othe= r network protocol api, implementing that for mirage (ie., in pure ocaml) *= might* be a more straightforward option...

-- 
Cheers,

R.

[ T= his address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ]





This message and any attachment are intended solely for the addressee and m=
ay contain confidential information. If you have received this message in e=
rror, please send it back to me, and immediately delete it.   Please do not=
 use, copy or disclose the information contained in this message or in any =
attachment.  Any views or opinions expressed by the author of this email do=
 not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment=
 may still contain software viruses which could damage your computer system=
, you are advised to perform your own checks. Email communications with the=
 University of Nottingham may be monitored as permitted by UK legislation.
= --Apple-Mail=_A6215B41-0E05-41B0-982B-5F53D7AB1E06-- --Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUiLkaAAoJEOLF27JWwSg37jsP/RUYtJ/mJ/ZlkXEQq9o7wQLx zFdKCzysgeRABcvlLxQSey5PaZuJJ/dkPJ9WrW0E7rNZMtrdQubith9TZhfmQLpe a4n2jcuWNdzt1VGd9ryleWTj+kE7IcfqJN+O9TRvvMyyW7H69UWmEf6UbpyVGMzs DfTJc77JxfIHFt9MZUOzeeORfHux7UdZaph/4RBXFvc02MTDu3GF3SCuXm5P5UxT YhKS3PhcU9/5WNq3Tyt1u0fVouZRy3tYq1C/ISZmkKOJdta8jXgsxAdvdYKk0bAd bCFGQbXAQe53XgHakiAQDSO4sLBUyXSkQkPCsI+iotl0BgzwjcuUJQ72wlfqNid/ jgsB0UwncZQBrsWcJWlh+s+llEIu+mGKFi6szBzRzEFGE1+LwubO98W87bYQOazs JNr+TmPgdvwMAjJMWcejuVEqccpdzewoXaUEYjv44xghLZQeWOqwkBo/qYRBMiwt 7limH/PCtXDLOsvRuTznBgL6HoUjAsYf3EPw+Kur1tamppm/0kjMYhkUM2VjG1bx ufsk8I//5JsVfbn07h9hzsH75Gxzh+0NsYnncuq7LQz6agLoh96Dav/XCEbGtN8r H/mUOkWpmMeTRpNojxvr1R++xxARGWCcE8MAWPth0WdHKgOxkxTw12z6d3AKWNNE /HM41biI1zx+InQkiwq9 =u37/ -----END PGP SIGNATURE----- --Apple-Mail=_9CC104C4-26BB-45E6-9D44-2DBC926A1609-- --===============2679807587152965559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2679807587152965559==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 01:41:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 01:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyskg-0006uO-V6; Thu, 11 Dec 2014 01:41:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyske-0006uJ-VF for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:41:09 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id 2C/2D-02696-436F8845; Thu, 11 Dec 2014 01:41:08 +0000 X-Env-Sender: louis.gesbert@ocamlpro.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1418262065!8879910!1 X-Originating-IP: [212.227.17.13] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11858 invoked from network); 11 Dec 2014 01:41:06 -0000 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.13) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Dec 2014 01:41:06 -0000 Received: from agaric.localnet ([111.64.65.75]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0Mhl9H-1YLcR32L4N-00Mwts; Thu, 11 Dec 2014 02:41:03 +0100 From: Louis Gesbert To: opam-devel@lists.ocaml.org Date: Thu, 11 Dec 2014 10:40:57 +0900 Message-ID: <5123334.al3TCFKHKs@agaric> Organization: OCamlPro User-Agent: KMail/4.14.1 (Linux/3.16-2-amd64; KDE/4.14.1; x86_64; ; ) In-Reply-To: <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> MIME-Version: 1.0 X-Provags-ID: V03:K0:olV0a33is1Y5waQRPfP2Dai45a9FB5CkYNNZHgQrO7fsqkkMV6z eSYsjKrKpLan036vjxd2Q0pmtAC9Enog/xcve1YhTu+iwYuo9bGpAD0AuX1LfzAENRHm/Tz pHD4PHtJUiVjTzjApTt6tRAX86ORCiKK6pzBasDNgM/3+o5pkBJGS84HvDXXRw1MYbv6xJy HvhgItsdvU2DR8TvvBkeQ== X-UI-Out-Filterresults: notjunk:1; Cc: mirageos-devel , Anil Madhavapeddy Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org It's indeed completely broken, that's bad news indeed. But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. Here is the original report: https://github.com/ocaml/opam/issues/1683 Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 Hope they can act on it quickly... Thanks for notifying and helping trace this! Louis > - Anil Madhavapeddy, 10/12/2014 14:54 - > I just reproduced it by following the referenced bug report. > > From a fresh Ubuntu 14.10, if I do: > > $ sudo apt-get install opam camlp4-extra aspcud > $ opam init -a > $ opam install mirage -y > $ eval `opam config env` > > At this point some packages have been installed and mirage is installed. > > Now however, if I use mirage it invokes opam install again and packages > are reinstalled as a duplicate. See below: > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > [NOTE] Package lwt is already installed (current version is 2.4.6). > [NOTE] Package io-page is already installed (current version is 1.1.1). > [NOTE] Package cstruct is already installed (current version is 1.4.0). > [NOTE] Package crunch is already installed (current version is 1.3.0). > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > The following actions will be performed: > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-bigarray.base [required by cowabloga] > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install xmlm.1.2.0 [required by cowabloga] > - install uutf.0.9.3 [required by cowabloga] > - install stringext.1.1.0 [required by cowabloga, mirage-http] > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install re.1.2.2 [required by cowabloga, mirage-http] > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install hex.0.1.0 [required by cowabloga] > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > - install base64.1.0.0 [required by cowabloga, mirage-http] > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > - install ulex.1.1 [required by cowabloga] > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install omd.1.2.3 [required by cowabloga] > - install jsonm.0.9.1 [required by cowabloga] > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install crunch.1.3.0 > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > - install dyntype.0.9.0 [required by cowabloga] > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install uri.1.7.2 [required by cowabloga, mirage-http] > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > Any inspiration from there from the CUDF interactions in the above gist? > > -anil > > > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > > > I've been trying to reproduce the issue, but things seem fine, sort of: > > > > From what I could gather: > > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > > ``` > > ===== ERROR while installing ocamlfind.1.5.5 ===== > > Internal error: > > "ocamlfind": command not found. > > ``` > > > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > > > Cheers, > > Louis > > > > > > [1] https://github.com/ocaml/opam/issues/1683 > > [2] https://github.com/ocaml/opam/issues/1658 > > > > - Anil Madhavapeddy, 09/12/2014 11:16 - > >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > >> > >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > >> > >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > >> > >> -anil > >> _______________________________________________ > >> opam-devel mailing list > >> opam-devel@lists.ocaml.org > >> http://lists.ocaml.org/listinfo/opam-devel > > _______________________________________________ > > opam-devel mailing list > > opam-devel@lists.ocaml.org > > http://lists.ocaml.org/listinfo/opam-devel > > > > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 01:41:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 01:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyskg-0006uO-V6; Thu, 11 Dec 2014 01:41:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xyske-0006uJ-VF for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:41:09 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id 2C/2D-02696-436F8845; Thu, 11 Dec 2014 01:41:08 +0000 X-Env-Sender: louis.gesbert@ocamlpro.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1418262065!8879910!1 X-Originating-IP: [212.227.17.13] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11858 invoked from network); 11 Dec 2014 01:41:06 -0000 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.13) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Dec 2014 01:41:06 -0000 Received: from agaric.localnet ([111.64.65.75]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0Mhl9H-1YLcR32L4N-00Mwts; Thu, 11 Dec 2014 02:41:03 +0100 From: Louis Gesbert To: opam-devel@lists.ocaml.org Date: Thu, 11 Dec 2014 10:40:57 +0900 Message-ID: <5123334.al3TCFKHKs@agaric> Organization: OCamlPro User-Agent: KMail/4.14.1 (Linux/3.16-2-amd64; KDE/4.14.1; x86_64; ; ) In-Reply-To: <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> MIME-Version: 1.0 X-Provags-ID: V03:K0:olV0a33is1Y5waQRPfP2Dai45a9FB5CkYNNZHgQrO7fsqkkMV6z eSYsjKrKpLan036vjxd2Q0pmtAC9Enog/xcve1YhTu+iwYuo9bGpAD0AuX1LfzAENRHm/Tz pHD4PHtJUiVjTzjApTt6tRAX86ORCiKK6pzBasDNgM/3+o5pkBJGS84HvDXXRw1MYbv6xJy HvhgItsdvU2DR8TvvBkeQ== X-UI-Out-Filterresults: notjunk:1; Cc: mirageos-devel , Anil Madhavapeddy Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org It's indeed completely broken, that's bad news indeed. But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. Here is the original report: https://github.com/ocaml/opam/issues/1683 Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 Hope they can act on it quickly... Thanks for notifying and helping trace this! Louis > - Anil Madhavapeddy, 10/12/2014 14:54 - > I just reproduced it by following the referenced bug report. > > From a fresh Ubuntu 14.10, if I do: > > $ sudo apt-get install opam camlp4-extra aspcud > $ opam init -a > $ opam install mirage -y > $ eval `opam config env` > > At this point some packages have been installed and mirage is installed. > > Now however, if I use mirage it invokes opam install again and packages > are reinstalled as a duplicate. See below: > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > [NOTE] Package lwt is already installed (current version is 2.4.6). > [NOTE] Package io-page is already installed (current version is 1.1.1). > [NOTE] Package cstruct is already installed (current version is 1.4.0). > [NOTE] Package crunch is already installed (current version is 1.3.0). > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > The following actions will be performed: > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install base-bigarray.base [required by cowabloga] > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > - install xmlm.1.2.0 [required by cowabloga] > - install uutf.0.9.3 [required by cowabloga] > - install stringext.1.1.0 [required by cowabloga, mirage-http] > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install re.1.2.2 [required by cowabloga, mirage-http] > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > - install hex.0.1.0 [required by cowabloga] > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > - install base64.1.0.0 [required by cowabloga, mirage-http] > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > - install ulex.1.1 [required by cowabloga] > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install omd.1.2.3 [required by cowabloga] > - install jsonm.0.9.1 [required by cowabloga] > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > - install crunch.1.3.0 > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > - install dyntype.0.9.0 [required by cowabloga] > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > - install uri.1.7.2 [required by cowabloga, mirage-http] > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > Any inspiration from there from the CUDF interactions in the above gist? > > -anil > > > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > > > I've been trying to reproduce the issue, but things seem fine, sort of: > > > > From what I could gather: > > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > > ``` > > ===== ERROR while installing ocamlfind.1.5.5 ===== > > Internal error: > > "ocamlfind": command not found. > > ``` > > > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > > > Cheers, > > Louis > > > > > > [1] https://github.com/ocaml/opam/issues/1683 > > [2] https://github.com/ocaml/opam/issues/1658 > > > > - Anil Madhavapeddy, 09/12/2014 11:16 - > >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > >> > >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > >> > >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > >> > >> -anil > >> _______________________________________________ > >> opam-devel mailing list > >> opam-devel@lists.ocaml.org > >> http://lists.ocaml.org/listinfo/opam-devel > > _______________________________________________ > > opam-devel mailing list > > opam-devel@lists.ocaml.org > > http://lists.ocaml.org/listinfo/opam-devel > > > > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 01:54:09 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 01:54:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XysxE-0007xa-Kj; Thu, 11 Dec 2014 01:54:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XysxD-0007xQ-EB for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:54:07 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 14/A0-26858-E39F8845; Thu, 11 Dec 2014 01:54:06 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-9.tower-31.messagelabs.com!1418262828!8764994!1 X-Originating-IP: [209.85.215.41] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13459 invoked from network); 11 Dec 2014 01:53:48 -0000 Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 01:53:48 -0000 Received: by mail-la0-f41.google.com with SMTP id hv19so3500680lab.28 for ; Wed, 10 Dec 2014 17:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NzzMoMEbY+EY724QMs4ujqHFytAKMLyJFFAo6moPwNY=; b=A2rd12yZoO+CnduZtnHEVKNWajHZter41d8aEIJ4qeus7j3Iq9h2jdHqVnaQ/KxmE0 J1wqTwyS8p6gTlwFEXw63e/MD7r6rlDj3yworxE8bOPfIGZ9UNtyGNnWM+S9wRMdBmI+ TpGCQFCmqVZIT6QEmaBZStJ9ACdwzZ/cnFEqVeTxu58O3L1e/4q+f26e+rJOqJlfCS4n /52QBlCdhu58aZARNfyNvXhmikuowsRe82cZhY2fLn5D0vj5tM2QNFul4NnVQ3aQ8TbX hjh/D7E2YR4qGcdEksTj4lv7wf4OfBhifwAReVMfyNl+QXPMmUTtPCZh8Fja8EVyGWlq 6ZCQ== MIME-Version: 1.0 X-Received: by 10.112.201.72 with SMTP id jy8mr6991942lbc.65.1418262827963; Wed, 10 Dec 2014 17:53:47 -0800 (PST) Received: by 10.112.48.65 with HTTP; Wed, 10 Dec 2014 17:53:47 -0800 (PST) In-Reply-To: References: Date: Wed, 10 Dec 2014 19:53:47 -0600 Message-ID: From: Brian Brietzke To: Richard Mortier Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4535144196557155165==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4535144196557155165== Content-Type: multipart/alternative; boundary=001a11c372da0f24c80509e70c14 --001a11c372da0f24c80509e70c14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I appreciate the feedback, Richard. There are implementations of the protocols for mysql and postgresql that popular. I've done some digging and have found pure ocaml implementations for both redis and mongo. I'll have to do some experimenting and see what the results are like. I'll leave it to folks far smarter and crazier than I am to remove the external POSIX dependencies from things likes of libmysqlclient. On Wed, Dec 10, 2014 at 3:20 PM, Richard Mortier < Richard.Mortier@nottingham.ac.uk> wrote: > > On 10 Dec 2014, at 19:58, Brian Brietzke wrote: > > I think I may have my own answer, but I thought I would ask anyways. > > I would like to be able to interface the Mirage images ( either running o= n > xen or just through unix ) to be able to contact external data storage > systems ( i.e. postgresql, mysql, redis, mongodb ) so that it can some da= ta > processing. > > I tried using sqlite3 with the bindings for OCaml, and it gave me an erro= r > that it can't load then extensions, which makes perfect sense. The files > the library is looking don't exist inside the tiny world of the Mirage > virtual machine. > > That means that we would have to use a client library which is totally > written in OCaml, no linkages to external dependencies. That severally > limits the number of client libraries available, which could or could not > be a bad thing. > > Is this assumption correct? > > > yes, that sound right to me. you can depend on mirage libs but not on > external libraries that pull in OS dependencies via the filesystem, > threading, processes, whatever. > > I'm assuming that it would be a very difficult ( if not an impossible ) > task to make the C libraries available from postgresql or sqlite into the > Mirage OS. > > > tricky but technically not impossible i think. the trick is to remove all > external (POSIX) dependencies... :) > > another option might be to interface using a network protocol-- i'm not > particularly familiar with those storage systems directly, but if any > support (e.g.) an http or other network protocol api, implementing that f= or > mirage (ie., in pure ocaml) *might* be a more straightforward option... > > -- > Cheers, > > R. > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk > subsequently. ] > > > > > > This message and any attachment are intended solely for the addressee and= may contain confidential information. If you have received this message in= error, please send it back to me, and immediately delete it. Please do n= ot use, copy or disclose the information contained in this message or in an= y attachment. Any views or opinions expressed by the author of this email = do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachme= nt may still contain software viruses which could damage your computer syst= em, you are advised to perform your own checks. Email communications with t= he University of Nottingham may be monitored as permitted by UK legislation= . > > --001a11c372da0f24c80509e70c14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I appreciate the feedback, Richard. =C2=A0

<= div>There are implementations of the protocols for mysql and postgresql tha= t popular.=C2=A0 I've done some digging and have found pure ocaml imple= mentations for both redis and mongo.=C2=A0 I'll have to do some experim= enting and see what the results are like.

I'll= leave it to folks far smarter and crazier than I am to remove the external= POSIX dependencies from things likes of libmysqlclient.

On Wed, Dec 10, 2014 at = 3:20 PM, Richard Mortier <Richard.Mortier@nottingham.ac.uk<= /a>> wrote:


I think I may have my own answer, but I thought I would ask any= ways. =C2=A0

I would like to be able to interface the Mi= rage images ( either running on xen or just through unix ) to be able to co= ntact external data storage systems ( i.e. postgresql, mysql, redis, mongod= b ) so that it can some data processing. =C2=A0

I = tried using sqlite3 with the bindings for=C2=A0OCaml, and it gave me an err= or that it can't load then extensions,=C2=A0which makes perfect sense.= =C2=A0 The files the library is looking don't exist inside the tiny wor= ld of the Mirage virtual machine. =C2=A0

That mean= s that we would have to use a client library which is totally written in OC= aml, no linkages to external dependencies.=C2=A0 That severally limits the = number of client libraries available, which could or could not be a bad thi= ng. =C2=A0

Is this assumption correct? =C2=A0

yes, that sound right to me. you = can depend on mirage libs but not on external libraries that pull in OS dep= endencies via the filesystem, threading, processes, whatever.

I'm a= ssuming that it would be a very difficult ( if not an impossible ) task to = make the C libraries available from postgresql or sqlite into the Mirage OS= . =C2=A0

tricky but tech= nically not impossible i think. the trick is to remove all external (POSIX)= dependencies... :)

another option might be to int= erface using a network protocol-- i'm not particularly familiar with th= ose storage systems directly, but if any support (e.g.) an http or other ne= twork protocol api, implementing that for mirage (ie., in pure ocaml) *migh= t* be a more straightforward option...

--=C2=A0<= /div>
Cheers,

R.

[ This address fails on Dec31. Use richard.mortier@cl.ca= m.ac.uk subsequently. ]

<= /font>



This message and any attachment are intended solely for the addressee and m=
ay contain confidential information. If you have received this message in e=
rror, please send it back to me, and immediately delete it.   Please do not=
 use, copy or disclose the information contained in this message or in any =
attachment.  Any views or opinions expressed by the author of this email do=
 not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment=
 may still contain software viruses which could damage your computer system=
, you are advised to perform your own checks. Email communications with the=
 University of Nottingham may be monitored as permitted by UK legislation.

--001a11c372da0f24c80509e70c14-- --===============4535144196557155165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4535144196557155165==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 01:54:09 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 01:54:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XysxE-0007xa-Kj; Thu, 11 Dec 2014 01:54:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XysxD-0007xQ-EB for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 01:54:07 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 14/A0-26858-E39F8845; Thu, 11 Dec 2014 01:54:06 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-9.tower-31.messagelabs.com!1418262828!8764994!1 X-Originating-IP: [209.85.215.41] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13459 invoked from network); 11 Dec 2014 01:53:48 -0000 Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 01:53:48 -0000 Received: by mail-la0-f41.google.com with SMTP id hv19so3500680lab.28 for ; Wed, 10 Dec 2014 17:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NzzMoMEbY+EY724QMs4ujqHFytAKMLyJFFAo6moPwNY=; b=A2rd12yZoO+CnduZtnHEVKNWajHZter41d8aEIJ4qeus7j3Iq9h2jdHqVnaQ/KxmE0 J1wqTwyS8p6gTlwFEXw63e/MD7r6rlDj3yworxE8bOPfIGZ9UNtyGNnWM+S9wRMdBmI+ TpGCQFCmqVZIT6QEmaBZStJ9ACdwzZ/cnFEqVeTxu58O3L1e/4q+f26e+rJOqJlfCS4n /52QBlCdhu58aZARNfyNvXhmikuowsRe82cZhY2fLn5D0vj5tM2QNFul4NnVQ3aQ8TbX hjh/D7E2YR4qGcdEksTj4lv7wf4OfBhifwAReVMfyNl+QXPMmUTtPCZh8Fja8EVyGWlq 6ZCQ== MIME-Version: 1.0 X-Received: by 10.112.201.72 with SMTP id jy8mr6991942lbc.65.1418262827963; Wed, 10 Dec 2014 17:53:47 -0800 (PST) Received: by 10.112.48.65 with HTTP; Wed, 10 Dec 2014 17:53:47 -0800 (PST) In-Reply-To: References: Date: Wed, 10 Dec 2014 19:53:47 -0600 Message-ID: From: Brian Brietzke To: Richard Mortier Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4535144196557155165==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4535144196557155165== Content-Type: multipart/alternative; boundary=001a11c372da0f24c80509e70c14 --001a11c372da0f24c80509e70c14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I appreciate the feedback, Richard. There are implementations of the protocols for mysql and postgresql that popular. I've done some digging and have found pure ocaml implementations for both redis and mongo. I'll have to do some experimenting and see what the results are like. I'll leave it to folks far smarter and crazier than I am to remove the external POSIX dependencies from things likes of libmysqlclient. On Wed, Dec 10, 2014 at 3:20 PM, Richard Mortier < Richard.Mortier@nottingham.ac.uk> wrote: > > On 10 Dec 2014, at 19:58, Brian Brietzke wrote: > > I think I may have my own answer, but I thought I would ask anyways. > > I would like to be able to interface the Mirage images ( either running o= n > xen or just through unix ) to be able to contact external data storage > systems ( i.e. postgresql, mysql, redis, mongodb ) so that it can some da= ta > processing. > > I tried using sqlite3 with the bindings for OCaml, and it gave me an erro= r > that it can't load then extensions, which makes perfect sense. The files > the library is looking don't exist inside the tiny world of the Mirage > virtual machine. > > That means that we would have to use a client library which is totally > written in OCaml, no linkages to external dependencies. That severally > limits the number of client libraries available, which could or could not > be a bad thing. > > Is this assumption correct? > > > yes, that sound right to me. you can depend on mirage libs but not on > external libraries that pull in OS dependencies via the filesystem, > threading, processes, whatever. > > I'm assuming that it would be a very difficult ( if not an impossible ) > task to make the C libraries available from postgresql or sqlite into the > Mirage OS. > > > tricky but technically not impossible i think. the trick is to remove all > external (POSIX) dependencies... :) > > another option might be to interface using a network protocol-- i'm not > particularly familiar with those storage systems directly, but if any > support (e.g.) an http or other network protocol api, implementing that f= or > mirage (ie., in pure ocaml) *might* be a more straightforward option... > > -- > Cheers, > > R. > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk > subsequently. ] > > > > > > This message and any attachment are intended solely for the addressee and= may contain confidential information. If you have received this message in= error, please send it back to me, and immediately delete it. Please do n= ot use, copy or disclose the information contained in this message or in an= y attachment. Any views or opinions expressed by the author of this email = do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachme= nt may still contain software viruses which could damage your computer syst= em, you are advised to perform your own checks. Email communications with t= he University of Nottingham may be monitored as permitted by UK legislation= . > > --001a11c372da0f24c80509e70c14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I appreciate the feedback, Richard. =C2=A0

<= div>There are implementations of the protocols for mysql and postgresql tha= t popular.=C2=A0 I've done some digging and have found pure ocaml imple= mentations for both redis and mongo.=C2=A0 I'll have to do some experim= enting and see what the results are like.

I'll= leave it to folks far smarter and crazier than I am to remove the external= POSIX dependencies from things likes of libmysqlclient.

On Wed, Dec 10, 2014 at = 3:20 PM, Richard Mortier <Richard.Mortier@nottingham.ac.uk<= /a>> wrote:


I think I may have my own answer, but I thought I would ask any= ways. =C2=A0

I would like to be able to interface the Mi= rage images ( either running on xen or just through unix ) to be able to co= ntact external data storage systems ( i.e. postgresql, mysql, redis, mongod= b ) so that it can some data processing. =C2=A0

I = tried using sqlite3 with the bindings for=C2=A0OCaml, and it gave me an err= or that it can't load then extensions,=C2=A0which makes perfect sense.= =C2=A0 The files the library is looking don't exist inside the tiny wor= ld of the Mirage virtual machine. =C2=A0

That mean= s that we would have to use a client library which is totally written in OC= aml, no linkages to external dependencies.=C2=A0 That severally limits the = number of client libraries available, which could or could not be a bad thi= ng. =C2=A0

Is this assumption correct? =C2=A0

yes, that sound right to me. you = can depend on mirage libs but not on external libraries that pull in OS dep= endencies via the filesystem, threading, processes, whatever.

I'm a= ssuming that it would be a very difficult ( if not an impossible ) task to = make the C libraries available from postgresql or sqlite into the Mirage OS= . =C2=A0

tricky but tech= nically not impossible i think. the trick is to remove all external (POSIX)= dependencies... :)

another option might be to int= erface using a network protocol-- i'm not particularly familiar with th= ose storage systems directly, but if any support (e.g.) an http or other ne= twork protocol api, implementing that for mirage (ie., in pure ocaml) *migh= t* be a more straightforward option...

--=C2=A0<= /div>
Cheers,

R.

[ This address fails on Dec31. Use richard.mortier@cl.ca= m.ac.uk subsequently. ]

<= /font>



This message and any attachment are intended solely for the addressee and m=
ay contain confidential information. If you have received this message in e=
rror, please send it back to me, and immediately delete it.   Please do not=
 use, copy or disclose the information contained in this message or in any =
attachment.  Any views or opinions expressed by the author of this email do=
 not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment=
 may still contain software viruses which could damage your computer system=
, you are advised to perform your own checks. Email communications with the=
 University of Nottingham may be monitored as permitted by UK legislation.

--001a11c372da0f24c80509e70c14-- --===============4535144196557155165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4535144196557155165==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 14:12:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 14:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4TK-0002EH-5V; Thu, 11 Dec 2014 14:12:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4Du-0001Z1-PU for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:56:07 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 3C/BC-26652-672A9845; Thu, 11 Dec 2014 13:56:06 +0000 X-Env-Sender: rdicosmo@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1418306164!12815088!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31838 invoked from network); 11 Dec 2014 13:56:04 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 13:56:04 -0000 Received: by mail-wg0-f54.google.com with SMTP id l2so6515483wgh.27 for ; Thu, 11 Dec 2014 05:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zNc/zJHBG+XoJy3XnwkiSjVYM5Wc93rVKEIkjSkMf60=; b=reOTqXoD6X+D8rZgYMEw7lkVxmQFqZ20docUkZX3aaWuOwZY2Sqcr19XvwazKxJuGV 34esaeRbfbrNNPjfZ7/3bp43zakDJmvfeOTFPAGiXgGFdBE3v/wZHNGJ2HADTjRPR4aK p84qkhU5yIo3xEru4aVJvQksBGwjPbQO33TgBNONjtDCTpgxP5VXby8M7b/9BRYw3W3J sMg9+bOJESrDNKKKQR3fROIiDj+CaBEI1vYeU/WQfjfsTdJs/nG9IclpY8HjDIhM9M0h ZdZKdp9FfZuNXIL5LdEFgT+OqY4Wgfccs1y8id1l/3mwG/qWSw7HMlgFzPuJoP50+tjz AwRg== X-Received: by 10.180.108.205 with SMTP id hm13mr23771063wib.5.1418306162867; Thu, 11 Dec 2014 05:56:02 -0800 (PST) Received: from traveler ([2001:660:3013:3:5e26:aff:fe33:808f]) by mx.google.com with ESMTPSA id x2sm1806682wjx.9.2014.12.11.05.56.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 05:56:02 -0800 (PST) Received: from dicosmo by traveler with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xz4Do-0007tL-QU; Thu, 11 Dec 2014 14:56:00 +0100 Date: Thu, 11 Dec 2014 14:56:00 +0100 From: Roberto Di Cosmo To: Louis Gesbert Message-ID: <20141211135600.GA30089@traveler> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> <5123334.al3TCFKHKs@agaric> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5123334.al3TCFKHKs@agaric> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 11 Dec 2014 14:12:01 +0000 Cc: opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Just for completeness, here is the info I can confirm after checking with the Debian side: - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with aspcud 1.9 and dose 3.3 - unfortunately, the time-boxed development process of Ubuntu, with a release in mid-October, ended in picking up an inconsistent set of versions of our beloved packages from the Debian timeline; this is not something that only happen to us, it is intrinsically related to these imperfectly aligned processes, and I suppose the Ubuntu people will be quick to act on this, as they are probably used to this kind of events -- Roberto On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: > It's indeed completely broken, that's bad news indeed. > > But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. > > Here is the original report: https://github.com/ocaml/opam/issues/1683 > > Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( > > I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 > Hope they can act on it quickly... > > Thanks for notifying and helping trace this! > Louis > > > - Anil Madhavapeddy, 10/12/2014 14:54 - > > I just reproduced it by following the referenced bug report. > > > > From a fresh Ubuntu 14.10, if I do: > > > > $ sudo apt-get install opam camlp4-extra aspcud > > $ opam init -a > > $ opam install mirage -y > > $ eval `opam config env` > > > > At this point some packages have been installed and mirage is installed. > > > > Now however, if I use mirage it invokes opam install again and packages > > are reinstalled as a duplicate. See below: > > > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > > [NOTE] Package lwt is already installed (current version is 2.4.6). > > [NOTE] Package io-page is already installed (current version is 1.1.1). > > [NOTE] Package cstruct is already installed (current version is 1.4.0). > > [NOTE] Package crunch is already installed (current version is 1.3.0). > > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > > The following actions will be performed: > > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-bigarray.base [required by cowabloga] > > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install xmlm.1.2.0 [required by cowabloga] > > - install uutf.0.9.3 [required by cowabloga] > > - install stringext.1.1.0 [required by cowabloga, mirage-http] > > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install re.1.2.2 [required by cowabloga, mirage-http] > > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install hex.0.1.0 [required by cowabloga] > > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > > - install base64.1.0.0 [required by cowabloga, mirage-http] > > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > > - install ulex.1.1 [required by cowabloga] > > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install omd.1.2.3 [required by cowabloga] > > - install jsonm.0.9.1 [required by cowabloga] > > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install crunch.1.3.0 > > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > > - install dyntype.0.9.0 [required by cowabloga] > > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install uri.1.7.2 [required by cowabloga, mirage-http] > > > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > > > Any inspiration from there from the CUDF interactions in the above gist? > > > > -anil > > > > > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > > > > > I've been trying to reproduce the issue, but things seem fine, sort of: > > > > > > From what I could gather: > > > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > > > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > > > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > > > > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > > > > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > > > ``` > > > ===== ERROR while installing ocamlfind.1.5.5 ===== > > > Internal error: > > > "ocamlfind": command not found. > > > ``` > > > > > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > > > > > Cheers, > > > Louis > > > > > > > > > [1] https://github.com/ocaml/opam/issues/1683 > > > [2] https://github.com/ocaml/opam/issues/1658 > > > > > > - Anil Madhavapeddy, 09/12/2014 11:16 - > > >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > > >> > > >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > > >> > > >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > > >> > > >> -anil > > >> _______________________________________________ > > >> opam-devel mailing list > > >> opam-devel@lists.ocaml.org > > >> http://lists.ocaml.org/listinfo/opam-devel > > > _______________________________________________ > > > opam-devel mailing list > > > opam-devel@lists.ocaml.org > > > http://lists.ocaml.org/listinfo/opam-devel > > > > > > > _______________________________________________ > > opam-devel mailing list > > opam-devel@lists.ocaml.org > > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel -- Roberto Di Cosmo ------------------------------------------------------------------ Professeur En delegation a l'INRIA PPS E-mail: roberto@dicosmo.org Universite Paris Diderot WWW : http://www.dicosmo.org Case 7014 Tel : ++33-(0)1-57 27 92 20 5, Rue Thomas Mann F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo FRANCE. Twitter: http://twitter.com/rdicosmo ------------------------------------------------------------------ Attachments: MIME accepted, Word deprecated http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------ Office location: Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France Metro Bibliotheque Francois Mitterrand, ligne 14/RER C ----------------------------------------------------------------- GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 14:12:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 14:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4TJ-0002E7-Vc; Thu, 11 Dec 2014 14:12:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyzZ4-00081e-Iw for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 08:57:38 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 80/71-07724-18C59845; Thu, 11 Dec 2014 08:57:37 +0000 X-Env-Sender: rdicosmo@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1418288255!12531942!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21195 invoked from network); 11 Dec 2014 08:57:35 -0000 Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 08:57:35 -0000 Received: by mail-wg0-f44.google.com with SMTP id b13so5778288wgh.3 for ; Thu, 11 Dec 2014 00:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IEpommhoWOMiUFYvcUJa+YQNx6QKW8vb1/pPRtQA6N8=; b=hYb+Ly5iGC+NiG/qK/M+z966DG/MMDcgwwCR0cYIB20/dt2fGcizwyztzRUBCGcW2o SVgmLFZIxrypULIPS2SVlFSbJU74Hl01HlR2938ELKlauN97I2N95gFOtjMHAlqW1Leg OC6NVsB7B3GEA1UepzUHdAL2zwtq33hi7GDQxtNDbb8mk+R23ADkU+08wWwAStbcjr8F qkQ3FS5wbKhtFs04n/luza+uV+LdPzwVyw01z4OLJkZ7rR1uVuLMlHtnwZk8syx/Chh/ NIWkIdz15YP26y/bWKzECoCK07MKoW5i0PwB0d4MACEJufqMHuY1GzBQ02zQbJwY80rn u21A== X-Received: by 10.194.92.82 with SMTP id ck18mr14333581wjb.103.1418288255241; Thu, 11 Dec 2014 00:57:35 -0800 (PST) Received: from traveler (nat-216-106.paris.ensam.fr. [193.50.216.106]) by mx.google.com with ESMTPSA id a14sm2052257wib.22.2014.12.11.00.57.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 00:57:34 -0800 (PST) Received: from dicosmo by traveler with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XyzYx-0002bE-2Z; Thu, 11 Dec 2014 09:57:31 +0100 Date: Thu, 11 Dec 2014 09:57:31 +0100 From: Roberto Di Cosmo To: Louis Gesbert Message-ID: <20141211085730.GA7087@traveler> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> <5123334.al3TCFKHKs@agaric> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5123334.al3TCFKHKs@agaric> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 11 Dec 2014 14:12:01 +0000 Cc: opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks Luis, indeed, now I remember, this is the same issue we had with Debian Jessie, see the thread started here https://sympa.inria.fr/sympa/arc/caml-list/2014-10/msg00095.html and then continued offline with Debian maintainers (I'm pointing them to this thread this very moment) Two issues I see: - urgent: fix Jessie an Utopic ... we'll see what the maintainers may do, but it might be too late - important: update our workflow to prevent all this in the future... IMHO, we need to get the dependencies right in the different distributions, and update them as soon as an incompatibility arises. For example, opam 1.1.1 should depend on dose << 3.2.2 ... and this should be linked to the bugs found by Torok back in October Thanks Anil for re-finding this On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: > It's indeed completely broken, that's bad news indeed. > > But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. > > Here is the original report: https://github.com/ocaml/opam/issues/1683 > > Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( > > I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 > Hope they can act on it quickly... > > Thanks for notifying and helping trace this! > Louis > > > - Anil Madhavapeddy, 10/12/2014 14:54 - > > I just reproduced it by following the referenced bug report. > > > > From a fresh Ubuntu 14.10, if I do: > > > > $ sudo apt-get install opam camlp4-extra aspcud > > $ opam init -a > > $ opam install mirage -y > > $ eval `opam config env` > > > > At this point some packages have been installed and mirage is installed. > > > > Now however, if I use mirage it invokes opam install again and packages > > are reinstalled as a duplicate. See below: > > > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > > [NOTE] Package lwt is already installed (current version is 2.4.6). > > [NOTE] Package io-page is already installed (current version is 1.1.1). > > [NOTE] Package cstruct is already installed (current version is 1.4.0). > > [NOTE] Package crunch is already installed (current version is 1.3.0). > > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > > The following actions will be performed: > > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-bigarray.base [required by cowabloga] > > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install xmlm.1.2.0 [required by cowabloga] > > - install uutf.0.9.3 [required by cowabloga] > > - install stringext.1.1.0 [required by cowabloga, mirage-http] > > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install re.1.2.2 [required by cowabloga, mirage-http] > > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install hex.0.1.0 [required by cowabloga] > > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > > - install base64.1.0.0 [required by cowabloga, mirage-http] > > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > > - install ulex.1.1 [required by cowabloga] > > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install omd.1.2.3 [required by cowabloga] > > - install jsonm.0.9.1 [required by cowabloga] > > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install crunch.1.3.0 > > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > > - install dyntype.0.9.0 [required by cowabloga] > > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install uri.1.7.2 [required by cowabloga, mirage-http] > > > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > > > Any inspiration from there from the CUDF interactions in the above gist? > > > > -anil > > > > > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > > > > > I've been trying to reproduce the issue, but things seem fine, sort of: > > > > > > From what I could gather: > > > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > > > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > > > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > > > > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > > > > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > > > ``` > > > ===== ERROR while installing ocamlfind.1.5.5 ===== > > > Internal error: > > > "ocamlfind": command not found. > > > ``` > > > > > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > > > > > Cheers, > > > Louis > > > > > > > > > [1] https://github.com/ocaml/opam/issues/1683 > > > [2] https://github.com/ocaml/opam/issues/1658 > > > > > > - Anil Madhavapeddy, 09/12/2014 11:16 - > > >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > > >> > > >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > > >> > > >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > > >> > > >> -anil > > >> _______________________________________________ > > >> opam-devel mailing list > > >> opam-devel@lists.ocaml.org > > >> http://lists.ocaml.org/listinfo/opam-devel > > > _______________________________________________ > > > opam-devel mailing list > > > opam-devel@lists.ocaml.org > > > http://lists.ocaml.org/listinfo/opam-devel > > > > > > > _______________________________________________ > > opam-devel mailing list > > opam-devel@lists.ocaml.org > > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel -- Roberto Di Cosmo ------------------------------------------------------------------ Professeur En delegation a l'INRIA PPS E-mail: roberto@dicosmo.org Universite Paris Diderot WWW : http://www.dicosmo.org Case 7014 Tel : ++33-(0)1-57 27 92 20 5, Rue Thomas Mann F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo FRANCE. Twitter: http://twitter.com/rdicosmo ------------------------------------------------------------------ Attachments: MIME accepted, Word deprecated http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------ Office location: Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France Metro Bibliotheque Francois Mitterrand, ligne 14/RER C ----------------------------------------------------------------- GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 14:12:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 14:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4TK-0002EC-39; Thu, 11 Dec 2014 14:12:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyzsG-0000OB-1F for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 09:17:28 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 1D/78-25276-72169845; Thu, 11 Dec 2014 09:17:27 +0000 X-Env-Sender: david.allsopp@metastack.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1418289446!11436972!1 X-Originating-IP: [62.13.149.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25825 invoked from network); 11 Dec 2014 09:17:26 -0000 Received: from outmail149101.authsmtp.com (HELO outmail149101.authsmtp.com) (62.13.149.101) by server-16.tower-21.messagelabs.com with SMTP; 11 Dec 2014 09:17:26 -0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBB9HP1v091509; Thu, 11 Dec 2014 09:17:25 GMT Received: from romulus.metastack.com (cpc1-cmbg5-0-0-cust241.5-4.cable.virginm.net [81.98.252.242]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBB9HKKc059344; Thu, 11 Dec 2014 09:17:21 GMT Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id sBB9HJ7u008176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 09:17:19 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 09:17:19 +0000 From: David Allsopp To: Louis Gesbert Thread-Topic: [opam-devel] opam 1.1.1 and aspcud 1.9 Thread-Index: AQHQE6GnY5BqOK8OTUansqanQvJ26pyI60tbgAC0doCAAH+AtA== Date: Thu, 11 Dec 2014 09:17:17 +0000 Message-ID: <48D0749F-FD88-4FB0-A94A-E1EF4A0A4F15@metastack.com> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org>, <5123334.al3TCFKHKs@agaric> In-Reply-To: <5123334.al3TCFKHKs@agaric> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 82cf11a2-8116-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZRRob BmUNCCtbTh09DhhB HRYYMQJRIxwCUgFH N1teMltLNFBcHhBP AmcULwEHT19xWGdl awNbbAJXYEsAVwR0 WUBXQFdQCgdsAwMD AwEeHFoABQw+AwUj ZUNrXXRfEkJydEAz SkwHQ2wHNGV9YGEe Vl1ZdlZQbQoceRtY alB9UXoNMGQEYy5j CTU+bXgCOi1WLWFZ Tx8AKWdaRl4CG3Zl AUlERH0mG0FNTj4r JAEqYgdaTS4A X-Authentic-SMTP: 61633634383431.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.98.252.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Mailman-Approved-At: Thu, 11 Dec 2014 14:12:01 +0000 Cc: "opam-devel@lists.ocaml.org" , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 11 Dec 2014, at 01:41, Louis Gesbert wrote: > > Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( It is indeed 'funny' the feeling of betrayal which a fully-typing yet broken functional program gives :) However, rather than introducing version constraints, wouldn't it be better to introduce a mandatory test step to the build process (one which could possibly be disabled when developing opam, but would definitely be enabled when it's being packaged or compiled by users)? Just a minimal program which fails with if Dose isn't behaving as expected (using this bug as the first test case) David _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 14:12:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 14:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4TK-0002EH-5V; Thu, 11 Dec 2014 14:12:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4Du-0001Z1-PU for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 13:56:07 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 3C/BC-26652-672A9845; Thu, 11 Dec 2014 13:56:06 +0000 X-Env-Sender: rdicosmo@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1418306164!12815088!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31838 invoked from network); 11 Dec 2014 13:56:04 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 13:56:04 -0000 Received: by mail-wg0-f54.google.com with SMTP id l2so6515483wgh.27 for ; Thu, 11 Dec 2014 05:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zNc/zJHBG+XoJy3XnwkiSjVYM5Wc93rVKEIkjSkMf60=; b=reOTqXoD6X+D8rZgYMEw7lkVxmQFqZ20docUkZX3aaWuOwZY2Sqcr19XvwazKxJuGV 34esaeRbfbrNNPjfZ7/3bp43zakDJmvfeOTFPAGiXgGFdBE3v/wZHNGJ2HADTjRPR4aK p84qkhU5yIo3xEru4aVJvQksBGwjPbQO33TgBNONjtDCTpgxP5VXby8M7b/9BRYw3W3J sMg9+bOJESrDNKKKQR3fROIiDj+CaBEI1vYeU/WQfjfsTdJs/nG9IclpY8HjDIhM9M0h ZdZKdp9FfZuNXIL5LdEFgT+OqY4Wgfccs1y8id1l/3mwG/qWSw7HMlgFzPuJoP50+tjz AwRg== X-Received: by 10.180.108.205 with SMTP id hm13mr23771063wib.5.1418306162867; Thu, 11 Dec 2014 05:56:02 -0800 (PST) Received: from traveler ([2001:660:3013:3:5e26:aff:fe33:808f]) by mx.google.com with ESMTPSA id x2sm1806682wjx.9.2014.12.11.05.56.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 05:56:02 -0800 (PST) Received: from dicosmo by traveler with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xz4Do-0007tL-QU; Thu, 11 Dec 2014 14:56:00 +0100 Date: Thu, 11 Dec 2014 14:56:00 +0100 From: Roberto Di Cosmo To: Louis Gesbert Message-ID: <20141211135600.GA30089@traveler> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> <5123334.al3TCFKHKs@agaric> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5123334.al3TCFKHKs@agaric> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 11 Dec 2014 14:12:01 +0000 Cc: opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Just for completeness, here is the info I can confirm after checking with the Debian side: - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with aspcud 1.9 and dose 3.3 - unfortunately, the time-boxed development process of Ubuntu, with a release in mid-October, ended in picking up an inconsistent set of versions of our beloved packages from the Debian timeline; this is not something that only happen to us, it is intrinsically related to these imperfectly aligned processes, and I suppose the Ubuntu people will be quick to act on this, as they are probably used to this kind of events -- Roberto On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: > It's indeed completely broken, that's bad news indeed. > > But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. > > Here is the original report: https://github.com/ocaml/opam/issues/1683 > > Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( > > I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 > Hope they can act on it quickly... > > Thanks for notifying and helping trace this! > Louis > > > - Anil Madhavapeddy, 10/12/2014 14:54 - > > I just reproduced it by following the referenced bug report. > > > > From a fresh Ubuntu 14.10, if I do: > > > > $ sudo apt-get install opam camlp4-extra aspcud > > $ opam init -a > > $ opam install mirage -y > > $ eval `opam config env` > > > > At this point some packages have been installed and mirage is installed. > > > > Now however, if I use mirage it invokes opam install again and packages > > are reinstalled as a duplicate. See below: > > > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > > [NOTE] Package lwt is already installed (current version is 2.4.6). > > [NOTE] Package io-page is already installed (current version is 1.1.1). > > [NOTE] Package cstruct is already installed (current version is 1.4.0). > > [NOTE] Package crunch is already installed (current version is 1.3.0). > > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > > The following actions will be performed: > > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-bigarray.base [required by cowabloga] > > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install xmlm.1.2.0 [required by cowabloga] > > - install uutf.0.9.3 [required by cowabloga] > > - install stringext.1.1.0 [required by cowabloga, mirage-http] > > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install re.1.2.2 [required by cowabloga, mirage-http] > > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install hex.0.1.0 [required by cowabloga] > > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > > - install base64.1.0.0 [required by cowabloga, mirage-http] > > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > > - install ulex.1.1 [required by cowabloga] > > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install omd.1.2.3 [required by cowabloga] > > - install jsonm.0.9.1 [required by cowabloga] > > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install crunch.1.3.0 > > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > > - install dyntype.0.9.0 [required by cowabloga] > > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install uri.1.7.2 [required by cowabloga, mirage-http] > > > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > > > Any inspiration from there from the CUDF interactions in the above gist? > > > > -anil > > > > > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > > > > > I've been trying to reproduce the issue, but things seem fine, sort of: > > > > > > From what I could gather: > > > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > > > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > > > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > > > > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > > > > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > > > ``` > > > ===== ERROR while installing ocamlfind.1.5.5 ===== > > > Internal error: > > > "ocamlfind": command not found. > > > ``` > > > > > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > > > > > Cheers, > > > Louis > > > > > > > > > [1] https://github.com/ocaml/opam/issues/1683 > > > [2] https://github.com/ocaml/opam/issues/1658 > > > > > > - Anil Madhavapeddy, 09/12/2014 11:16 - > > >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > > >> > > >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > > >> > > >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > > >> > > >> -anil > > >> _______________________________________________ > > >> opam-devel mailing list > > >> opam-devel@lists.ocaml.org > > >> http://lists.ocaml.org/listinfo/opam-devel > > > _______________________________________________ > > > opam-devel mailing list > > > opam-devel@lists.ocaml.org > > > http://lists.ocaml.org/listinfo/opam-devel > > > > > > > _______________________________________________ > > opam-devel mailing list > > opam-devel@lists.ocaml.org > > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel -- Roberto Di Cosmo ------------------------------------------------------------------ Professeur En delegation a l'INRIA PPS E-mail: roberto@dicosmo.org Universite Paris Diderot WWW : http://www.dicosmo.org Case 7014 Tel : ++33-(0)1-57 27 92 20 5, Rue Thomas Mann F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo FRANCE. Twitter: http://twitter.com/rdicosmo ------------------------------------------------------------------ Attachments: MIME accepted, Word deprecated http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------ Office location: Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France Metro Bibliotheque Francois Mitterrand, ligne 14/RER C ----------------------------------------------------------------- GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 14:12:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 14:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4TJ-0002E7-Vc; Thu, 11 Dec 2014 14:12:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyzZ4-00081e-Iw for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 08:57:38 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 80/71-07724-18C59845; Thu, 11 Dec 2014 08:57:37 +0000 X-Env-Sender: rdicosmo@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1418288255!12531942!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21195 invoked from network); 11 Dec 2014 08:57:35 -0000 Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 08:57:35 -0000 Received: by mail-wg0-f44.google.com with SMTP id b13so5778288wgh.3 for ; Thu, 11 Dec 2014 00:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IEpommhoWOMiUFYvcUJa+YQNx6QKW8vb1/pPRtQA6N8=; b=hYb+Ly5iGC+NiG/qK/M+z966DG/MMDcgwwCR0cYIB20/dt2fGcizwyztzRUBCGcW2o SVgmLFZIxrypULIPS2SVlFSbJU74Hl01HlR2938ELKlauN97I2N95gFOtjMHAlqW1Leg OC6NVsB7B3GEA1UepzUHdAL2zwtq33hi7GDQxtNDbb8mk+R23ADkU+08wWwAStbcjr8F qkQ3FS5wbKhtFs04n/luza+uV+LdPzwVyw01z4OLJkZ7rR1uVuLMlHtnwZk8syx/Chh/ NIWkIdz15YP26y/bWKzECoCK07MKoW5i0PwB0d4MACEJufqMHuY1GzBQ02zQbJwY80rn u21A== X-Received: by 10.194.92.82 with SMTP id ck18mr14333581wjb.103.1418288255241; Thu, 11 Dec 2014 00:57:35 -0800 (PST) Received: from traveler (nat-216-106.paris.ensam.fr. [193.50.216.106]) by mx.google.com with ESMTPSA id a14sm2052257wib.22.2014.12.11.00.57.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 00:57:34 -0800 (PST) Received: from dicosmo by traveler with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XyzYx-0002bE-2Z; Thu, 11 Dec 2014 09:57:31 +0100 Date: Thu, 11 Dec 2014 09:57:31 +0100 From: Roberto Di Cosmo To: Louis Gesbert Message-ID: <20141211085730.GA7087@traveler> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> <5123334.al3TCFKHKs@agaric> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5123334.al3TCFKHKs@agaric> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 11 Dec 2014 14:12:01 +0000 Cc: opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks Luis, indeed, now I remember, this is the same issue we had with Debian Jessie, see the thread started here https://sympa.inria.fr/sympa/arc/caml-list/2014-10/msg00095.html and then continued offline with Debian maintainers (I'm pointing them to this thread this very moment) Two issues I see: - urgent: fix Jessie an Utopic ... we'll see what the maintainers may do, but it might be too late - important: update our workflow to prevent all this in the future... IMHO, we need to get the dependencies right in the different distributions, and update them as soon as an incompatibility arises. For example, opam 1.1.1 should depend on dose << 3.2.2 ... and this should be linked to the bugs found by Torok back in October Thanks Anil for re-finding this On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: > It's indeed completely broken, that's bad news indeed. > > But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. > > Here is the original report: https://github.com/ocaml/opam/issues/1683 > > Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( > > I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 > Hope they can act on it quickly... > > Thanks for notifying and helping trace this! > Louis > > > - Anil Madhavapeddy, 10/12/2014 14:54 - > > I just reproduced it by following the referenced bug report. > > > > From a fresh Ubuntu 14.10, if I do: > > > > $ sudo apt-get install opam camlp4-extra aspcud > > $ opam init -a > > $ opam install mirage -y > > $ eval `opam config env` > > > > At this point some packages have been installed and mirage is installed. > > > > Now however, if I use mirage it invokes opam install again and packages > > are reinstalled as a duplicate. See below: > > > > opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > > [NOTE] Package mirage-types is already installed (current version is 2.1.0). > > [NOTE] Package lwt is already installed (current version is 2.4.6). > > [NOTE] Package io-page is already installed (current version is 1.1.1). > > [NOTE] Package cstruct is already installed (current version is 1.4.0). > > [NOTE] Package crunch is already installed (current version is 1.3.0). > > [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > > The following actions will be performed: > > - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > > - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install base-bigarray.base [required by cowabloga] > > - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > > - install xmlm.1.2.0 [required by cowabloga] > > - install uutf.0.9.3 [required by cowabloga] > > - install stringext.1.1.0 [required by cowabloga, mirage-http] > > - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install re.1.2.2 [required by cowabloga, mirage-http] > > - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install hex.0.1.0 [required by cowabloga] > > - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > > - install base64.1.0.0 [required by cowabloga, mirage-http] > > - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > > - install ulex.1.1 [required by cowabloga] > > - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install omd.1.2.3 [required by cowabloga] > > - install jsonm.0.9.1 [required by cowabloga] > > - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install crunch.1.3.0 > > - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > > - install dyntype.0.9.0 [required by cowabloga] > > - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > > - install uri.1.7.2 [required by cowabloga, mirage-http] > > > > I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > > gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > > > > Any inspiration from there from the CUDF interactions in the above gist? > > > > -anil > > > > > On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > > > > > > I've been trying to reproduce the issue, but things seem fine, sort of: > > > > > > From what I could gather: > > > * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > > > * utopic (14.10, latest) has 1.1 and aspcud 1.9 > > > * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > > > > > > Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > > > > > > There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > > > ``` > > > ===== ERROR while installing ocamlfind.1.5.5 ===== > > > Internal error: > > > "ocamlfind": command not found. > > > ``` > > > > > > so it would still be nice if they could backport (so that there is a better error) or recommend m4. > > > > > > Cheers, > > > Louis > > > > > > > > > [1] https://github.com/ocaml/opam/issues/1683 > > > [2] https://github.com/ocaml/opam/issues/1658 > > > > > > - Anil Madhavapeddy, 09/12/2014 11:16 - > > >> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > > >> > > >> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > > >> > > >> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > > >> > > >> -anil > > >> _______________________________________________ > > >> opam-devel mailing list > > >> opam-devel@lists.ocaml.org > > >> http://lists.ocaml.org/listinfo/opam-devel > > > _______________________________________________ > > > opam-devel mailing list > > > opam-devel@lists.ocaml.org > > > http://lists.ocaml.org/listinfo/opam-devel > > > > > > > _______________________________________________ > > opam-devel mailing list > > opam-devel@lists.ocaml.org > > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel -- Roberto Di Cosmo ------------------------------------------------------------------ Professeur En delegation a l'INRIA PPS E-mail: roberto@dicosmo.org Universite Paris Diderot WWW : http://www.dicosmo.org Case 7014 Tel : ++33-(0)1-57 27 92 20 5, Rue Thomas Mann F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo FRANCE. Twitter: http://twitter.com/rdicosmo ------------------------------------------------------------------ Attachments: MIME accepted, Word deprecated http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------ Office location: Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France Metro Bibliotheque Francois Mitterrand, ligne 14/RER C ----------------------------------------------------------------- GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 14:12:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 14:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz4TK-0002EC-39; Thu, 11 Dec 2014 14:12:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XyzsG-0000OB-1F for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 09:17:28 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 1D/78-25276-72169845; Thu, 11 Dec 2014 09:17:27 +0000 X-Env-Sender: david.allsopp@metastack.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1418289446!11436972!1 X-Originating-IP: [62.13.149.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25825 invoked from network); 11 Dec 2014 09:17:26 -0000 Received: from outmail149101.authsmtp.com (HELO outmail149101.authsmtp.com) (62.13.149.101) by server-16.tower-21.messagelabs.com with SMTP; 11 Dec 2014 09:17:26 -0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBB9HP1v091509; Thu, 11 Dec 2014 09:17:25 GMT Received: from romulus.metastack.com (cpc1-cmbg5-0-0-cust241.5-4.cable.virginm.net [81.98.252.242]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBB9HKKc059344; Thu, 11 Dec 2014 09:17:21 GMT Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id sBB9HJ7u008176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 09:17:19 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 09:17:19 +0000 From: David Allsopp To: Louis Gesbert Thread-Topic: [opam-devel] opam 1.1.1 and aspcud 1.9 Thread-Index: AQHQE6GnY5BqOK8OTUansqanQvJ26pyI60tbgAC0doCAAH+AtA== Date: Thu, 11 Dec 2014 09:17:17 +0000 Message-ID: <48D0749F-FD88-4FB0-A94A-E1EF4A0A4F15@metastack.com> References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org>, <5123334.al3TCFKHKs@agaric> In-Reply-To: <5123334.al3TCFKHKs@agaric> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 82cf11a2-8116-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZRRob BmUNCCtbTh09DhhB HRYYMQJRIxwCUgFH N1teMltLNFBcHhBP AmcULwEHT19xWGdl awNbbAJXYEsAVwR0 WUBXQFdQCgdsAwMD AwEeHFoABQw+AwUj ZUNrXXRfEkJydEAz SkwHQ2wHNGV9YGEe Vl1ZdlZQbQoceRtY alB9UXoNMGQEYy5j CTU+bXgCOi1WLWFZ Tx8AKWdaRl4CG3Zl AUlERH0mG0FNTj4r JAEqYgdaTS4A X-Authentic-SMTP: 61633634383431.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.98.252.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Mailman-Approved-At: Thu, 11 Dec 2014 14:12:01 +0000 Cc: "opam-devel@lists.ocaml.org" , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 11 Dec 2014, at 01:41, Louis Gesbert wrote: > > Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( It is indeed 'funny' the feeling of betrayal which a fully-typing yet broken functional program gives :) However, rather than introducing version constraints, wouldn't it be better to introduce a mandatory test step to the build process (one which could possibly be disabled when developing opam, but would definitely be enabled when it's being packaged or compiled by users)? Just a minimal program which fails with if Dose isn't behaving as expected (using this bug as the first test case) David _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 19:47:02 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 19:47:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz9hP-00032u-13; Thu, 11 Dec 2014 19:46:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz9hN-00032b-6R for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 19:46:53 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 17/0A-09842-CA4F9845; Thu, 11 Dec 2014 19:46:52 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1418327211!15061860!1 X-Originating-IP: [209.85.215.51] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31181 invoked from network); 11 Dec 2014 19:46:51 -0000 Received: from mail-la0-f51.google.com (HELO mail-la0-f51.google.com) (209.85.215.51) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 19:46:51 -0000 Received: by mail-la0-f51.google.com with SMTP id ms9so4892989lab.10 for ; Thu, 11 Dec 2014 11:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=jTY3SSCjJXKEkf0lLNCG3D4OEA4TBYcqNWbuxLuBsqE=; b=ZVOOerKuoKO8uvY4FQJVhQzyS2DypGUJrpGJFgfsvPz9B0xb8/woIGWAPL86hOCpsD G5g86oG/+DstykIeQBc603LzkXPJsuRb7f8s4PAunf+9XnuPu06Xrs+E4qOPDpKCtPLp n132wkgWUuEccvqtdzpJKjVu4gaZ6P/kSUqeLFkQ/JeqdawK9tWjDInzzZmmiOkrjmQS 1iiSi3v1xd8GevAV6qg9DhPsgoB57SJ3orLVNDSqKWtJx/Qo3+kQhnmq++1M8hA50pgw WWMYHVKf9RcymasoWn8OPIhad8cFP7JUufNrvTC8xu6pP2zpngT1OBmPcr3cHA7lmpM7 4VrA== MIME-Version: 1.0 X-Received: by 10.153.7.170 with SMTP id dd10mr11602423lad.44.1418327211131; Thu, 11 Dec 2014 11:46:51 -0800 (PST) Received: by 10.112.0.104 with HTTP; Thu, 11 Dec 2014 11:46:51 -0800 (PST) Date: Thu, 11 Dec 2014 14:46:51 -0500 X-Google-Sender-Auth: pHn9gd75f98-3gyK4Perd-dUCNY Message-ID: From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-api@lists.xen.org, xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Monday is the Last Xen Project Document Day of 2014 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Monday, December 15, will be our last Document Day of the year. Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays which occur later in the month, we have scheduled Document Day for Monday. This is a great time to get our documentation ready for the new release. Have you added a new feature in this release? Make sure it is in the Wiki. Have you noticed pages which might be confusing for a new installation? Now is a great time to clean it up. Have you information on better integrating Xen Project with other projects? Share that information with others. All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days If you get a few moments before Monday, please take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Monday in #xendocs! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 11 19:47:02 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 11 Dec 2014 19:47:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz9hP-00032u-13; Thu, 11 Dec 2014 19:46:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xz9hN-00032b-6R for mirageos-devel@lists.xenproject.org; Thu, 11 Dec 2014 19:46:53 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 17/0A-09842-CA4F9845; Thu, 11 Dec 2014 19:46:52 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1418327211!15061860!1 X-Originating-IP: [209.85.215.51] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31181 invoked from network); 11 Dec 2014 19:46:51 -0000 Received: from mail-la0-f51.google.com (HELO mail-la0-f51.google.com) (209.85.215.51) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 11 Dec 2014 19:46:51 -0000 Received: by mail-la0-f51.google.com with SMTP id ms9so4892989lab.10 for ; Thu, 11 Dec 2014 11:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=jTY3SSCjJXKEkf0lLNCG3D4OEA4TBYcqNWbuxLuBsqE=; b=ZVOOerKuoKO8uvY4FQJVhQzyS2DypGUJrpGJFgfsvPz9B0xb8/woIGWAPL86hOCpsD G5g86oG/+DstykIeQBc603LzkXPJsuRb7f8s4PAunf+9XnuPu06Xrs+E4qOPDpKCtPLp n132wkgWUuEccvqtdzpJKjVu4gaZ6P/kSUqeLFkQ/JeqdawK9tWjDInzzZmmiOkrjmQS 1iiSi3v1xd8GevAV6qg9DhPsgoB57SJ3orLVNDSqKWtJx/Qo3+kQhnmq++1M8hA50pgw WWMYHVKf9RcymasoWn8OPIhad8cFP7JUufNrvTC8xu6pP2zpngT1OBmPcr3cHA7lmpM7 4VrA== MIME-Version: 1.0 X-Received: by 10.153.7.170 with SMTP id dd10mr11602423lad.44.1418327211131; Thu, 11 Dec 2014 11:46:51 -0800 (PST) Received: by 10.112.0.104 with HTTP; Thu, 11 Dec 2014 11:46:51 -0800 (PST) Date: Thu, 11 Dec 2014 14:46:51 -0500 X-Google-Sender-Auth: pHn9gd75f98-3gyK4Perd-dUCNY Message-ID: From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-api@lists.xen.org, xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Monday is the Last Xen Project Document Day of 2014 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Monday, December 15, will be our last Document Day of the year. Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays which occur later in the month, we have scheduled Document Day for Monday. This is a great time to get our documentation ready for the new release. Have you added a new feature in this release? Make sure it is in the Wiki. Have you noticed pages which might be confusing for a new installation? Now is a great time to clean it up. Have you information on better integrating Xen Project with other projects? Share that information with others. All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days If you get a few moments before Monday, please take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Monday in #xendocs! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 12 15:33:08 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 12 Dec 2014 15:33:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzSDE-0005cR-B8; Fri, 12 Dec 2014 15:33:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzSDD-0005cM-08 for mirageos-devel@lists.xenproject.org; Fri, 12 Dec 2014 15:32:59 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 0D/55-20609-AAA0B845; Fri, 12 Dec 2014 15:32:58 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1418398376!14749805!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12953 invoked from network); 12 Dec 2014 15:32:56 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Dec 2014 15:32:56 -0000 Received: from flick.office (volstagg-0.srg.cl.cam.ac.uk [128.232.32.232]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 983d3c18; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 12 Dec 2014 15:38:33 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141211135600.GA30089@traveler> Date: Fri, 12 Dec 2014 15:32:54 +0000 Message-Id: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> <5123334.al3TCFKHKs@agaric> <20141211135600.GA30089@traveler> To: Roberto Di Cosmo X-Mailer: Apple Mail (2.1993) Cc: Louis Gesbert , opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Excellent detective work all around -- thanks for helping to pin this down, Louis and Roberto. Ideally Ubuntu will just upgrade to OPAM 1.2 rather than just fix Dose Louis -- can we do anything in OPAM 1.2 to ensure that packagers don't get this mixed up in the future via a failing configure script, as David suggests? In OpenBSD, I elected to import the -full archive rather than piecemeal packaging of the libraries required to build OPAM. -anil > On 11 Dec 2014, at 13:56, Roberto Di Cosmo wrote: > > Just for completeness, here is the info I can confirm after checking with > the Debian side: > > - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with > aspcud 1.9 and dose 3.3 > > - unfortunately, the time-boxed development process of Ubuntu, with a release > in mid-October, ended in picking up an inconsistent set of versions of our > beloved packages from the Debian timeline; this is not something that only > happen to us, it is intrinsically related to these imperfectly aligned > processes, and I suppose the Ubuntu people will be quick to act on this, > as they are probably used to this kind of events > > -- > Roberto > > On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: >> It's indeed completely broken, that's bad news indeed. >> >> But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. >> >> Here is the original report: https://github.com/ocaml/opam/issues/1683 >> >> Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( >> >> I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 >> Hope they can act on it quickly... >> >> Thanks for notifying and helping trace this! >> Louis >> >>> - Anil Madhavapeddy, 10/12/2014 14:54 - >>> I just reproduced it by following the referenced bug report. >>> >>> From a fresh Ubuntu 14.10, if I do: >>> >>> $ sudo apt-get install opam camlp4-extra aspcud >>> $ opam init -a >>> $ opam install mirage -y >>> $ eval `opam config env` >>> >>> At this point some packages have been installed and mirage is installed. >>> >>> Now however, if I use mirage it invokes opam install again and packages >>> are reinstalled as a duplicate. See below: >>> >>> opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan >>> [NOTE] Package mirage-types is already installed (current version is 2.1.0). >>> [NOTE] Package lwt is already installed (current version is 2.4.6). >>> [NOTE] Package io-page is already installed (current version is 1.1.1). >>> [NOTE] Package cstruct is already installed (current version is 1.4.0). >>> [NOTE] Package crunch is already installed (current version is 1.3.0). >>> [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile >>> The following actions will be performed: >>> - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] >>> - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install base-bigarray.base [required by cowabloga] >>> - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install xmlm.1.2.0 [required by cowabloga] >>> - install uutf.0.9.3 [required by cowabloga] >>> - install stringext.1.1.0 [required by cowabloga, mirage-http] >>> - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install re.1.2.2 [required by cowabloga, mirage-http] >>> - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install hex.0.1.0 [required by cowabloga] >>> - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] >>> - install base64.1.0.0 [required by cowabloga, mirage-http] >>> - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install ulex.1.1 [required by cowabloga] >>> - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install omd.1.2.3 [required by cowabloga] >>> - install jsonm.0.9.1 [required by cowabloga] >>> - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install crunch.1.3.0 >>> - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install fieldslib.109.20.03 [required by cowabloga, mirage-http] >>> - install dyntype.0.9.0 [required by cowabloga] >>> - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install uri.1.7.2 [required by cowabloga, mirage-http] >>> >>> I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG >>> gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe >>> >>> Any inspiration from there from the CUDF interactions in the above gist? >>> >>> -anil >>> >>>> On 10 Dec 2014, at 01:15, Louis Gesbert wrote: >>>> >>>> I've been trying to reproduce the issue, but things seem fine, sort of: >>>> >>>> From what I could gather: >>>> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine >>>> * utopic (14.10, latest) has 1.1 and aspcud 1.9 >>>> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too >>>> >>>> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). >>>> >>>> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with >>>> ``` >>>> ===== ERROR while installing ocamlfind.1.5.5 ===== >>>> Internal error: >>>> "ocamlfind": command not found. >>>> ``` >>>> >>>> so it would still be nice if they could backport (so that there is a better error) or recommend m4. >>>> >>>> Cheers, >>>> Louis >>>> >>>> >>>> [1] https://github.com/ocaml/opam/issues/1683 >>>> [2] https://github.com/ocaml/opam/issues/1658 >>>> >>>> - Anil Madhavapeddy, 09/12/2014 11:16 - >>>>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >>>>> >>>>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >>>>> >>>>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >>>>> >>>>> -anil >>>>> _______________________________________________ >>>>> opam-devel mailing list >>>>> opam-devel@lists.ocaml.org >>>>> http://lists.ocaml.org/listinfo/opam-devel >>>> _______________________________________________ >>>> opam-devel mailing list >>>> opam-devel@lists.ocaml.org >>>> http://lists.ocaml.org/listinfo/opam-devel >>>> >>> >>> _______________________________________________ >>> opam-devel mailing list >>> opam-devel@lists.ocaml.org >>> http://lists.ocaml.org/listinfo/opam-devel >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > > -- > Roberto Di Cosmo > > ------------------------------------------------------------------ > Professeur En delegation a l'INRIA > PPS E-mail: roberto@dicosmo.org > Universite Paris Diderot WWW : http://www.dicosmo.org > Case 7014 Tel : ++33-(0)1-57 27 92 20 > 5, Rue Thomas Mann > F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo > FRANCE. Twitter: http://twitter.com/rdicosmo > ------------------------------------------------------------------ > Attachments: > MIME accepted, Word deprecated > http://www.gnu.org/philosophy/no-word-attachments.html > ------------------------------------------------------------------ > Office location: > > Bureau 3020 (3rd floor) > Batiment Sophie Germain > Avenue de France > Metro Bibliotheque Francois Mitterrand, ligne 14/RER C > ----------------------------------------------------------------- > GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 12 15:33:08 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 12 Dec 2014 15:33:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzSDE-0005cR-B8; Fri, 12 Dec 2014 15:33:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzSDD-0005cM-08 for mirageos-devel@lists.xenproject.org; Fri, 12 Dec 2014 15:32:59 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 0D/55-20609-AAA0B845; Fri, 12 Dec 2014 15:32:58 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1418398376!14749805!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12953 invoked from network); 12 Dec 2014 15:32:56 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Dec 2014 15:32:56 -0000 Received: from flick.office (volstagg-0.srg.cl.cam.ac.uk [128.232.32.232]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 983d3c18; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 12 Dec 2014 15:38:33 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141211135600.GA30089@traveler> Date: Fri, 12 Dec 2014 15:32:54 +0000 Message-Id: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <5416267.uz7Mnlar5D@agaric> <4CF6C0CD-9BF9-4976-ACE9-71110CE042DA@recoil.org> <5123334.al3TCFKHKs@agaric> <20141211135600.GA30089@traveler> To: Roberto Di Cosmo X-Mailer: Apple Mail (2.1993) Cc: Louis Gesbert , opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Excellent detective work all around -- thanks for helping to pin this down, Louis and Roberto. Ideally Ubuntu will just upgrade to OPAM 1.2 rather than just fix Dose Louis -- can we do anything in OPAM 1.2 to ensure that packagers don't get this mixed up in the future via a failing configure script, as David suggests? In OpenBSD, I elected to import the -full archive rather than piecemeal packaging of the libraries required to build OPAM. -anil > On 11 Dec 2014, at 13:56, Roberto Di Cosmo wrote: > > Just for completeness, here is the info I can confirm after checking with > the Debian side: > > - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with > aspcud 1.9 and dose 3.3 > > - unfortunately, the time-boxed development process of Ubuntu, with a release > in mid-October, ended in picking up an inconsistent set of versions of our > beloved packages from the Debian timeline; this is not something that only > happen to us, it is intrinsically related to these imperfectly aligned > processes, and I suppose the Ubuntu people will be quick to act on this, > as they are probably used to this kind of events > > -- > Roberto > > On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: >> It's indeed completely broken, that's bad news indeed. >> >> But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. >> >> Here is the original report: https://github.com/ocaml/opam/issues/1683 >> >> Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( >> >> I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 >> Hope they can act on it quickly... >> >> Thanks for notifying and helping trace this! >> Louis >> >>> - Anil Madhavapeddy, 10/12/2014 14:54 - >>> I just reproduced it by following the referenced bug report. >>> >>> From a fresh Ubuntu 14.10, if I do: >>> >>> $ sudo apt-get install opam camlp4-extra aspcud >>> $ opam init -a >>> $ opam install mirage -y >>> $ eval `opam config env` >>> >>> At this point some packages have been installed and mirage is installed. >>> >>> Now however, if I use mirage it invokes opam install again and packages >>> are reinstalled as a duplicate. See below: >>> >>> opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan >>> [NOTE] Package mirage-types is already installed (current version is 2.1.0). >>> [NOTE] Package lwt is already installed (current version is 2.4.6). >>> [NOTE] Package io-page is already installed (current version is 1.1.1). >>> [NOTE] Package cstruct is already installed (current version is 1.4.0). >>> [NOTE] Package crunch is already installed (current version is 1.3.0). >>> [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile >>> The following actions will be performed: >>> - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] >>> - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install base-bigarray.base [required by cowabloga] >>> - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install xmlm.1.2.0 [required by cowabloga] >>> - install uutf.0.9.3 [required by cowabloga] >>> - install stringext.1.1.0 [required by cowabloga, mirage-http] >>> - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install re.1.2.2 [required by cowabloga, mirage-http] >>> - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install hex.0.1.0 [required by cowabloga] >>> - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] >>> - install base64.1.0.0 [required by cowabloga, mirage-http] >>> - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install ulex.1.1 [required by cowabloga] >>> - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install omd.1.2.3 [required by cowabloga] >>> - install jsonm.0.9.1 [required by cowabloga] >>> - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install crunch.1.3.0 >>> - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install fieldslib.109.20.03 [required by cowabloga, mirage-http] >>> - install dyntype.0.9.0 [required by cowabloga] >>> - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] >>> - install uri.1.7.2 [required by cowabloga, mirage-http] >>> >>> I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG >>> gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe >>> >>> Any inspiration from there from the CUDF interactions in the above gist? >>> >>> -anil >>> >>>> On 10 Dec 2014, at 01:15, Louis Gesbert wrote: >>>> >>>> I've been trying to reproduce the issue, but things seem fine, sort of: >>>> >>>> From what I could gather: >>>> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine >>>> * utopic (14.10, latest) has 1.1 and aspcud 1.9 >>>> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too >>>> >>>> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). >>>> >>>> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with >>>> ``` >>>> ===== ERROR while installing ocamlfind.1.5.5 ===== >>>> Internal error: >>>> "ocamlfind": command not found. >>>> ``` >>>> >>>> so it would still be nice if they could backport (so that there is a better error) or recommend m4. >>>> >>>> Cheers, >>>> Louis >>>> >>>> >>>> [1] https://github.com/ocaml/opam/issues/1683 >>>> [2] https://github.com/ocaml/opam/issues/1658 >>>> >>>> - Anil Madhavapeddy, 09/12/2014 11:16 - >>>>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). >>>>> >>>>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 >>>>> >>>>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? >>>>> >>>>> -anil >>>>> _______________________________________________ >>>>> opam-devel mailing list >>>>> opam-devel@lists.ocaml.org >>>>> http://lists.ocaml.org/listinfo/opam-devel >>>> _______________________________________________ >>>> opam-devel mailing list >>>> opam-devel@lists.ocaml.org >>>> http://lists.ocaml.org/listinfo/opam-devel >>>> >>> >>> _______________________________________________ >>> opam-devel mailing list >>> opam-devel@lists.ocaml.org >>> http://lists.ocaml.org/listinfo/opam-devel >> _______________________________________________ >> opam-devel mailing list >> opam-devel@lists.ocaml.org >> http://lists.ocaml.org/listinfo/opam-devel > > -- > Roberto Di Cosmo > > ------------------------------------------------------------------ > Professeur En delegation a l'INRIA > PPS E-mail: roberto@dicosmo.org > Universite Paris Diderot WWW : http://www.dicosmo.org > Case 7014 Tel : ++33-(0)1-57 27 92 20 > 5, Rue Thomas Mann > F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo > FRANCE. Twitter: http://twitter.com/rdicosmo > ------------------------------------------------------------------ > Attachments: > MIME accepted, Word deprecated > http://www.gnu.org/philosophy/no-word-attachments.html > ------------------------------------------------------------------ > Office location: > > Bureau 3020 (3rd floor) > Batiment Sophie Germain > Avenue de France > Metro Bibliotheque Francois Mitterrand, ligne 14/RER C > ----------------------------------------------------------------- > GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 12 19:16:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 12 Dec 2014 19:16:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzVhq-0006fR-MM; Fri, 12 Dec 2014 19:16:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzVhp-0006fI-GU for mirageos-devel@lists.xenproject.org; Fri, 12 Dec 2014 19:16:49 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 90/32-17958-02F3B845; Fri, 12 Dec 2014 19:16:48 +0000 X-Env-Sender: weitzkon@cs.washington.edu X-Msg-Ref: server-8.tower-31.messagelabs.com!1418411806!13021938!1 X-Originating-IP: [209.85.216.178] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26552 invoked from network); 12 Dec 2014 19:16:47 -0000 Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com) (209.85.216.178) by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 12 Dec 2014 19:16:47 -0000 Received: by mail-qc0-f178.google.com with SMTP id b13so6792577qcw.9 for ; Fri, 12 Dec 2014 11:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=/TSV75DB2ZrSM18ptv3lSubJE99ehINcQvTixs0Befw=; b=c5/Zv5Fo/tdITD50TTFIBKNS4xBN25w5aI8ZJ068QqHCo92BYjH0CIee38ihyO9ivL jTsjMXAbRe4p1epk5u3S8nfI+vNg4XjoEVmbMQ6mGLFe02KEsG7hWloHycO52AbBIzMM iFe5SEH5U+NN2CMjVVVyq6wvoP0tOlR6rIdik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=/TSV75DB2ZrSM18ptv3lSubJE99ehINcQvTixs0Befw=; b=lDA23BL8yAo5jjdtBUuqjseC87v3iXaMQHrdjsBDb0PxhVOW/Y1xBg4DFPFcI6G2kE o62UfWPKlPXl090AMRmFA34qHsnuCUoeUdoeWWDdm79NpzUCD2H314EQV/e/3YaffH77 ssFsJ/c1e+m5AyYLkTp9ZrCRgYZvgT/jfMcm806Tv/rBpirDCgQl3CV6K4y53abqGzp1 z45emE64Lac12HL3m5Hdbwe+HCjbsT+t6zE6lp/EAykQLvKxGGv47/l9vFbOTCB8qbzg IlRZhkin/DvrDNMNVNBsqhRE9Z932gapU2KGHSxjRfXcDA5gVhXL0Gig9UY20rn3PNq3 c6sQ== X-Gm-Message-State: ALoCoQkIUc/1guZflic1KuOUq+/eSFHQwe05mcY3jVk4slRCEofheEf1BOHm9KZJeqvxb4Zrmje1 X-Received: by 10.224.45.65 with SMTP id d1mr22374050qaf.56.1418411806504; Fri, 12 Dec 2014 11:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.227 with HTTP; Fri, 12 Dec 2014 11:16:05 -0800 (PST) From: Konstantin Weitz Date: Fri, 12 Dec 2014 11:16:05 -0800 X-Google-Sender-Auth: mhOIU0qLPOAHKxB91sk5yEZbkDs Message-ID: To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Sync Block Device X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4785730986417426134==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4785730986417426134== Content-Type: multipart/alternative; boundary=001a11c29a4cdf51d4050a09bbfc --001a11c29a4cdf51d4050a09bbfc Content-Type: text/plain; charset=UTF-8 I'm trying to write a database. The database is using a block device for storage. I want to make sure that after a commit, all data has actually been persistent on disk. The documentation for the `write` command says that on success, the written data is persistent: https://github.com/mirage/mirage/blob/1.1.0/types/V1.mli#L134 Is this true, or do I need to call a `sync` command that asks the block device to persist all writes (i.e. write the contents of the hard drive's hardware cache to disk?) - Konstantin --001a11c29a4cdf51d4050a09bbfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm trying to write a database. The database is u= sing a block device for storage. I want to make sure that after a commit, a= ll data has actually been persistent on disk.=C2=A0

The documentation for the `write` command says that on success, the writt= en data is persistent:


<= /div>
Is this true, or do I need to call a `sync` command that asks the= block device to persist all writes (i.e. write the contents of the hard dr= ive's hardware cache to disk?)

- Konstantin
--001a11c29a4cdf51d4050a09bbfc-- --===============4785730986417426134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4785730986417426134==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 12 19:16:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 12 Dec 2014 19:16:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzVhq-0006fR-MM; Fri, 12 Dec 2014 19:16:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzVhp-0006fI-GU for mirageos-devel@lists.xenproject.org; Fri, 12 Dec 2014 19:16:49 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 90/32-17958-02F3B845; Fri, 12 Dec 2014 19:16:48 +0000 X-Env-Sender: weitzkon@cs.washington.edu X-Msg-Ref: server-8.tower-31.messagelabs.com!1418411806!13021938!1 X-Originating-IP: [209.85.216.178] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26552 invoked from network); 12 Dec 2014 19:16:47 -0000 Received: from mail-qc0-f178.google.com (HELO mail-qc0-f178.google.com) (209.85.216.178) by server-8.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 12 Dec 2014 19:16:47 -0000 Received: by mail-qc0-f178.google.com with SMTP id b13so6792577qcw.9 for ; Fri, 12 Dec 2014 11:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=/TSV75DB2ZrSM18ptv3lSubJE99ehINcQvTixs0Befw=; b=c5/Zv5Fo/tdITD50TTFIBKNS4xBN25w5aI8ZJ068QqHCo92BYjH0CIee38ihyO9ivL jTsjMXAbRe4p1epk5u3S8nfI+vNg4XjoEVmbMQ6mGLFe02KEsG7hWloHycO52AbBIzMM iFe5SEH5U+NN2CMjVVVyq6wvoP0tOlR6rIdik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=/TSV75DB2ZrSM18ptv3lSubJE99ehINcQvTixs0Befw=; b=lDA23BL8yAo5jjdtBUuqjseC87v3iXaMQHrdjsBDb0PxhVOW/Y1xBg4DFPFcI6G2kE o62UfWPKlPXl090AMRmFA34qHsnuCUoeUdoeWWDdm79NpzUCD2H314EQV/e/3YaffH77 ssFsJ/c1e+m5AyYLkTp9ZrCRgYZvgT/jfMcm806Tv/rBpirDCgQl3CV6K4y53abqGzp1 z45emE64Lac12HL3m5Hdbwe+HCjbsT+t6zE6lp/EAykQLvKxGGv47/l9vFbOTCB8qbzg IlRZhkin/DvrDNMNVNBsqhRE9Z932gapU2KGHSxjRfXcDA5gVhXL0Gig9UY20rn3PNq3 c6sQ== X-Gm-Message-State: ALoCoQkIUc/1guZflic1KuOUq+/eSFHQwe05mcY3jVk4slRCEofheEf1BOHm9KZJeqvxb4Zrmje1 X-Received: by 10.224.45.65 with SMTP id d1mr22374050qaf.56.1418411806504; Fri, 12 Dec 2014 11:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.227 with HTTP; Fri, 12 Dec 2014 11:16:05 -0800 (PST) From: Konstantin Weitz Date: Fri, 12 Dec 2014 11:16:05 -0800 X-Google-Sender-Auth: mhOIU0qLPOAHKxB91sk5yEZbkDs Message-ID: To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Sync Block Device X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4785730986417426134==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4785730986417426134== Content-Type: multipart/alternative; boundary=001a11c29a4cdf51d4050a09bbfc --001a11c29a4cdf51d4050a09bbfc Content-Type: text/plain; charset=UTF-8 I'm trying to write a database. The database is using a block device for storage. I want to make sure that after a commit, all data has actually been persistent on disk. The documentation for the `write` command says that on success, the written data is persistent: https://github.com/mirage/mirage/blob/1.1.0/types/V1.mli#L134 Is this true, or do I need to call a `sync` command that asks the block device to persist all writes (i.e. write the contents of the hard drive's hardware cache to disk?) - Konstantin --001a11c29a4cdf51d4050a09bbfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm trying to write a database. The database is u= sing a block device for storage. I want to make sure that after a commit, a= ll data has actually been persistent on disk.=C2=A0

The documentation for the `write` command says that on success, the writt= en data is persistent:


<= /div>
Is this true, or do I need to call a `sync` command that asks the= block device to persist all writes (i.e. write the contents of the hard dr= ive's hardware cache to disk?)

- Konstantin
--001a11c29a4cdf51d4050a09bbfc-- --===============4785730986417426134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4785730986417426134==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 12 23:46:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 12 Dec 2014 23:46:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzZum-0004Yv-U0; Fri, 12 Dec 2014 23:46:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzZul-0004Yq-6j for mirageos-devel@lists.xenproject.org; Fri, 12 Dec 2014 23:46:27 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id FE/48-17958-25E7B845; Fri, 12 Dec 2014 23:46:26 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1418427985!13043363!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18463 invoked from network); 12 Dec 2014 23:46:25 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 12 Dec 2014 23:46:25 -0000 X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="27851958" From: Dave Scott To: Konstantin Weitz Thread-Topic: [MirageOS-devel] Sync Block Device Thread-Index: AQHQFkAzu+IrZDakw0aq8/qt8On0apyMjmWA Date: Fri, 12 Dec 2014 23:46:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <445A4FB135D0B84A9455905F3D328693@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Sync Block Device X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org DQo+IE9uIDEyIERlYyAyMDE0LCBhdCAxOToxNiwgS29uc3RhbnRpbiBXZWl0eiA8d2VpdHprb25A dXcuZWR1PiB3cm90ZToNCj4gDQo+IEknbSB0cnlpbmcgdG8gd3JpdGUgYSBkYXRhYmFzZS4gVGhl IGRhdGFiYXNlIGlzIHVzaW5nIGEgYmxvY2sgZGV2aWNlIGZvciBzdG9yYWdlLiBJIHdhbnQgdG8g bWFrZSBzdXJlIHRoYXQgYWZ0ZXIgYSBjb21taXQsIGFsbCBkYXRhIGhhcyBhY3R1YWxseSBiZWVu IHBlcnNpc3RlbnQgb24gZGlzay4gDQo+IA0KPiBUaGUgZG9jdW1lbnRhdGlvbiBmb3IgdGhlIGB3 cml0ZWAgY29tbWFuZCBzYXlzIHRoYXQgb24gc3VjY2VzcywgdGhlIHdyaXR0ZW4gZGF0YSBpcyBw ZXJzaXN0ZW50Og0KPiANCj4gaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvYmxvYi8x LjEuMC90eXBlcy9WMS5tbGkjTDEzNA0KPiANCj4gSXMgdGhpcyB0cnVlLCBvciBkbyBJIG5lZWQg dG8gY2FsbCBhIGBzeW5jYCBjb21tYW5kIHRoYXQgYXNrcyB0aGUgYmxvY2sgZGV2aWNlIHRvIHBl cnNpc3QgYWxsIHdyaXRlcyAoaS5lLiB3cml0ZSB0aGUgY29udGVudHMgb2YgdGhlIGhhcmQgZHJp dmUncyBoYXJkd2FyZSBjYWNoZSB0byBkaXNrPykNCg0KSXTigJlzIHN1cHBvc2VkIHRvIGJlIHRy dWUgOi0pIEZvciByZWZlcmVuY2UgdHdvIHNpZ25pZmljYW50IGltcGxlbWVudGF0aW9ucyBhcmU6 DQoNCjEuIFhlbiBibGtmcm9udDogd2hlcmUgdGhlIHdyaXRlIGlzIGNvbnNpZGVyZWQgcGVyc2lz dGVudCB3aGVuIHRoZSByZXF1ZXN0IG9uIHRoZSByaW5nIGhhcyBiZWVuIHJlcGxpZWQgdG8uIFRo ZSB1c3VhbCBjb250cmFjdCBpcyB0aGF0IHRoZSBYZW4gYmFja2VuZCB3b27igJl0IHJlcGx5IHVu dGlsIHRoZSBkYXRhIGhhcyBoaXQgdGhlIGRpc2suIEFzIGFuIGFzaWRlIHRoaXMgY2FuIGNhdXNl IHBlcmZvcm1hbmNlIHByb2JsZW1zIHdoZW4gdGhlIHN0b3JhZ2UgZGV2aWNlIGhhcyBoaWdoIGxh dGVuY3kgKGUuZy4gTkZTKSBzaW5jZSB0aGUgZml4ZWQtc2l6ZSByaW5nIGZpbGxzIHVwIHdpdGgg cGVuZGluZyByZXF1ZXN0cy4NCg0KMi4gVW5peCB3aXRoIE9fRElSRUNUICh1bmJ1ZmZlcmVkIHNl Y3Rvci1hbGlnbmVkIEkvTykNCg0KQ2hlZXJzLA0KRGF2ZQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QK TWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2pl Y3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Fri Dec 12 23:46:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 12 Dec 2014 23:46:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzZum-0004Yv-U0; Fri, 12 Dec 2014 23:46:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzZul-0004Yq-6j for mirageos-devel@lists.xenproject.org; Fri, 12 Dec 2014 23:46:27 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id FE/48-17958-25E7B845; Fri, 12 Dec 2014 23:46:26 +0000 X-Env-Sender: Dave.Scott@citrix.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1418427985!13043363!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18463 invoked from network); 12 Dec 2014 23:46:25 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 12 Dec 2014 23:46:25 -0000 X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="27851958" From: Dave Scott To: Konstantin Weitz Thread-Topic: [MirageOS-devel] Sync Block Device Thread-Index: AQHQFkAzu+IrZDakw0aq8/qt8On0apyMjmWA Date: Fri, 12 Dec 2014 23:46:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <445A4FB135D0B84A9455905F3D328693@citrix.com> MIME-Version: 1.0 X-DLP: AMS1 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Sync Block Device X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org DQo+IE9uIDEyIERlYyAyMDE0LCBhdCAxOToxNiwgS29uc3RhbnRpbiBXZWl0eiA8d2VpdHprb25A dXcuZWR1PiB3cm90ZToNCj4gDQo+IEknbSB0cnlpbmcgdG8gd3JpdGUgYSBkYXRhYmFzZS4gVGhl IGRhdGFiYXNlIGlzIHVzaW5nIGEgYmxvY2sgZGV2aWNlIGZvciBzdG9yYWdlLiBJIHdhbnQgdG8g bWFrZSBzdXJlIHRoYXQgYWZ0ZXIgYSBjb21taXQsIGFsbCBkYXRhIGhhcyBhY3R1YWxseSBiZWVu IHBlcnNpc3RlbnQgb24gZGlzay4gDQo+IA0KPiBUaGUgZG9jdW1lbnRhdGlvbiBmb3IgdGhlIGB3 cml0ZWAgY29tbWFuZCBzYXlzIHRoYXQgb24gc3VjY2VzcywgdGhlIHdyaXR0ZW4gZGF0YSBpcyBw ZXJzaXN0ZW50Og0KPiANCj4gaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvYmxvYi8x LjEuMC90eXBlcy9WMS5tbGkjTDEzNA0KPiANCj4gSXMgdGhpcyB0cnVlLCBvciBkbyBJIG5lZWQg dG8gY2FsbCBhIGBzeW5jYCBjb21tYW5kIHRoYXQgYXNrcyB0aGUgYmxvY2sgZGV2aWNlIHRvIHBl cnNpc3QgYWxsIHdyaXRlcyAoaS5lLiB3cml0ZSB0aGUgY29udGVudHMgb2YgdGhlIGhhcmQgZHJp dmUncyBoYXJkd2FyZSBjYWNoZSB0byBkaXNrPykNCg0KSXTigJlzIHN1cHBvc2VkIHRvIGJlIHRy dWUgOi0pIEZvciByZWZlcmVuY2UgdHdvIHNpZ25pZmljYW50IGltcGxlbWVudGF0aW9ucyBhcmU6 DQoNCjEuIFhlbiBibGtmcm9udDogd2hlcmUgdGhlIHdyaXRlIGlzIGNvbnNpZGVyZWQgcGVyc2lz dGVudCB3aGVuIHRoZSByZXF1ZXN0IG9uIHRoZSByaW5nIGhhcyBiZWVuIHJlcGxpZWQgdG8uIFRo ZSB1c3VhbCBjb250cmFjdCBpcyB0aGF0IHRoZSBYZW4gYmFja2VuZCB3b27igJl0IHJlcGx5IHVu dGlsIHRoZSBkYXRhIGhhcyBoaXQgdGhlIGRpc2suIEFzIGFuIGFzaWRlIHRoaXMgY2FuIGNhdXNl IHBlcmZvcm1hbmNlIHByb2JsZW1zIHdoZW4gdGhlIHN0b3JhZ2UgZGV2aWNlIGhhcyBoaWdoIGxh dGVuY3kgKGUuZy4gTkZTKSBzaW5jZSB0aGUgZml4ZWQtc2l6ZSByaW5nIGZpbGxzIHVwIHdpdGgg cGVuZGluZyByZXF1ZXN0cy4NCg0KMi4gVW5peCB3aXRoIE9fRElSRUNUICh1bmJ1ZmZlcmVkIHNl Y3Rvci1hbGlnbmVkIEkvTykNCg0KQ2hlZXJzLA0KRGF2ZQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QK TWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2pl Y3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 01:16:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 01:16:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbK5-0002VX-69; Sat, 13 Dec 2014 01:16:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbK3-0002VS-Ci for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 01:16:39 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id C6/C7-05632-6739B845; Sat, 13 Dec 2014 01:16:38 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1418433397!13020991!1 X-Originating-IP: [209.85.212.174] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2136 invoked from network); 13 Dec 2014 01:16:38 -0000 Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Dec 2014 01:16:38 -0000 Received: by mail-wi0-f174.google.com with SMTP id h11so4105595wiw.7 for ; Fri, 12 Dec 2014 17:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=nDrlThEd0PpRu9OO1hdKVp3bIxl6ekwYxV0QlhSvQ74=; b=reoAGcbiASwzGY5kY/M95hIem+ktfN2EJ7CdU+6SiB1cXz3bhF22YQX5ZZJNvQkPyw yo7FfMq6boDMG88xug/7twUIZOdYiEx43NSSO6cqGP1KRVhuADrIFCMB5lBN+9WNSXCL Op3qW02BtIeKg4Sg+rFKV7tQKdEK1Sz1LG5DQvpD7OHyvtvxT9rWbZhraWQnC5sxAXUq hl2ukBvq0QXsUUr2lBDL8q1ctQRDUvma+kyIq/FAWAprMrCghTxqX2GdM/wZu1YX6Mn/ uDHTUijVfIa5yqWZ/uG4HvJKfMeoHShhqLlR7ETawo08TmUgItGwVArIkLKT3gANXxen /Lqg== MIME-Version: 1.0 X-Received: by 10.194.187.235 with SMTP id fv11mr32168167wjc.16.1418433397513; Fri, 12 Dec 2014 17:16:37 -0800 (PST) Received: by 10.27.45.205 with HTTP; Fri, 12 Dec 2014 17:16:37 -0800 (PST) Date: Fri, 12 Dec 2014 22:16:37 -0300 X-Google-Sender-Auth: EBcm0BKwUWppma3vSBazfABYQ8w Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] vmnet and ip routes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi list, I am trying to make the `ping` example in `mirage-skeleton` work with `vmnet` on OS X. The unikernel is binding to the address 10.0.0.2, and 10.0.0.1 is the default gateway. Previously (when using tun/tap), in order to ping the unikernel all we had to do was to bind 10.0.0.1 to the `tap` interface. When using `vmnet`, I tried binding 10.0.0.1 to the bridge or the associated virtual ethernet interface but it does not seem to work. Or rather, it only half-works: the unikernel receives the ARP queries but its response does not appear to reach anyone. What am I missing ? Thanks! Best wishes, Nicolas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 01:16:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 01:16:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbK5-0002VX-69; Sat, 13 Dec 2014 01:16:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbK3-0002VS-Ci for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 01:16:39 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id C6/C7-05632-6739B845; Sat, 13 Dec 2014 01:16:38 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1418433397!13020991!1 X-Originating-IP: [209.85.212.174] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2136 invoked from network); 13 Dec 2014 01:16:38 -0000 Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Dec 2014 01:16:38 -0000 Received: by mail-wi0-f174.google.com with SMTP id h11so4105595wiw.7 for ; Fri, 12 Dec 2014 17:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=nDrlThEd0PpRu9OO1hdKVp3bIxl6ekwYxV0QlhSvQ74=; b=reoAGcbiASwzGY5kY/M95hIem+ktfN2EJ7CdU+6SiB1cXz3bhF22YQX5ZZJNvQkPyw yo7FfMq6boDMG88xug/7twUIZOdYiEx43NSSO6cqGP1KRVhuADrIFCMB5lBN+9WNSXCL Op3qW02BtIeKg4Sg+rFKV7tQKdEK1Sz1LG5DQvpD7OHyvtvxT9rWbZhraWQnC5sxAXUq hl2ukBvq0QXsUUr2lBDL8q1ctQRDUvma+kyIq/FAWAprMrCghTxqX2GdM/wZu1YX6Mn/ uDHTUijVfIa5yqWZ/uG4HvJKfMeoHShhqLlR7ETawo08TmUgItGwVArIkLKT3gANXxen /Lqg== MIME-Version: 1.0 X-Received: by 10.194.187.235 with SMTP id fv11mr32168167wjc.16.1418433397513; Fri, 12 Dec 2014 17:16:37 -0800 (PST) Received: by 10.27.45.205 with HTTP; Fri, 12 Dec 2014 17:16:37 -0800 (PST) Date: Fri, 12 Dec 2014 22:16:37 -0300 X-Google-Sender-Auth: EBcm0BKwUWppma3vSBazfABYQ8w Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] vmnet and ip routes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi list, I am trying to make the `ping` example in `mirage-skeleton` work with `vmnet` on OS X. The unikernel is binding to the address 10.0.0.2, and 10.0.0.1 is the default gateway. Previously (when using tun/tap), in order to ping the unikernel all we had to do was to bind 10.0.0.1 to the `tap` interface. When using `vmnet`, I tried binding 10.0.0.1 to the bridge or the associated virtual ethernet interface but it does not seem to work. Or rather, it only half-works: the unikernel receives the ARP queries but its response does not appear to reach anyone. What am I missing ? Thanks! Best wishes, Nicolas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 01:24:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 01:24:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbS6-0002jF-Tm; Sat, 13 Dec 2014 01:24:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbS4-0002jA-OU for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 01:24:57 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 76/AA-28296-7659B845; Sat, 13 Dec 2014 01:24:55 +0000 X-Env-Sender: louis.gesbert@ocamlpro.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1418433893!13009631!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13532 invoked from network); 13 Dec 2014 01:24:54 -0000 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.10) by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 01:24:54 -0000 Received: from agaric.localnet ([111.64.65.75]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MVrSa-1YSINX2aOe-00X5ei; Sat, 13 Dec 2014 02:24:52 +0100 From: Louis Gesbert To: Anil Madhavapeddy Date: Sat, 13 Dec 2014 10:24:45 +0900 Message-ID: <3900186.VCNjxAKEzz@agaric> Organization: OCamlPro User-Agent: KMail/4.14.1 (Linux/3.16-2-amd64; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <20141211135600.GA30089@traveler> MIME-Version: 1.0 X-Provags-ID: V03:K0:AzOBXFeJyT6t2VmW4t2dpy6KxDAqgWYkURVFNf/meeSdgG+FqOm 3wH4VvThcBggg463LUCKqme5MO266/NKjwbbmtQdSL54+0f5In18OG+NNnqbfSLQ2Ail/N6 sbyeQPIfSyLstdz6vBWbJVrZXt0Dq5Kun6S7XUmUENc6+gqH/efaAtqRPF7tkjH5MfHKcMb 1tb1ooSv+qQElu+4sZevQ== X-UI-Out-Filterresults: notjunk:1; Cc: Roberto Di Cosmo , opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1177796862373681303==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============1177796862373681303== Content-Type: multipart/alternative; boundary="nextPart1689993.ETHeaMfqNo" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1689993.ETHeaMfqNo Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" For this specific bug,running "make tests" would have been enough (I just tested on my VM). For being defensive and having ./configure refuse newer version of dependencies, the m4 macros don't seem to provide version filtering (only API testing. Here the API was compatible, anyway that would have failed at build-time). Does ocamlfind even provide an easy way to get the version of a package? But my feeling is that what happened really shouldn't happen -- I mean, a small, but API compatible change, that would cause the older version to break _but not the newer version, just by chance_, so that it could get unnoticed ? What are the odds of this happening _again_ ? ;) On using the -full archive, that can be a good thing, but it probably won't go well with the Debian/Ubuntu policies. Really, packaging scripts should run "make tests"; not sure if it's worth preventing upgrades in ./configure -- although that at least gives the opportunity to fix ./configure (and hopefully check that nothing is broken) by hand. Cheers, Louis > - Anil Madhavapeddy, 12/12/2014 15:32 - > Excellent detective work all around -- thanks for helping to pin this down, > Louis and Roberto. Ideally Ubuntu will just upgrade to OPAM 1.2 rather than > just fix Dose > > Louis -- can we do anything in OPAM 1.2 to ensure that packagers don't get > this mixed up in the future via a failing configure script, as David suggests? > In OpenBSD, I elected to import the -full archive rather than piecemeal > packaging of the libraries required to build OPAM. > > -anil > > > > On 11 Dec 2014, at 13:56, Roberto Di Cosmo wrote: > > > > Just for completeness, here is the info I can confirm after checking with > > the Debian side: > > > > - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with > > aspcud 1.9 and dose 3.3 > > > > - unfortunately, the time-boxed development process of Ubuntu, with a release > > in mid-October, ended in picking up an inconsistent set of versions of our > > beloved packages from the Debian timeline; this is not something that only > > happen to us, it is intrinsically related to these imperfectly aligned > > processes, and I suppose the Ubuntu people will be quick to act on this, > > as they are probably used to this kind of events > > > > -- > > Roberto > > > > On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: > >> It's indeed completely broken, that's bad news indeed. > >> > >> But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. > >> > >> Here is the original report: https://github.com/ocaml/opam/issues/1683 > >> > >> Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( > >> > >> I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 > >> Hope they can act on it quickly... > >> > >> Thanks for notifying and helping trace this! > >> Louis > >> > >>> - Anil Madhavapeddy, 10/12/2014 14:54 - > >>> I just reproduced it by following the referenced bug report. > >>> > >>> From a fresh Ubuntu 14.10, if I do: > >>> > >>> $ sudo apt-get install opam camlp4-extra aspcud > >>> $ opam init -a > >>> $ opam install mirage -y > >>> $ eval `opam config env` > >>> > >>> At this point some packages have been installed and mirage is installed. > >>> > >>> Now however, if I use mirage it invokes opam install again and packages > >>> are reinstalled as a duplicate. See below: > >>> > >>> opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > >>> [NOTE] Package mirage-types is already installed (current version is 2.1.0). > >>> [NOTE] Package lwt is already installed (current version is 2.4.6). > >>> [NOTE] Package io-page is already installed (current version is 1.1.1). > >>> [NOTE] Package cstruct is already installed (current version is 1.4.0). > >>> [NOTE] Package crunch is already installed (current version is 1.3.0). > >>> [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > >>> The following actions will be performed: > >>> - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > >>> - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install base-bigarray.base [required by cowabloga] > >>> - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install xmlm.1.2.0 [required by cowabloga] > >>> - install uutf.0.9.3 [required by cowabloga] > >>> - install stringext.1.1.0 [required by cowabloga, mirage-http] > >>> - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install re.1.2.2 [required by cowabloga, mirage-http] > >>> - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install hex.0.1.0 [required by cowabloga] > >>> - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > >>> - install base64.1.0.0 [required by cowabloga, mirage-http] > >>> - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install ulex.1.1 [required by cowabloga] > >>> - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install omd.1.2.3 [required by cowabloga] > >>> - install jsonm.0.9.1 [required by cowabloga] > >>> - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install crunch.1.3.0 > >>> - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > >>> - install dyntype.0.9.0 [required by cowabloga] > >>> - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install uri.1.7.2 [required by cowabloga, mirage-http] > >>> > >>> I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > >>> gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > >>> > >>> Any inspiration from there from the CUDF interactions in the above gist? > >>> > >>> -anil > >>> > >>>> On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > >>>> > >>>> I've been trying to reproduce the issue, but things seem fine, sort of: > >>>> > >>>> From what I could gather: > >>>> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > >>>> * utopic (14.10, latest) has 1.1 and aspcud 1.9 > >>>> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > >>>> > >>>> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > >>>> > >>>> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > >>>> ``` > >>>> ===== ERROR while installing ocamlfind.1.5.5 ===== > >>>> Internal error: > >>>> "ocamlfind": command not found. > >>>> ``` > >>>> > >>>> so it would still be nice if they could backport (so that there is a better error) or recommend m4. > >>>> > >>>> Cheers, > >>>> Louis > >>>> > >>>> > >>>> [1] https://github.com/ocaml/opam/issues/1683 > >>>> [2] https://github.com/ocaml/opam/issues/1658 > >>>> > >>>> - Anil Madhavapeddy, 09/12/2014 11:16 - > >>>>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > >>>>> > >>>>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > >>>>> > >>>>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > >>>>> > >>>>> -anil > >>>>> _______________________________________________ > >>>>> opam-devel mailing list > >>>>> opam-devel@lists.ocaml.org > >>>>> http://lists.ocaml.org/listinfo/opam-devel > >>>> _______________________________________________ > >>>> opam-devel mailing list > >>>> opam-devel@lists.ocaml.org > >>>> http://lists.ocaml.org/listinfo/opam-devel > >>>> > >>> > >>> _______________________________________________ > >>> opam-devel mailing list > >>> opam-devel@lists.ocaml.org > >>> http://lists.ocaml.org/listinfo/opam-devel > >> _______________________________________________ > >> opam-devel mailing list > >> opam-devel@lists.ocaml.org > >> http://lists.ocaml.org/listinfo/opam-devel > > > --nextPart1689993.ETHeaMfqNo Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

For this specific bug,running "make tests" would have been enough (I just tested on my VM). For being defensive and having ./configure refuse newer version of dependencies, the m4 macros don't seem to provide version filtering (only API testing. Here the API was compatible, anyway that would have failed at build-time). Does ocamlfind even provide an easy way to get the version of a package?

 

But my feeling is that what happened really shouldn't happen -- I mean, a small, but API compatible change, that would cause the older version to break _but not the newer version, just by chance_, so that it could get unnoticed ? What are the odds of this happening _again_ ? ;)

 

On using the -full archive, that can be a good thing, but it probably won't go well with the Debian/Ubuntu policies. Really, packaging scripts should run "make tests"; not sure if it's worth preventing upgrades in ./configure -- although that at least gives the opportunity to fix ./configure (and hopefully check that nothing is broken) by hand.

 

Cheers,

Louis

 

> - Anil Madhavapeddy, 12/12/2014 15:32 -

> Excellent detective work all around -- thanks for helping to pin this down,

> Louis and Roberto. Ideally Ubuntu will just upgrade to OPAM 1.2 rather than

> just fix Dose

>

> Louis -- can we do anything in OPAM 1.2 to ensure that packagers don't get

> this mixed up in the future via a failing configure script, as David suggests?

> In OpenBSD, I elected to import the -full archive rather than piecemeal

> packaging of the libraries required to build OPAM.

>

> -anil

>

>

> > On 11 Dec 2014, at 13:56, Roberto Di Cosmo <roberto@dicosmo.org> wrote:

> >

> > Just for completeness, here is the info I can confirm after checking with

> > the Debian side:

> >

> > - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with

> > aspcud 1.9 and dose 3.3

> >

> > - unfortunately, the time-boxed development process of Ubuntu, with a release

> > in mid-October, ended in picking up an inconsistent set of versions of our

> > beloved packages from the Debian timeline; this is not something that only

> > happen to us, it is intrinsically related to these imperfectly aligned

> > processes, and I suppose the Ubuntu people will be quick to act on this,

> > as they are probably used to this kind of events

> >

> > --

> > Roberto

> >

> > On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote:

> >> It's indeed completely broken, that's bad news indeed.

> >>

> >> But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed.

> >>

> >> Here is the original report: https://github.com/ocaml/opam/issues/1683

> >>

> >> Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :(

> >>

> >> I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346

> >> Hope they can act on it quickly...

> >>

> >> Thanks for notifying and helping trace this!

> >> Louis

> >>

> >>> - Anil Madhavapeddy, 10/12/2014 14:54 -

> >>> I just reproduced it by following the referenced bug report.

> >>>

> >>> From a fresh Ubuntu 14.10, if I do:

> >>>

> >>> $ sudo apt-get install opam camlp4-extra aspcud

> >>> $ opam init -a

> >>> $ opam install mirage -y

> >>> $ eval `opam config env`

> >>>

> >>> At this point some packages have been installed and mirage is installed.

> >>>

> >>> Now however, if I use mirage it invokes opam install again and packages

> >>> are reinstalled as a duplicate. See below:

> >>>

> >>> opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan

> >>> [NOTE] Package mirage-types is already installed (current version is 2.1.0).

> >>> [NOTE] Package lwt is already installed (current version is 2.4.6).

> >>> [NOTE] Package io-page is already installed (current version is 1.1.1).

> >>> [NOTE] Package cstruct is already installed (current version is 1.4.0).

> >>> [NOTE] Package crunch is already installed (current version is 1.3.0).

> >>> [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile

> >>> The following actions will be performed:

> >>> - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http]

> >>> - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install base-bigarray.base [required by cowabloga]

> >>> - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install xmlm.1.2.0 [required by cowabloga]

> >>> - install uutf.0.9.3 [required by cowabloga]

> >>> - install stringext.1.1.0 [required by cowabloga, mirage-http]

> >>> - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install re.1.2.2 [required by cowabloga, mirage-http]

> >>> - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install hex.0.1.0 [required by cowabloga]

> >>> - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http]

> >>> - install base64.1.0.0 [required by cowabloga, mirage-http]

> >>> - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install ulex.1.1 [required by cowabloga]

> >>> - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install omd.1.2.3 [required by cowabloga]

> >>> - install jsonm.0.9.1 [required by cowabloga]

> >>> - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install crunch.1.3.0

> >>> - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install fieldslib.109.20.03 [required by cowabloga, mirage-http]

> >>> - install dyntype.0.9.0 [required by cowabloga]

> >>> - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install uri.1.7.2 [required by cowabloga, mirage-http]

> >>>

> >>> I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG

> >>> gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe

> >>>

> >>> Any inspiration from there from the CUDF interactions in the above gist?

> >>>

> >>> -anil

> >>>

> >>>> On 10 Dec 2014, at 01:15, Louis Gesbert <louis.gesbert@ocamlpro.com> wrote:

> >>>>

> >>>> I've been trying to reproduce the issue, but things seem fine, sort of:

> >>>>

> >>>> From what I could gather:

> >>>> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine

> >>>> * utopic (14.10, latest) has 1.1 and aspcud 1.9

> >>>> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too

> >>>>

> >>>> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface).

> >>>>

> >>>> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with

> >>>> ```

> >>>> ===== ERROR while installing ocamlfind.1.5.5 =====

> >>>> Internal error:

> >>>> "ocamlfind": command not found.

> >>>> ```

> >>>>

> >>>> so it would still be nice if they could backport (so that there is a better error) or recommend m4.

> >>>>

> >>>> Cheers,

> >>>> Louis

> >>>>

> >>>>

> >>>> [1] https://github.com/ocaml/opam/issues/1683

> >>>> [2] https://github.com/ocaml/opam/issues/1658

> >>>>

> >>>> - Anil Madhavapeddy, 09/12/2014 11:16 -

> >>>>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface).

> >>>>>

> >>>>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59

> >>>>>

> >>>>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10?

> >>>>>

> >>>>> -anil

> >>>>> _______________________________________________

> >>>>> opam-devel mailing list

> >>>>> opam-devel@lists.ocaml.org

> >>>>> http://lists.ocaml.org/listinfo/opam-devel

> >>>> _______________________________________________

> >>>> opam-devel mailing list

> >>>> opam-devel@lists.ocaml.org

> >>>> http://lists.ocaml.org/listinfo/opam-devel

> >>>>

> >>>

> >>> _______________________________________________

> >>> opam-devel mailing list

> >>> opam-devel@lists.ocaml.org

> >>> http://lists.ocaml.org/listinfo/opam-devel

> >> _______________________________________________

> >> opam-devel mailing list

> >> opam-devel@lists.ocaml.org

> >> http://lists.ocaml.org/listinfo/opam-devel

> >

>

--nextPart1689993.ETHeaMfqNo-- --===============1177796862373681303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1177796862373681303==-- From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 01:24:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 01:24:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbS6-0002jF-Tm; Sat, 13 Dec 2014 01:24:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzbS4-0002jA-OU for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 01:24:57 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 76/AA-28296-7659B845; Sat, 13 Dec 2014 01:24:55 +0000 X-Env-Sender: louis.gesbert@ocamlpro.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1418433893!13009631!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13532 invoked from network); 13 Dec 2014 01:24:54 -0000 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.10) by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 01:24:54 -0000 Received: from agaric.localnet ([111.64.65.75]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MVrSa-1YSINX2aOe-00X5ei; Sat, 13 Dec 2014 02:24:52 +0100 From: Louis Gesbert To: Anil Madhavapeddy Date: Sat, 13 Dec 2014 10:24:45 +0900 Message-ID: <3900186.VCNjxAKEzz@agaric> Organization: OCamlPro User-Agent: KMail/4.14.1 (Linux/3.16-2-amd64; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <20141211135600.GA30089@traveler> MIME-Version: 1.0 X-Provags-ID: V03:K0:AzOBXFeJyT6t2VmW4t2dpy6KxDAqgWYkURVFNf/meeSdgG+FqOm 3wH4VvThcBggg463LUCKqme5MO266/NKjwbbmtQdSL54+0f5In18OG+NNnqbfSLQ2Ail/N6 sbyeQPIfSyLstdz6vBWbJVrZXt0Dq5Kun6S7XUmUENc6+gqH/efaAtqRPF7tkjH5MfHKcMb 1tb1ooSv+qQElu+4sZevQ== X-UI-Out-Filterresults: notjunk:1; Cc: Roberto Di Cosmo , opam-devel@lists.ocaml.org, mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1177796862373681303==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============1177796862373681303== Content-Type: multipart/alternative; boundary="nextPart1689993.ETHeaMfqNo" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1689993.ETHeaMfqNo Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" For this specific bug,running "make tests" would have been enough (I just tested on my VM). For being defensive and having ./configure refuse newer version of dependencies, the m4 macros don't seem to provide version filtering (only API testing. Here the API was compatible, anyway that would have failed at build-time). Does ocamlfind even provide an easy way to get the version of a package? But my feeling is that what happened really shouldn't happen -- I mean, a small, but API compatible change, that would cause the older version to break _but not the newer version, just by chance_, so that it could get unnoticed ? What are the odds of this happening _again_ ? ;) On using the -full archive, that can be a good thing, but it probably won't go well with the Debian/Ubuntu policies. Really, packaging scripts should run "make tests"; not sure if it's worth preventing upgrades in ./configure -- although that at least gives the opportunity to fix ./configure (and hopefully check that nothing is broken) by hand. Cheers, Louis > - Anil Madhavapeddy, 12/12/2014 15:32 - > Excellent detective work all around -- thanks for helping to pin this down, > Louis and Roberto. Ideally Ubuntu will just upgrade to OPAM 1.2 rather than > just fix Dose > > Louis -- can we do anything in OPAM 1.2 to ensure that packagers don't get > this mixed up in the future via a failing configure script, as David suggests? > In OpenBSD, I elected to import the -full archive rather than piecemeal > packaging of the libraries required to build OPAM. > > -anil > > > > On 11 Dec 2014, at 13:56, Roberto Di Cosmo wrote: > > > > Just for completeness, here is the info I can confirm after checking with > > the Debian side: > > > > - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with > > aspcud 1.9 and dose 3.3 > > > > - unfortunately, the time-boxed development process of Ubuntu, with a release > > in mid-October, ended in picking up an inconsistent set of versions of our > > beloved packages from the Debian timeline; this is not something that only > > happen to us, it is intrinsically related to these imperfectly aligned > > processes, and I suppose the Ubuntu people will be quick to act on this, > > as they are probably used to this kind of events > > > > -- > > Roberto > > > > On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote: > >> It's indeed completely broken, that's bad news indeed. > >> > >> But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed. > >> > >> Here is the original report: https://github.com/ocaml/opam/issues/1683 > >> > >> Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :( > >> > >> I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346 > >> Hope they can act on it quickly... > >> > >> Thanks for notifying and helping trace this! > >> Louis > >> > >>> - Anil Madhavapeddy, 10/12/2014 14:54 - > >>> I just reproduced it by following the referenced bug report. > >>> > >>> From a fresh Ubuntu 14.10, if I do: > >>> > >>> $ sudo apt-get install opam camlp4-extra aspcud > >>> $ opam init -a > >>> $ opam install mirage -y > >>> $ eval `opam config env` > >>> > >>> At this point some packages have been installed and mirage is installed. > >>> > >>> Now however, if I use mirage it invokes opam install again and packages > >>> are reinstalled as a duplicate. See below: > >>> > >>> opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan > >>> [NOTE] Package mirage-types is already installed (current version is 2.1.0). > >>> [NOTE] Package lwt is already installed (current version is 2.4.6). > >>> [NOTE] Package io-page is already installed (current version is 1.1.1). > >>> [NOTE] Package cstruct is already installed (current version is 1.4.0). > >>> [NOTE] Package crunch is already installed (current version is 1.3.0). > >>> [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile > >>> The following actions will be performed: > >>> - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http] > >>> - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install base-bigarray.base [required by cowabloga] > >>> - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install xmlm.1.2.0 [required by cowabloga] > >>> - install uutf.0.9.3 [required by cowabloga] > >>> - install stringext.1.1.0 [required by cowabloga, mirage-http] > >>> - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install re.1.2.2 [required by cowabloga, mirage-http] > >>> - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install hex.0.1.0 [required by cowabloga] > >>> - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http] > >>> - install base64.1.0.0 [required by cowabloga, mirage-http] > >>> - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install ulex.1.1 [required by cowabloga] > >>> - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install omd.1.2.3 [required by cowabloga] > >>> - install jsonm.0.9.1 [required by cowabloga] > >>> - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install crunch.1.3.0 > >>> - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install fieldslib.109.20.03 [required by cowabloga, mirage-http] > >>> - install dyntype.0.9.0 [required by cowabloga] > >>> - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http] > >>> - install uri.1.7.2 [required by cowabloga, mirage-http] > >>> > >>> I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG > >>> gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe > >>> > >>> Any inspiration from there from the CUDF interactions in the above gist? > >>> > >>> -anil > >>> > >>>> On 10 Dec 2014, at 01:15, Louis Gesbert wrote: > >>>> > >>>> I've been trying to reproduce the issue, but things seem fine, sort of: > >>>> > >>>> From what I could gather: > >>>> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine > >>>> * utopic (14.10, latest) has 1.1 and aspcud 1.9 > >>>> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too > >>>> > >>>> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface). > >>>> > >>>> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with > >>>> ``` > >>>> ===== ERROR while installing ocamlfind.1.5.5 ===== > >>>> Internal error: > >>>> "ocamlfind": command not found. > >>>> ``` > >>>> > >>>> so it would still be nice if they could backport (so that there is a better error) or recommend m4. > >>>> > >>>> Cheers, > >>>> Louis > >>>> > >>>> > >>>> [1] https://github.com/ocaml/opam/issues/1683 > >>>> [2] https://github.com/ocaml/opam/issues/1658 > >>>> > >>>> - Anil Madhavapeddy, 09/12/2014 11:16 - > >>>>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface). > >>>>> > >>>>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59 > >>>>> > >>>>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10? > >>>>> > >>>>> -anil > >>>>> _______________________________________________ > >>>>> opam-devel mailing list > >>>>> opam-devel@lists.ocaml.org > >>>>> http://lists.ocaml.org/listinfo/opam-devel > >>>> _______________________________________________ > >>>> opam-devel mailing list > >>>> opam-devel@lists.ocaml.org > >>>> http://lists.ocaml.org/listinfo/opam-devel > >>>> > >>> > >>> _______________________________________________ > >>> opam-devel mailing list > >>> opam-devel@lists.ocaml.org > >>> http://lists.ocaml.org/listinfo/opam-devel > >> _______________________________________________ > >> opam-devel mailing list > >> opam-devel@lists.ocaml.org > >> http://lists.ocaml.org/listinfo/opam-devel > > > --nextPart1689993.ETHeaMfqNo Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

For this specific bug,running "make tests" would have been enough (I just tested on my VM). For being defensive and having ./configure refuse newer version of dependencies, the m4 macros don't seem to provide version filtering (only API testing. Here the API was compatible, anyway that would have failed at build-time). Does ocamlfind even provide an easy way to get the version of a package?

 

But my feeling is that what happened really shouldn't happen -- I mean, a small, but API compatible change, that would cause the older version to break _but not the newer version, just by chance_, so that it could get unnoticed ? What are the odds of this happening _again_ ? ;)

 

On using the -full archive, that can be a good thing, but it probably won't go well with the Debian/Ubuntu policies. Really, packaging scripts should run "make tests"; not sure if it's worth preventing upgrades in ./configure -- although that at least gives the opportunity to fix ./configure (and hopefully check that nothing is broken) by hand.

 

Cheers,

Louis

 

> - Anil Madhavapeddy, 12/12/2014 15:32 -

> Excellent detective work all around -- thanks for helping to pin this down,

> Louis and Roberto. Ideally Ubuntu will just upgrade to OPAM 1.2 rather than

> just fix Dose

>

> Louis -- can we do anything in OPAM 1.2 to ensure that packagers don't get

> this mixed up in the future via a failing configure script, as David suggests?

> In OpenBSD, I elected to import the -full archive rather than piecemeal

> packaging of the libraries required to build OPAM.

>

> -anil

>

>

> > On 11 Dec 2014, at 13:56, Roberto Di Cosmo <roberto@dicosmo.org> wrote:

> >

> > Just for completeness, here is the info I can confirm after checking with

> > the Debian side:

> >

> > - in Debian Jessie and Sid, opam 1.2 is now correctly packaged together with

> > aspcud 1.9 and dose 3.3

> >

> > - unfortunately, the time-boxed development process of Ubuntu, with a release

> > in mid-October, ended in picking up an inconsistent set of versions of our

> > beloved packages from the Debian timeline; this is not something that only

> > happen to us, it is intrinsically related to these imperfectly aligned

> > processes, and I suppose the Ubuntu people will be quick to act on this,

> > as they are probably used to this kind of events

> >

> > --

> > Roberto

> >

> > On Thu, Dec 11, 2014 at 10:40:57AM +0900, Louis Gesbert wrote:

> >> It's indeed completely broken, that's bad news indeed.

> >>

> >> But I confirm my diagnostic: aspcud is not in cause, Dose is (well, or the dose interface in opam 1.1, not trying to put the blame on anyone). The problem happens even without aspcud installed.

> >>

> >> Here is the original report: https://github.com/ocaml/opam/issues/1683

> >>

> >> Opam build got broken between 1.1.1-1 (trusty) and 1.1.1-1build3 (utopic) because the dose version was upgraded from 3.1.3-7build1 to 3.2.2-2build1. It's very painful when everything types and compiles after an upgrade, but gets subtly broken :(

> >>

> >> I filed a bug at https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346

> >> Hope they can act on it quickly...

> >>

> >> Thanks for notifying and helping trace this!

> >> Louis

> >>

> >>> - Anil Madhavapeddy, 10/12/2014 14:54 -

> >>> I just reproduced it by following the referenced bug report.

> >>>

> >>> From a fresh Ubuntu 14.10, if I do:

> >>>

> >>> $ sudo apt-get install opam camlp4-extra aspcud

> >>> $ opam init -a

> >>> $ opam install mirage -y

> >>> $ eval `opam config env`

> >>>

> >>> At this point some packages have been installed and mirage is installed.

> >>>

> >>> Now however, if I use mirage it invokes opam install again and packages

> >>> are reinstalled as a duplicate. See below:

> >>>

> >>> opam install --yes conduit cow cowabloga crunch cstruct io-page lwt mirage-clock-unix mirage-conduit mirage-console mirage-fs-unix mirage-http mirage-net-unix mirage-types mirage-unix tcpip vchan

> >>> [NOTE] Package mirage-types is already installed (current version is 2.1.0).

> >>> [NOTE] Package lwt is already installed (current version is 2.4.6).

> >>> [NOTE] Package io-page is already installed (current version is 1.1.1).

> >>> [NOTE] Package cstruct is already installed (current version is 1.4.0).

> >>> [NOTE] Package crunch is already installed (current version is 1.3.0).

> >>> [WARNING] mirage-unix.2.1.0 references unknown package mirage-profile

> >>> The following actions will be performed:

> >>> - install ocamlfind.1.5.5 [required by cowabloga, crunch, mirage-fs-unix, mirage-http]

> >>> - install base-no-ppx.base [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install camlp4.4.01.0 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install base-threads.base [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install base-bigarray.base [required by cowabloga]

> >>> - install base-unix.base [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install xmlm.1.2.0 [required by cowabloga]

> >>> - install uutf.0.9.3 [required by cowabloga]

> >>> - install stringext.1.1.0 [required by cowabloga, mirage-http]

> >>> - install ssl.0.4.7 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install re.1.2.2 [required by cowabloga, mirage-http]

> >>> - install ounit.2.0.0 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install hex.0.1.0 [required by cowabloga]

> >>> - install cmdliner.0.9.5 [required by cowabloga, crunch, mirage-http]

> >>> - install base64.1.0.0 [required by cowabloga, mirage-http]

> >>> - install base-bytes.legacy [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install ulex.1.1 [required by cowabloga]

> >>> - install type_conv.111.13.00 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install optcomp.1.6 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install omd.1.2.3 [required by cowabloga]

> >>> - install jsonm.0.9.1 [required by cowabloga]

> >>> - install lwt.2.4.6 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install crunch.1.3.0

> >>> - install sexplib.111.25.00 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install fieldslib.109.20.03 [required by cowabloga, mirage-http]

> >>> - install dyntype.0.9.0 [required by cowabloga]

> >>> - install ocplib-endian.0.7 [required by cowabloga, mirage-fs-unix, mirage-http]

> >>> - install uri.1.7.2 [required by cowabloga, mirage-http]

> >>>

> >>> I've not managed to narrow it down further to a smaller test case, but the OPAMDEBUG

> >>> gist is up at: https://gist.github.com/avsm/62e28b05e2b282ed5fbe

> >>>

> >>> Any inspiration from there from the CUDF interactions in the above gist?

> >>>

> >>> -anil

> >>>

> >>>> On 10 Dec 2014, at 01:15, Louis Gesbert <louis.gesbert@ocamlpro.com> wrote:

> >>>>

> >>>> I've been trying to reproduce the issue, but things seem fine, sort of:

> >>>>

> >>>> From what I could gather:

> >>>> * trusty (14.04LTS) has 1.1 and aspcud 1.8, it works fine

> >>>> * utopic (14.10, latest) has 1.1 and aspcud 1.9

> >>>> * vivid (15.04, unreleased) has OPAM 1.2, so it's ok. Recommends aspcud, too

> >>>>

> >>>> Note that there should be no conflict that I know of between OPAM 1.1 and aspcud 1.9 -- it's just that newer OPAM will benefit from the more advanced criteria offered. Where we have been hitting problems on Debian was by compiling with a different version of *Dose* [1] (which has a much less standardised interface).

> >>>>

> >>>> There is still a known issue, though, the missing dependency on m4 that will bite you as soon as you try to install ocamlfind [2] and which is very badly reported with

> >>>> ```

> >>>> ===== ERROR while installing ocamlfind.1.5.5 =====

> >>>> Internal error:

> >>>> "ocamlfind": command not found.

> >>>> ```

> >>>>

> >>>> so it would still be nice if they could backport (so that there is a better error) or recommend m4.

> >>>>

> >>>> Cheers,

> >>>> Louis

> >>>>

> >>>>

> >>>> [1] https://github.com/ocaml/opam/issues/1683

> >>>> [2] https://github.com/ocaml/opam/issues/1658

> >>>>

> >>>> - Anil Madhavapeddy, 09/12/2014 11:16 -

> >>>>> It looks like the latest Ubuntu has a completely broken OPAM out of the box since it ships with OPAM 1.1.1 and Aspcud 1.9 (which requires OPAM 1.2 due to a changed solver interface).

> >>>>>

> >>>>> This leads to issues such as this: https://github.com/mirage/mirage-skeleton/issues/59

> >>>>>

> >>>>> Does anyone know how to get in touch with Ubuntu folk to request a backport of OPAM 1.2 to Ubuntu 14.10?

> >>>>>

> >>>>> -anil

> >>>>> _______________________________________________

> >>>>> opam-devel mailing list

> >>>>> opam-devel@lists.ocaml.org

> >>>>> http://lists.ocaml.org/listinfo/opam-devel

> >>>> _______________________________________________

> >>>> opam-devel mailing list

> >>>> opam-devel@lists.ocaml.org

> >>>> http://lists.ocaml.org/listinfo/opam-devel

> >>>>

> >>>

> >>> _______________________________________________

> >>> opam-devel mailing list

> >>> opam-devel@lists.ocaml.org

> >>> http://lists.ocaml.org/listinfo/opam-devel

> >> _______________________________________________

> >> opam-devel mailing list

> >> opam-devel@lists.ocaml.org

> >> http://lists.ocaml.org/listinfo/opam-devel

> >

>

--nextPart1689993.ETHeaMfqNo-- --===============1177796862373681303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1177796862373681303==-- From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 07:08:31 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 07:08:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzgoQ-0003VZ-JG; Sat, 13 Dec 2014 07:08:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzgoO-0003VU-QS for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 07:08:20 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 6F/EF-24859-3E5EB845; Sat, 13 Dec 2014 07:08:19 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-5.tower-31.messagelabs.com!1418454498!13087709!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18373 invoked from network); 13 Dec 2014 07:08:18 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 07:08:18 -0000 Received: from [192.168.1.116] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 679b6b07; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 13 Dec 2014 07:13:58 +0000 (GMT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <8AF80C70-E69C-47DA-9BBA-1C32E021B096@recoil.org> X-Mailer: iPad Mail (11B651) From: Anil Madhavapeddy Date: Sat, 13 Dec 2014 07:08:14 +0000 To: Nicolas Ojeda Bar Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] vmnet and ip routes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Have to use DHCP with vmnet I believe, or possibly bind a static IP alias to the bridge100 (or similar) interface. Anil > On 13 Dec 2014, at 01:16, Nicolas Ojeda Bar wrote: > > Hi list, > > I am trying to make the `ping` example in `mirage-skeleton` work with > `vmnet` on OS X. The unikernel is binding to the address 10.0.0.2, > and 10.0.0.1 is the default gateway. > > Previously (when using tun/tap), in order to ping the unikernel all we > had to do was to bind 10.0.0.1 to the `tap` interface. > > When using `vmnet`, I tried binding 10.0.0.1 to the bridge or the > associated virtual ethernet interface but it does not seem to work. > Or rather, it only half-works: the unikernel receives the ARP queries > but its response does not appear to reach anyone. > > What am I missing ? > > Thanks! > > Best wishes, > Nicolas > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 07:08:31 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 07:08:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzgoQ-0003VZ-JG; Sat, 13 Dec 2014 07:08:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzgoO-0003VU-QS for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 07:08:20 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 6F/EF-24859-3E5EB845; Sat, 13 Dec 2014 07:08:19 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-5.tower-31.messagelabs.com!1418454498!13087709!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18373 invoked from network); 13 Dec 2014 07:08:18 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-5.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 07:08:18 -0000 Received: from [192.168.1.116] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 679b6b07; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 13 Dec 2014 07:13:58 +0000 (GMT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <8AF80C70-E69C-47DA-9BBA-1C32E021B096@recoil.org> X-Mailer: iPad Mail (11B651) From: Anil Madhavapeddy Date: Sat, 13 Dec 2014 07:08:14 +0000 To: Nicolas Ojeda Bar Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] vmnet and ip routes X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Have to use DHCP with vmnet I believe, or possibly bind a static IP alias to the bridge100 (or similar) interface. Anil > On 13 Dec 2014, at 01:16, Nicolas Ojeda Bar wrote: > > Hi list, > > I am trying to make the `ping` example in `mirage-skeleton` work with > `vmnet` on OS X. The unikernel is binding to the address 10.0.0.2, > and 10.0.0.1 is the default gateway. > > Previously (when using tun/tap), in order to ping the unikernel all we > had to do was to bind 10.0.0.1 to the `tap` interface. > > When using `vmnet`, I tried binding 10.0.0.1 to the bridge or the > associated virtual ethernet interface but it does not seem to work. > Or rather, it only half-works: the unikernel receives the ARP queries > but its response does not appear to reach anyone. > > What am I missing ? > > Thanks! > > Best wishes, > Nicolas > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 11:18:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 11:18:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzkia-0000Z9-VB; Sat, 13 Dec 2014 11:18:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzkiZ-0000Z4-KV for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 11:18:35 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 9D/10-25276-A802C845; Sat, 13 Dec 2014 11:18:34 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-21.messagelabs.com!1418469514!15366068!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17535 invoked from network); 13 Dec 2014 11:18:34 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 11:18:34 -0000 Received: from [10.3.187.234] (dab-ell1-h-5-1.dab.02.net [82.132.236.137]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id d07bd9de; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Sat, 13 Dec 2014 11:24:13 +0000 (GMT) From: Anil Madhavapeddy X-Mailer: iPhone Mail (12B435) Message-Id: <4179EC8B-A5D6-499C-8B01-0A168AF2AC6A@recoil.org> Date: Sat, 13 Dec 2014 11:17:37 +0000 To: mirageos-devel Mime-Version: 1.0 (1.0) Subject: [MirageOS-devel] Updating list of git repos X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org If you have a Mirage-related git repo with a library, could you please check that it's in the TROVE file in https://github.com/mirage/mirage-www? I use these to generate the aggregate changelog -- for a end of year blog post but also for Lars to use. I've not checked if the latest TLS or Irmin kind are in there. Thanks! Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 11:18:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 11:18:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzkia-0000Z9-VB; Sat, 13 Dec 2014 11:18:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzkiZ-0000Z4-KV for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 11:18:35 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 9D/10-25276-A802C845; Sat, 13 Dec 2014 11:18:34 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-21.messagelabs.com!1418469514!15366068!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17535 invoked from network); 13 Dec 2014 11:18:34 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 11:18:34 -0000 Received: from [10.3.187.234] (dab-ell1-h-5-1.dab.02.net [82.132.236.137]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id d07bd9de; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Sat, 13 Dec 2014 11:24:13 +0000 (GMT) From: Anil Madhavapeddy X-Mailer: iPhone Mail (12B435) Message-Id: <4179EC8B-A5D6-499C-8B01-0A168AF2AC6A@recoil.org> Date: Sat, 13 Dec 2014 11:17:37 +0000 To: mirageos-devel Mime-Version: 1.0 (1.0) Subject: [MirageOS-devel] Updating list of git repos X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org If you have a Mirage-related git repo with a library, could you please check that it's in the TROVE file in https://github.com/mirage/mirage-www? I use these to generate the aggregate changelog -- for a end of year blog post but also for Lars to use. I've not checked if the latest TLS or Irmin kind are in there. Thanks! Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 12:32:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 12:32:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzlrt-00024W-6w; Sat, 13 Dec 2014 12:32:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzlnH-0001yR-La for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 12:27:31 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id DE/12-26740-2B03C845; Sat, 13 Dec 2014 12:27:30 +0000 X-Env-Sender: Christophe.TROESTLER@umons.ac.be X-Msg-Ref: server-5.tower-31.messagelabs.com!1418473649!13121196!1 X-Originating-IP: [157.55.234.60] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10044 invoked from network); 13 Dec 2014 12:27:30 -0000 Received: from mail-db3on0060.outbound.protection.outlook.com (HELO emea01-db3-obe.outbound.protection.outlook.com) (157.55.234.60) by server-5.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 13 Dec 2014 12:27:30 -0000 Received: from AMXPR05CA0030.eurprd05.prod.outlook.com (10.242.9.158) by DB4PR05MB0830.eurprd05.prod.outlook.com (25.161.248.153) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sat, 13 Dec 2014 12:27:29 +0000 Received: from AM1FFO11FD047.protection.gbl (2a01:111:f400:7e00::168) by AMXPR05CA0030.outlook.office365.com (2a01:111:e400:803c::30) with Microsoft SMTP Server (TLS) id 15.1.26.15 via Frontend Transport; Sat, 13 Dec 2014 12:27:28 +0000 Received: from smtp.umons.ac.be (193.190.208.132) by AM1FFO11FD047.mail.protection.outlook.com (10.174.65.210) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Sat, 13 Dec 2014 12:27:28 +0000 Received: from poincare (10.104.2.63) by smtp.umons.ac.be (10.104.2.84) with Microsoft SMTP Server (TLS) id 14.3.224.1; Sat, 13 Dec 2014 13:27:22 +0100 Received: from localhost ([::1]) by poincare with esmtp (Exim 4.84) (envelope-from ) id 1Xzln7-0008VZ-6C; Sat, 13 Dec 2014 13:27:21 +0100 Date: Sat, 13 Dec 2014 13:27:20 +0100 Message-ID: <20141213.132720.1360309041060667382.Christophe.Troestler@umons.ac.be> To: From: Christophe Troestler In-Reply-To: <3900186.VCNjxAKEzz@agaric> References: <20141211135600.GA30089@traveler> <3900186.VCNjxAKEzz@agaric> X-Face: #2fb%mPx>rRL@4ff~TVgZ"<[:,oL"`TUEGK/[8/qb58~C>jR(x4A+v/n)7BgpEtIph_neoLKJBq0JBY9:}8v|j Organization: Universite de Mons (http://math.umons.ac.be/anum/) X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) MIME-Version: 1.0 X-Originating-IP: [10.104.2.63] X-EOPAttributedMessage: 0 X-Matching-Connectors: 130629472486164283; (9b551343-d075-4328-d154-08d0574c44b8,aa519c6d-c5b7-417d-4ec3-08d1170c20a9); (9b551343-d075-4328-d154-08d0574c44b8,aa519c6d-c5b7-417d-4ec3-08d1170c20a9) Received-SPF: Pass (protection.outlook.com: domain of umons.ac.be designates 193.190.208.132 as permitted sender) receiver=protection.outlook.com; client-ip=193.190.208.132; helo=smtp.umons.ac.be; X-Forefront-Antispam-Report: CIP:193.190.208.132; CTRY:BE; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(189002)(24454002)(199003)(57986006)(89996001)(2351001)(64706001)(107046002)(87936001)(76506005)(23726002)(4396001)(50226001)(120916001)(103116003)(6806004)(76176999)(86362001)(99396003)(20776003)(47776003)(50466002)(92566001)(106466001)(97756001)(46102003)(46406003)(50986999)(31966008)(74482002)(110136001)(62966003)(21056001)(36756003)(77156002)(16796002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR05MB0830; H:smtp.umons.ac.be; FPR:; SPF:Pass; MLV:sfv; PTR:smtp.umons.ac.be,imap.umons.ac.be,pop.umons.ac.be; MX:1; A:0; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR05MB0830; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:DB4PR05MB0830; X-Forefront-PRVS: 04244E0DC5 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(400003)(401002)(402001); SRVR:DB4PR05MB0830; X-Mailman-Approved-At: Sat, 13 Dec 2014 12:32:15 +0000 Cc: opam-devel@lists.ocaml.org, mirageos-devel@lists.xenproject.org, anil@recoil.org Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On Sat, 13 Dec 2014 10:24:45 +0900, Louis Gesbert wrote: > > For this specific bug,running "make tests" would have been enough (I > just tested on my VM). For being defensive and having ./configure > refuse newer version of dependencies, the m4 macros don't seem to > provide version filtering (only API testing. Here the API was > compatible, anyway that would have failed at build-time). Does > ocamlfind even provide an easy way to get the version of a package? $ ocamlfind query -format "%v" lacaml 7.1.5 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 12:32:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 12:32:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzlrt-00024W-6w; Sat, 13 Dec 2014 12:32:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzlnH-0001yR-La for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 12:27:31 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id DE/12-26740-2B03C845; Sat, 13 Dec 2014 12:27:30 +0000 X-Env-Sender: Christophe.TROESTLER@umons.ac.be X-Msg-Ref: server-5.tower-31.messagelabs.com!1418473649!13121196!1 X-Originating-IP: [157.55.234.60] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10044 invoked from network); 13 Dec 2014 12:27:30 -0000 Received: from mail-db3on0060.outbound.protection.outlook.com (HELO emea01-db3-obe.outbound.protection.outlook.com) (157.55.234.60) by server-5.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 13 Dec 2014 12:27:30 -0000 Received: from AMXPR05CA0030.eurprd05.prod.outlook.com (10.242.9.158) by DB4PR05MB0830.eurprd05.prod.outlook.com (25.161.248.153) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sat, 13 Dec 2014 12:27:29 +0000 Received: from AM1FFO11FD047.protection.gbl (2a01:111:f400:7e00::168) by AMXPR05CA0030.outlook.office365.com (2a01:111:e400:803c::30) with Microsoft SMTP Server (TLS) id 15.1.26.15 via Frontend Transport; Sat, 13 Dec 2014 12:27:28 +0000 Received: from smtp.umons.ac.be (193.190.208.132) by AM1FFO11FD047.mail.protection.outlook.com (10.174.65.210) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Sat, 13 Dec 2014 12:27:28 +0000 Received: from poincare (10.104.2.63) by smtp.umons.ac.be (10.104.2.84) with Microsoft SMTP Server (TLS) id 14.3.224.1; Sat, 13 Dec 2014 13:27:22 +0100 Received: from localhost ([::1]) by poincare with esmtp (Exim 4.84) (envelope-from ) id 1Xzln7-0008VZ-6C; Sat, 13 Dec 2014 13:27:21 +0100 Date: Sat, 13 Dec 2014 13:27:20 +0100 Message-ID: <20141213.132720.1360309041060667382.Christophe.Troestler@umons.ac.be> To: From: Christophe Troestler In-Reply-To: <3900186.VCNjxAKEzz@agaric> References: <20141211135600.GA30089@traveler> <3900186.VCNjxAKEzz@agaric> X-Face: #2fb%mPx>rRL@4ff~TVgZ"<[:,oL"`TUEGK/[8/qb58~C>jR(x4A+v/n)7BgpEtIph_neoLKJBq0JBY9:}8v|j Organization: Universite de Mons (http://math.umons.ac.be/anum/) X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) MIME-Version: 1.0 X-Originating-IP: [10.104.2.63] X-EOPAttributedMessage: 0 X-Matching-Connectors: 130629472486164283; (9b551343-d075-4328-d154-08d0574c44b8,aa519c6d-c5b7-417d-4ec3-08d1170c20a9); (9b551343-d075-4328-d154-08d0574c44b8,aa519c6d-c5b7-417d-4ec3-08d1170c20a9) Received-SPF: Pass (protection.outlook.com: domain of umons.ac.be designates 193.190.208.132 as permitted sender) receiver=protection.outlook.com; client-ip=193.190.208.132; helo=smtp.umons.ac.be; X-Forefront-Antispam-Report: CIP:193.190.208.132; CTRY:BE; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(189002)(24454002)(199003)(57986006)(89996001)(2351001)(64706001)(107046002)(87936001)(76506005)(23726002)(4396001)(50226001)(120916001)(103116003)(6806004)(76176999)(86362001)(99396003)(20776003)(47776003)(50466002)(92566001)(106466001)(97756001)(46102003)(46406003)(50986999)(31966008)(74482002)(110136001)(62966003)(21056001)(36756003)(77156002)(16796002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR05MB0830; H:smtp.umons.ac.be; FPR:; SPF:Pass; MLV:sfv; PTR:smtp.umons.ac.be,imap.umons.ac.be,pop.umons.ac.be; MX:1; A:0; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR05MB0830; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:DB4PR05MB0830; X-Forefront-PRVS: 04244E0DC5 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(400003)(401002)(402001); SRVR:DB4PR05MB0830; X-Mailman-Approved-At: Sat, 13 Dec 2014 12:32:15 +0000 Cc: opam-devel@lists.ocaml.org, mirageos-devel@lists.xenproject.org, anil@recoil.org Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On Sat, 13 Dec 2014 10:24:45 +0900, Louis Gesbert wrote: > > For this specific bug,running "make tests" would have been enough (I > just tested on my VM). For being defensive and having ./configure > refuse newer version of dependencies, the m4 macros don't seem to > provide version filtering (only API testing. Here the API was > compatible, anyway that would have failed at build-time). Does > ocamlfind even provide an easy way to get the version of a package? $ ocamlfind query -format "%v" lacaml 7.1.5 _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 13:57:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 13:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XznCX-0003g3-Iu; Sat, 13 Dec 2014 13:57:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XznCV-0003ft-W5 for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 13:57:40 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 2C/6F-27584-3D54C845; Sat, 13 Dec 2014 13:57:39 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-13.tower-206.messagelabs.com!1418479055!13185466!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2904 invoked from network); 13 Dec 2014 13:57:35 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 13:57:35 -0000 Received: from [10.12.2.241] (no-dns-yet.convergencegroup.co.uk [37.205.61.202]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id afd8c733; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 13 Dec 2014 14:03:16 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <3A5650C9-9F0F-47F1-9204-4A90D1A04F9D@recoil.org> Date: Sat, 13 Dec 2014 13:57:37 +0000 Message-Id: References: <1395927366.3749.13.camel@Guybrush> <533450C5.5070005@xen.org> <3A5650C9-9F0F-47F1-9204-4A90D1A04F9D@recoil.org> To: lars.kurth@xen.org X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" , "xen-api@lists.xen.org" Subject: Re: [MirageOS-devel] [Xen-API] Issues and questions related to contribution metrics dashboard for XAPI and Mirage OS X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Lars, Better late than never, but here is the current list of Mirage repositories= (relative to GitHub). https://raw.githubusercontent.com/mirage/mirage-www/master/TROVE Replicated below as full URLs: https://github.com/avsm/ezxmlm https://github.com/avsm/ocaml-github https://github.com/djs55/ocaml-xenstore-clients https://github.com/mirage/cowabloga https://github.com/mirage/dyntype https://github.com/mirage/ezjsonm https://github.com/mirage/io-page https://github.com/mirage/irmin https://github.com/mirage/merge-queues https://github.com/mirage/merge-ropes https://github.com/mirage/mirage https://github.com/mirage/mirage-block-unix https://github.com/mirage/mirage-block-volume https://github.com/mirage/mirage-block-xen https://github.com/mirage/mirage-clock https://github.com/mirage/mirage-console https://github.com/mirage/mirage-decks https://github.com/mirage/mirage-entropy https://github.com/mirage/mirage-fs-unix https://github.com/mirage/mirage-http https://github.com/mirage/mirage-net-macosx https://github.com/mirage/mirage-net-unix https://github.com/mirage/mirage-net-xen https://github.com/mirage/mirage-platform https://github.com/mirage/mirage-profile https://github.com/mirage/mirage-skeleton https://github.com/mirage/mirage-tc https://github.com/mirage/mirage-tcpip https://github.com/mirage/mirage-vagrant-vms https://github.com/mirage/mirage-www https://github.com/mirage/mirage-xen-minios https://github.com/mirage/ocaml-cohttp https://github.com/mirage/ocaml-conduit https://github.com/mirage/ocaml-cow https://github.com/mirage/ocaml-crunch https://github.com/mirage/ocaml-cstruct https://github.com/mirage/ocaml-dns https://github.com/mirage/ocaml-fat https://github.com/mirage/ocaml-git https://github.com/mirage/ocaml-hex https://github.com/mirage/ocaml-ipaddr https://github.com/mirage/ocaml-lazy-trie https://github.com/mirage/ocaml-mstruct https://github.com/mirage/ocaml-mbr https://github.com/mirage/ocaml-pcap https://github.com/mirage/ocaml-tuntap https://github.com/mirage/ocaml-tar https://github.com/mirage/ocaml-uri https://github.com/mirage/ocaml-vchan https://github.com/mirage/ocaml-vmnet https://github.com/mirage/ocaml-xenstore https://github.com/mirage/shared-memory-ring https://github.com/mirage/xen-disk https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-x509 https://github.com/mirleft/ocaml-nocrypto https://github.com/mirleft/ocaml-asn1-combinators https://github.com/ocamllabs/ocaml-ctypes https://github.com/samoht/alcotest https://github.com/talex5/mirage-trace-viewer The consolidated changelog is present at: http://openmirage.org/releases -anil > On 27 Mar 2014, at 16:28, Anil Madhavapeddy wrote: > = > Dave and I are currently going through our repository list to normalize t= his for Mirage. > = > https://github.com/mirage/mirage/issues/236 > = > We'll update you shortly when the "trove" is completed. That will have a= n authoritative list of libraries, as well as spotting any licensing incons= istencies or incorrect fork orders. > = > cheers, > Anil > = > On 27 Mar 2014, at 16:24, Lars Kurth wrote: > = >> Hi all, >> = >> a while ago I kicked a conversation related to putting a dashboard for t= he Xen project sub projects together. As it turns out there is an issue in = XAPI and MirageOS repositories on github. Some of them are forks of upstre= ams, which are hard for the tool to analyze. My proposal would be to *not a= nalyse them* and include them into statistics. If I don't hear any screams,= then this will be the default. The list of forks detected are listed below= ... >> = >> Also, it would be good to let me know of any other repos that you dont w= ant to analyse. The full list is at http://bitergia.com/projects/citrix-xen= -dashboard/browser/scm-repos.html (note that there is 79 pages of them) whi= ch should be aggregated into buckets for XAPI and opam >> = >> Regards >> Lars >> = >> =3D Detected forks in XAPI Project =3D >> xen-unstable-mirror git://github.com/xapi-project/xen-unstable-mirror.git >> PRDup git://github.com/xapi-project/PRDup.git >> blktap-dkms git://github.com/xapi-project/blktap-dkms.git >> cdrom git://github.com/xapi-project/cdrom.git >> ffs git://github.com/xapi-project/ffs.git >> libvhd git://github.com/xapi-project/libvhd.git >> nbd git://github.com/xapi-project/nbd.git >> netdev git://github.com/xapi-project/netdev.git >> ocaml-fd-send-recv git://github.com/xapi-project/ocaml-fd-send-recv.git >> ocaml-opasswd git://github.com/xapi-project/ocaml-opasswd.git >> ocaml-sha git://github.com/xapi-project/ocaml-sha.git >> ocaml-tar git://github.com/xapi-project/ocaml-tar.git >> ocaml-vhd git://github.com/xapi-project/ocaml-vhd.git >> ocaml-xenstore-clients git://github.com/xapi-project/ocaml-xenstore-clie= nts.git >> ocamltest git://github.com/xapi-project/ocamltest.git >> oclock git://github.com/xapi-project/oclock.git >> opam git://github.com/xapi-project/opam.git >> opam-repository git://github.com/xapi-project/opam-repository.git >> python-github2 git://github.com/xapi-project/python-github2.git >> tapctl git://github.com/xapi-project/tapctl.git >> vhd-tool git://github.com/xapi-project/vhd-tool.git >> vncterm git://github.com/xapi-project/vncterm.git >> wsproxy git://github.com/xapi-project/wsproxy.git >> xcp-eliloader git://github.com/xapi-project/xcp-eliloader.git >> xcp-guest-templates git://github.com/xapi-project/xcp-guest-templates.git >> xcp-idl git://github.com/xapi-project/xcp-idl.git >> xcp-storage-managers git://github.com/xapi-project/xcp-storage-managers.= git >> xen-api-backports git://github.com/xapi-project/xen-api-backports.git >> xen-api-client git://github.com/xapi-project/xen-api-client.git >> xen-api-libs-specs git://github.com/xapi-project/xen-api-libs-specs.git >> xen-api-libs-transitional git://github.com/xapi-project/xen-api-libs-tra= nsitional.git >> xs-pull-request-build-scripts git://github.com/xapi-project/xs-pull-requ= est-build-scripts.git >> = >> =3D Detected forks in Mirage OS =3D >> xen git://github.com/mirage/xen.git >> mirari git://github.com/mirage/mirari.git >> ocaml-cohttp git://github.com/mirage/ocaml-cohttp.git >> ocaml-crypto-keys git://github.com/mirage/ocaml-crypto-keys.git >> ocaml-cstruct git://github.com/mirage/ocaml-cstruct.git >> ocaml-dns git://github.com/mirage/ocaml-dns.git >> ocaml-openflow git://github.com/mirage/ocaml-openflow.git >> ocaml-re git://github.com/mirage/ocaml-re.git >> ocaml-tuntap git://github.com/mirage/ocaml-tuntap.git >> ocaml-uri git://github.com/mirage/ocaml-uri.git >> ocaml-xenstore git://github.com/mirage/ocaml-xenstore.git >> opam-repository git://github.com/mirage/opam-repository.git >> = >> = >> = >> = >> -------- Original Message -------- >> Subject: Removing forks from the analysis >> Date: Thu, 27 Mar 2014 14:36:06 +0100 >> From: Santiago Due=F1as >> To: Lars Kurth >> CC: citrix@lists.bitergia.com >> = >> Hi again Lars, >> = >> during our analysis, we found that some of your git repos are forks from >> upstream repositories. I don not know whether you talk to Manrique or >> Jesus about that but I prefer to remember you which possibilities we >> offer and which one we have follow. >> = >> The repositories that we have already analyzed are listed on the >> scm-repos page: >> = >> = >> http://bitergia.com/projects/citrix-xen-dashboard/browser/scm-repos.html >> = >> = >> We offer three possibilities for treating these cases: >> = >> - Do not analyze forks. This is the default option. We have removed from >> the analysis those repositories marked as forks in Github and others >> from upstream such as "ocaml" and "opam" series (see the attached file >> that includes the full list of forks). >> = >> Probably, you will want to remove more. If this is your choice, please >> have a look at the repositories page and send me an email with the list >> of git repositories you want to remove from the analysis. >> = >> - Analyze forks. Take into account that this can affect the whole >> numbers and stats, particularly if your team is not really active in >> these repos. >> = >> - Analyze differences between upstream and local repositories. Due this >> functionality is out of the basic dashboard, please talk to Manrique or >> Jesus to get more details, if interested. >> = >> Santi >> -- = >> Santiago Due=F1as >> = >> sduenas@bitergia.com >> = >> Bitergia S.L.L >> = >> = >> = >> = >> = >> _______________________________________________ >> Xen-api mailing list >> Xen-api@lists.xen.org >> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api > = > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 13:57:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 13:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XznCX-0003g3-Iu; Sat, 13 Dec 2014 13:57:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XznCV-0003ft-W5 for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 13:57:40 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 2C/6F-27584-3D54C845; Sat, 13 Dec 2014 13:57:39 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-13.tower-206.messagelabs.com!1418479055!13185466!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2904 invoked from network); 13 Dec 2014 13:57:35 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Dec 2014 13:57:35 -0000 Received: from [10.12.2.241] (no-dns-yet.convergencegroup.co.uk [37.205.61.202]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id afd8c733; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 13 Dec 2014 14:03:16 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <3A5650C9-9F0F-47F1-9204-4A90D1A04F9D@recoil.org> Date: Sat, 13 Dec 2014 13:57:37 +0000 Message-Id: References: <1395927366.3749.13.camel@Guybrush> <533450C5.5070005@xen.org> <3A5650C9-9F0F-47F1-9204-4A90D1A04F9D@recoil.org> To: lars.kurth@xen.org X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" , "xen-api@lists.xen.org" Subject: Re: [MirageOS-devel] [Xen-API] Issues and questions related to contribution metrics dashboard for XAPI and Mirage OS X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Lars, Better late than never, but here is the current list of Mirage repositories= (relative to GitHub). https://raw.githubusercontent.com/mirage/mirage-www/master/TROVE Replicated below as full URLs: https://github.com/avsm/ezxmlm https://github.com/avsm/ocaml-github https://github.com/djs55/ocaml-xenstore-clients https://github.com/mirage/cowabloga https://github.com/mirage/dyntype https://github.com/mirage/ezjsonm https://github.com/mirage/io-page https://github.com/mirage/irmin https://github.com/mirage/merge-queues https://github.com/mirage/merge-ropes https://github.com/mirage/mirage https://github.com/mirage/mirage-block-unix https://github.com/mirage/mirage-block-volume https://github.com/mirage/mirage-block-xen https://github.com/mirage/mirage-clock https://github.com/mirage/mirage-console https://github.com/mirage/mirage-decks https://github.com/mirage/mirage-entropy https://github.com/mirage/mirage-fs-unix https://github.com/mirage/mirage-http https://github.com/mirage/mirage-net-macosx https://github.com/mirage/mirage-net-unix https://github.com/mirage/mirage-net-xen https://github.com/mirage/mirage-platform https://github.com/mirage/mirage-profile https://github.com/mirage/mirage-skeleton https://github.com/mirage/mirage-tc https://github.com/mirage/mirage-tcpip https://github.com/mirage/mirage-vagrant-vms https://github.com/mirage/mirage-www https://github.com/mirage/mirage-xen-minios https://github.com/mirage/ocaml-cohttp https://github.com/mirage/ocaml-conduit https://github.com/mirage/ocaml-cow https://github.com/mirage/ocaml-crunch https://github.com/mirage/ocaml-cstruct https://github.com/mirage/ocaml-dns https://github.com/mirage/ocaml-fat https://github.com/mirage/ocaml-git https://github.com/mirage/ocaml-hex https://github.com/mirage/ocaml-ipaddr https://github.com/mirage/ocaml-lazy-trie https://github.com/mirage/ocaml-mstruct https://github.com/mirage/ocaml-mbr https://github.com/mirage/ocaml-pcap https://github.com/mirage/ocaml-tuntap https://github.com/mirage/ocaml-tar https://github.com/mirage/ocaml-uri https://github.com/mirage/ocaml-vchan https://github.com/mirage/ocaml-vmnet https://github.com/mirage/ocaml-xenstore https://github.com/mirage/shared-memory-ring https://github.com/mirage/xen-disk https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-x509 https://github.com/mirleft/ocaml-nocrypto https://github.com/mirleft/ocaml-asn1-combinators https://github.com/ocamllabs/ocaml-ctypes https://github.com/samoht/alcotest https://github.com/talex5/mirage-trace-viewer The consolidated changelog is present at: http://openmirage.org/releases -anil > On 27 Mar 2014, at 16:28, Anil Madhavapeddy wrote: > = > Dave and I are currently going through our repository list to normalize t= his for Mirage. > = > https://github.com/mirage/mirage/issues/236 > = > We'll update you shortly when the "trove" is completed. That will have a= n authoritative list of libraries, as well as spotting any licensing incons= istencies or incorrect fork orders. > = > cheers, > Anil > = > On 27 Mar 2014, at 16:24, Lars Kurth wrote: > = >> Hi all, >> = >> a while ago I kicked a conversation related to putting a dashboard for t= he Xen project sub projects together. As it turns out there is an issue in = XAPI and MirageOS repositories on github. Some of them are forks of upstre= ams, which are hard for the tool to analyze. My proposal would be to *not a= nalyse them* and include them into statistics. If I don't hear any screams,= then this will be the default. The list of forks detected are listed below= ... >> = >> Also, it would be good to let me know of any other repos that you dont w= ant to analyse. The full list is at http://bitergia.com/projects/citrix-xen= -dashboard/browser/scm-repos.html (note that there is 79 pages of them) whi= ch should be aggregated into buckets for XAPI and opam >> = >> Regards >> Lars >> = >> =3D Detected forks in XAPI Project =3D >> xen-unstable-mirror git://github.com/xapi-project/xen-unstable-mirror.git >> PRDup git://github.com/xapi-project/PRDup.git >> blktap-dkms git://github.com/xapi-project/blktap-dkms.git >> cdrom git://github.com/xapi-project/cdrom.git >> ffs git://github.com/xapi-project/ffs.git >> libvhd git://github.com/xapi-project/libvhd.git >> nbd git://github.com/xapi-project/nbd.git >> netdev git://github.com/xapi-project/netdev.git >> ocaml-fd-send-recv git://github.com/xapi-project/ocaml-fd-send-recv.git >> ocaml-opasswd git://github.com/xapi-project/ocaml-opasswd.git >> ocaml-sha git://github.com/xapi-project/ocaml-sha.git >> ocaml-tar git://github.com/xapi-project/ocaml-tar.git >> ocaml-vhd git://github.com/xapi-project/ocaml-vhd.git >> ocaml-xenstore-clients git://github.com/xapi-project/ocaml-xenstore-clie= nts.git >> ocamltest git://github.com/xapi-project/ocamltest.git >> oclock git://github.com/xapi-project/oclock.git >> opam git://github.com/xapi-project/opam.git >> opam-repository git://github.com/xapi-project/opam-repository.git >> python-github2 git://github.com/xapi-project/python-github2.git >> tapctl git://github.com/xapi-project/tapctl.git >> vhd-tool git://github.com/xapi-project/vhd-tool.git >> vncterm git://github.com/xapi-project/vncterm.git >> wsproxy git://github.com/xapi-project/wsproxy.git >> xcp-eliloader git://github.com/xapi-project/xcp-eliloader.git >> xcp-guest-templates git://github.com/xapi-project/xcp-guest-templates.git >> xcp-idl git://github.com/xapi-project/xcp-idl.git >> xcp-storage-managers git://github.com/xapi-project/xcp-storage-managers.= git >> xen-api-backports git://github.com/xapi-project/xen-api-backports.git >> xen-api-client git://github.com/xapi-project/xen-api-client.git >> xen-api-libs-specs git://github.com/xapi-project/xen-api-libs-specs.git >> xen-api-libs-transitional git://github.com/xapi-project/xen-api-libs-tra= nsitional.git >> xs-pull-request-build-scripts git://github.com/xapi-project/xs-pull-requ= est-build-scripts.git >> = >> =3D Detected forks in Mirage OS =3D >> xen git://github.com/mirage/xen.git >> mirari git://github.com/mirage/mirari.git >> ocaml-cohttp git://github.com/mirage/ocaml-cohttp.git >> ocaml-crypto-keys git://github.com/mirage/ocaml-crypto-keys.git >> ocaml-cstruct git://github.com/mirage/ocaml-cstruct.git >> ocaml-dns git://github.com/mirage/ocaml-dns.git >> ocaml-openflow git://github.com/mirage/ocaml-openflow.git >> ocaml-re git://github.com/mirage/ocaml-re.git >> ocaml-tuntap git://github.com/mirage/ocaml-tuntap.git >> ocaml-uri git://github.com/mirage/ocaml-uri.git >> ocaml-xenstore git://github.com/mirage/ocaml-xenstore.git >> opam-repository git://github.com/mirage/opam-repository.git >> = >> = >> = >> = >> -------- Original Message -------- >> Subject: Removing forks from the analysis >> Date: Thu, 27 Mar 2014 14:36:06 +0100 >> From: Santiago Due=F1as >> To: Lars Kurth >> CC: citrix@lists.bitergia.com >> = >> Hi again Lars, >> = >> during our analysis, we found that some of your git repos are forks from >> upstream repositories. I don not know whether you talk to Manrique or >> Jesus about that but I prefer to remember you which possibilities we >> offer and which one we have follow. >> = >> The repositories that we have already analyzed are listed on the >> scm-repos page: >> = >> = >> http://bitergia.com/projects/citrix-xen-dashboard/browser/scm-repos.html >> = >> = >> We offer three possibilities for treating these cases: >> = >> - Do not analyze forks. This is the default option. We have removed from >> the analysis those repositories marked as forks in Github and others >> from upstream such as "ocaml" and "opam" series (see the attached file >> that includes the full list of forks). >> = >> Probably, you will want to remove more. If this is your choice, please >> have a look at the repositories page and send me an email with the list >> of git repositories you want to remove from the analysis. >> = >> - Analyze forks. Take into account that this can affect the whole >> numbers and stats, particularly if your team is not really active in >> these repos. >> = >> - Analyze differences between upstream and local repositories. Due this >> functionality is out of the basic dashboard, please talk to Manrique or >> Jesus to get more details, if interested. >> = >> Santi >> -- = >> Santiago Due=F1as >> = >> sduenas@bitergia.com >> = >> Bitergia S.L.L >> = >> = >> = >> = >> = >> _______________________________________________ >> Xen-api mailing list >> Xen-api@lists.xen.org >> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api > = > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 16:53:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 16:53:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzpws-0007xO-VE; Sat, 13 Dec 2014 16:53:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzpwr-0007xJ-KI for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 16:53:41 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 11/3B-05632-41F6C845; Sat, 13 Dec 2014 16:53:40 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1418489617!13075254!1 X-Originating-IP: [209.85.220.176] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6883 invoked from network); 13 Dec 2014 16:53:38 -0000 Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com) (209.85.220.176) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Dec 2014 16:53:38 -0000 Received: by mail-vc0-f176.google.com with SMTP id hq12so4347331vcb.7 for ; Sat, 13 Dec 2014 08:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NBpMV7E+agLy9vWAmknFUxNtDPB8sr4xoYMicUk3V1o=; b=YXPuH8kzF84pt6xAKu01Y3tExkQcXfoE6o87zQzvoDFqLxsAFPum0jrDdKfWAuLVFj jlATA9/wPb4zYTLO2gQRXJR5W3NVthIogU/BIrYVozz+XO7YJixdoJ9E7OegDaIMy9KW 7sdGvdUaIV7mSl+qWaSPz74lnR0+/Py8kIHf46Id1MjqaFdPFb9lJwazMdyGnJ72UACX qKb38jRPRXxlQVT3IwIRSj8dz3Kkpf2C/O8Du4vgLT5zAIsmN3iPwQ4yq3zTW4g31kT/ ew+9RGoCnDai8dNs5bVKG4pVAqkMCsWkaSqzISGB0pVl+xmmflkbG7CvqmCpaQwysVmh 37ZQ== MIME-Version: 1.0 X-Received: by 10.220.12.131 with SMTP id x3mr13169757vcx.63.1418489617090; Sat, 13 Dec 2014 08:53:37 -0800 (PST) Received: by 10.31.183.134 with HTTP; Sat, 13 Dec 2014 08:53:37 -0800 (PST) Date: Sat, 13 Dec 2014 16:53:37 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Mirage profiling and tracing update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I've put up a page on the Mirage wiki describing the new tracing system: http://openmirage.org/wiki/profiling Whereas the previous examples looked at performance, this one looks at using tracing to hunt down a bug (a race condition in the network stack). Some new features since the previous blog post: - The trace format is now binary (CTF). - The mirage tool can automatically configure your unikernel for tracing. - You can view the trace of a program while it's still running, or after it has crashed. - The mirage-trace-viewer tool can now read from multiple input sources (trace files, Unix processes and Xen guests) and output in mutliple formats (GTK viewer, HTML/JavaScript website, CTF file). - Many Mirage libraries now have tracing instrumentation built in. - We now trace Lwt_conditions too, even though they're not technically threads, adding a nice splash of orange to the diagrams. - The GTK viewer has an Export SVG feature on the popup menu (which I used for the poster). I'd be interested to hear about other people using it... -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 13 16:53:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 13 Dec 2014 16:53:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzpws-0007xO-VE; Sat, 13 Dec 2014 16:53:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzpwr-0007xJ-KI for mirageos-devel@lists.xenproject.org; Sat, 13 Dec 2014 16:53:41 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 11/3B-05632-41F6C845; Sat, 13 Dec 2014 16:53:40 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1418489617!13075254!1 X-Originating-IP: [209.85.220.176] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6883 invoked from network); 13 Dec 2014 16:53:38 -0000 Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com) (209.85.220.176) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Dec 2014 16:53:38 -0000 Received: by mail-vc0-f176.google.com with SMTP id hq12so4347331vcb.7 for ; Sat, 13 Dec 2014 08:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NBpMV7E+agLy9vWAmknFUxNtDPB8sr4xoYMicUk3V1o=; b=YXPuH8kzF84pt6xAKu01Y3tExkQcXfoE6o87zQzvoDFqLxsAFPum0jrDdKfWAuLVFj jlATA9/wPb4zYTLO2gQRXJR5W3NVthIogU/BIrYVozz+XO7YJixdoJ9E7OegDaIMy9KW 7sdGvdUaIV7mSl+qWaSPz74lnR0+/Py8kIHf46Id1MjqaFdPFb9lJwazMdyGnJ72UACX qKb38jRPRXxlQVT3IwIRSj8dz3Kkpf2C/O8Du4vgLT5zAIsmN3iPwQ4yq3zTW4g31kT/ ew+9RGoCnDai8dNs5bVKG4pVAqkMCsWkaSqzISGB0pVl+xmmflkbG7CvqmCpaQwysVmh 37ZQ== MIME-Version: 1.0 X-Received: by 10.220.12.131 with SMTP id x3mr13169757vcx.63.1418489617090; Sat, 13 Dec 2014 08:53:37 -0800 (PST) Received: by 10.31.183.134 with HTTP; Sat, 13 Dec 2014 08:53:37 -0800 (PST) Date: Sat, 13 Dec 2014 16:53:37 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Mirage profiling and tracing update X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I've put up a page on the Mirage wiki describing the new tracing system: http://openmirage.org/wiki/profiling Whereas the previous examples looked at performance, this one looks at using tracing to hunt down a bug (a race condition in the network stack). Some new features since the previous blog post: - The trace format is now binary (CTF). - The mirage tool can automatically configure your unikernel for tracing. - You can view the trace of a program while it's still running, or after it has crashed. - The mirage-trace-viewer tool can now read from multiple input sources (trace files, Unix processes and Xen guests) and output in mutliple formats (GTK viewer, HTML/JavaScript website, CTF file). - Many Mirage libraries now have tracing instrumentation built in. - We now trace Lwt_conditions too, even though they're not technically threads, adding a nice splash of orange to the diagrams. - The GTK viewer has an Export SVG feature on the popup menu (which I used for the poster). I'd be interested to hear about other people using it... -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzyq1-0008Qk-Ok; Sun, 14 Dec 2014 02:23:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzyq0-0008Qf-MA for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:12 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 0F/A1-25276-F84FC845; Sun, 14 Dec 2014 02:23:11 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-21.messagelabs.com!1418523790!15449730!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.0 required=7.0 tests=DATE_IN_PAST_06_12, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32509 invoked from network); 14 Dec 2014 02:23:11 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:11 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 5e79d56e; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 14 Dec 2014 02:28:52 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sat, 13 Dec 2014 19:55:41 +0000 Message-Id: <8C49B405-D4FA-4119-BE70-E798E0876157@recoil.org> References: To: Brian Brietzke X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 11 Dec 2014, at 01:53, Brian Brietzke wrote: > > There are implementations of the protocols for mysql and postgresql that > popular. I've done some digging and have found pure ocaml implementations > for both redis and mongo. I'll have to do some experimenting and see > what the results are like. It would actually be really useful to have a simple benchmark against Redis and Mongo to put into mirage-skeleton. We could run it over both TCP and Vchan as a much more realistic workload than the usual iperf efforts. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzyq1-0008Qk-Ok; Sun, 14 Dec 2014 02:23:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xzyq0-0008Qf-MA for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:12 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 0F/A1-25276-F84FC845; Sun, 14 Dec 2014 02:23:11 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-21.messagelabs.com!1418523790!15449730!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.0 required=7.0 tests=DATE_IN_PAST_06_12, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32509 invoked from network); 14 Dec 2014 02:23:11 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:11 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 5e79d56e; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 14 Dec 2014 02:28:52 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sat, 13 Dec 2014 19:55:41 +0000 Message-Id: <8C49B405-D4FA-4119-BE70-E798E0876157@recoil.org> References: To: Brian Brietzke X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 11 Dec 2014, at 01:53, Brian Brietzke wrote: > > There are implementations of the protocols for mysql and postgresql that > popular. I've done some digging and have found pure ocaml implementations > for both redis and mongo. I'll have to do some experimenting and see > what the results are like. It would actually be really useful to have a simple benchmark against Redis and Mongo to put into mirage-skeleton. We could run it over both TCP and Vchan as a much more realistic workload than the usual iperf efforts. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:29 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqH-0008RO-4y; Sun, 14 Dec 2014 02:23:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqF-0008RG-KC for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:27 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 28/7D-15461-F94FC845; Sun, 14 Dec 2014 02:23:27 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-21.messagelabs.com!1418523806!15424337!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2495 invoked from network); 14 Dec 2014 02:23:26 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:26 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6686e5a3; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Sun, 14 Dec 2014 02:29:09 +0000 (GMT) From: Anil Madhavapeddy Date: Sat, 13 Dec 2014 20:32:00 +0000 References: <20141205183153.GD19077@dezo.moloch.sk> To: mirageos-devel Message-Id: <86E6FB93-2376-4B04-9A4E-83BC77E05870@recoil.org> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] Fwd: [Xen-devel] RFC: Cleaning up the Mini-OS namespace X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thomas(L), What's the status of your minios-as-a-library patches that we currently have in mirage-xen-minios? They never got applied upstream did they? -anil > Begin forwarded message: > > Date: 5 December 2014 18:31:53 GMT > From: Martin Lucina > To: Antti Kantee > Cc: Andrew Cooper , xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy , Samuel Thibault , Ian Jackson , Stefano Stabellini > Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace > > pooka@iki.fi said: >> I wonder if work is minimized if we attempt to merge before or after >> we (I?) take the carving knife for a second round in the rumprun-xen >> repo to minimize MiniOS to run only on top of itself. > > Before, I think. Minimizing our copy of Mini-OS duplicates what we would > need to do to the upstream copy. > > I think the steps are roughly as follows: > > a) split the current rumprun-xen build out of the Mini-OS Makefile. > b) replace our fork of Mini-OS with the vanilla upstream Mini-OS. > c) re-apply my work and your work, while checking things keep working > with upstream xen.git, until we get rumprun-xen working again. > > c) will leave us with a set of patches to upstream. > > Does this make sense? It's a fair amount of work but mostly retracing steps > we've already done. > > It'd help if we had a full list of "what exactly needs to keep working > upstream", see my other reply to Andrew. Maybe also osstest building and > running Mini-OS related tests off our branch while we do the work? (Ian: > ping? Doable?) > > Martin > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:29 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqH-0008RO-4y; Sun, 14 Dec 2014 02:23:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqF-0008RG-KC for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:27 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 28/7D-15461-F94FC845; Sun, 14 Dec 2014 02:23:27 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-21.messagelabs.com!1418523806!15424337!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2495 invoked from network); 14 Dec 2014 02:23:26 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:26 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6686e5a3; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Sun, 14 Dec 2014 02:29:09 +0000 (GMT) From: Anil Madhavapeddy Date: Sat, 13 Dec 2014 20:32:00 +0000 References: <20141205183153.GD19077@dezo.moloch.sk> To: mirageos-devel Message-Id: <86E6FB93-2376-4B04-9A4E-83BC77E05870@recoil.org> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] Fwd: [Xen-devel] RFC: Cleaning up the Mini-OS namespace X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thomas(L), What's the status of your minios-as-a-library patches that we currently have in mirage-xen-minios? They never got applied upstream did they? -anil > Begin forwarded message: > > Date: 5 December 2014 18:31:53 GMT > From: Martin Lucina > To: Antti Kantee > Cc: Andrew Cooper , xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy , Samuel Thibault , Ian Jackson , Stefano Stabellini > Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace > > pooka@iki.fi said: >> I wonder if work is minimized if we attempt to merge before or after >> we (I?) take the carving knife for a second round in the rumprun-xen >> repo to minimize MiniOS to run only on top of itself. > > Before, I think. Minimizing our copy of Mini-OS duplicates what we would > need to do to the upstream copy. > > I think the steps are roughly as follows: > > a) split the current rumprun-xen build out of the Mini-OS Makefile. > b) replace our fork of Mini-OS with the vanilla upstream Mini-OS. > c) re-apply my work and your work, while checking things keep working > with upstream xen.git, until we get rumprun-xen working again. > > c) will leave us with a set of patches to upstream. > > Does this make sense? It's a fair amount of work but mostly retracing steps > we've already done. > > It'd help if we had a full list of "what exactly needs to keep working > upstream", see my other reply to Andrew. Maybe also osstest building and > running Mini-OS related tests off our branch while we do the work? (Ian: > ping? Doable?) > > Martin > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:34 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqM-0008SL-82; Sun, 14 Dec 2014 02:23:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqK-0008S6-E1 for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:32 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id B0/E1-25276-3A4FC845; Sun, 14 Dec 2014 02:23:31 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-21.messagelabs.com!1418523806!15424337!2 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3049 invoked from network); 14 Dec 2014 02:23:31 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:31 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6fba6d9f; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 14 Dec 2014 02:29:14 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141204143631.GE11192@dezo.moloch.sk> Date: Sat, 13 Dec 2014 20:42:42 +0000 Message-Id: References: <20141204143631.GE11192@dezo.moloch.sk> To: Martin Lucina X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 4 Dec 2014, at 14:36, Martin Lucina wrote: > > Hi Anil, > > in your talk at operatingsystems.io last week (great talk, thanks!), you > mentioned that you have Unikernels "booting in the time between SYN and > ACK" [1]. > > I'm curious; is this the "raw" boot time (first instruction to serving > requests) or a "full stack on Xen" boot time (domain creation to serving > requests)? Hi Martin, This is the full boot time -- from receiving a DNS request to starting up the virtual machine from scratch (including attaching devices such as netfront/netback). > > If it is the latter I presume you are using a custom Xen toolstack to > create the domain? My measurements with rump kernels show that the "xl" > toolstack is quite slow, depending on the exact Xen setup taking between 1 > to 2.5 seconds to create a domain with a vif and a couple of disk devices. > > Following discussion with Ian Jackson, this (xl) should be be fairly easy > to optimize, has/is anyone from Mirage OS looking at this? There were a sequence of slow bits in xl that we progressively fixed. Most of these should be winding their way upstream as they get cleaned up. Improvements came from: 1) Replace hotplug script with minimal version (currently a shell script) 2) Replace hotplug script with inline ioctl() gave even better results as no forking happened at all. 3) Parallelise hotplug with domain build. 4) Don't block on primary console 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. Number 3) is fairly invasive to libxl, and the XenstoreNG is still being prepared for release, but the minimal ioctl is pretty easy and could be the default. We're preparing a camera-ready paper on this for NSDI 2015, so I'll share that with you privately and the camera-ready with the list (if anyone wants to read it, please ask -- I just don't want the draft version to be archived by crawlers and so am not posting it here). -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:34 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqM-0008SL-82; Sun, 14 Dec 2014 02:23:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqK-0008S6-E1 for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:32 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id B0/E1-25276-3A4FC845; Sun, 14 Dec 2014 02:23:31 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-21.messagelabs.com!1418523806!15424337!2 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3049 invoked from network); 14 Dec 2014 02:23:31 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:31 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 6fba6d9f; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 14 Dec 2014 02:29:14 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141204143631.GE11192@dezo.moloch.sk> Date: Sat, 13 Dec 2014 20:42:42 +0000 Message-Id: References: <20141204143631.GE11192@dezo.moloch.sk> To: Martin Lucina X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 4 Dec 2014, at 14:36, Martin Lucina wrote: > > Hi Anil, > > in your talk at operatingsystems.io last week (great talk, thanks!), you > mentioned that you have Unikernels "booting in the time between SYN and > ACK" [1]. > > I'm curious; is this the "raw" boot time (first instruction to serving > requests) or a "full stack on Xen" boot time (domain creation to serving > requests)? Hi Martin, This is the full boot time -- from receiving a DNS request to starting up the virtual machine from scratch (including attaching devices such as netfront/netback). > > If it is the latter I presume you are using a custom Xen toolstack to > create the domain? My measurements with rump kernels show that the "xl" > toolstack is quite slow, depending on the exact Xen setup taking between 1 > to 2.5 seconds to create a domain with a vif and a couple of disk devices. > > Following discussion with Ian Jackson, this (xl) should be be fairly easy > to optimize, has/is anyone from Mirage OS looking at this? There were a sequence of slow bits in xl that we progressively fixed. Most of these should be winding their way upstream as they get cleaned up. Improvements came from: 1) Replace hotplug script with minimal version (currently a shell script) 2) Replace hotplug script with inline ioctl() gave even better results as no forking happened at all. 3) Parallelise hotplug with domain build. 4) Don't block on primary console 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. Number 3) is fairly invasive to libxl, and the XenstoreNG is still being prepared for release, but the minimal ioctl is pretty easy and could be the default. We're preparing a camera-ready paper on this for NSDI 2015, so I'll share that with you privately and the camera-ready with the list (if anyone wants to read it, please ask -- I just don't want the draft version to be archived by crawlers and so am not posting it here). -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqZ-0008V8-Lk; Sun, 14 Dec 2014 02:23:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqY-0008Ut-MV for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:46 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 74/54-09842-2B4FC845; Sun, 14 Dec 2014 02:23:46 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-21.messagelabs.com!1418523825!15391914!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4843 invoked from network); 14 Dec 2014 02:23:45 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:45 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 39a67054; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 14 Dec 2014 02:29:28 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sat, 13 Dec 2014 21:27:26 +0000 Message-Id: <0AF57287-8C17-451D-BD50-05611FE1E8AC@recoil.org> References: To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: Thomas Gazagnaire , mirageos-devel Subject: Re: [MirageOS-devel] v1/v2/vN-- a discussion X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 28 Nov 2014, at 16:40, Richard Mortier wrote: > > all; > > just had a chat with thomas regarding the V1/V2 discussions from last week. this is my attempt to capture the results, which i fully expect thomas to have to correct :) > > the problem is essentially that we have several implicit dependencies that have to be captured between a library author and the mirage tool author: which opam packages contain libraries that implement which `mirage-types` signatures and also provide `'a impl` values satisfying `'a typ` types in the mirage tool. > > thus when a library author wants to rev a library (eg., dave wants to change V1.FS_LWT, or we want to support the equivalent of a `mirage-dev` branch) there are several things that may need updating: `mirage-types` has to have the signature updated, the implementations of that signature need to have their code updated, any dependencies between those implementations and other opam packages/ocamlfind packages need to be captured in the mirage tool (eg., Makefile generation to install correct packages and libraries), and the mirage tool needs to potentially have code generation for that implementation updated as well. this is all rather messy. > > thomas managed to explain things to me sufficiently that i realise this is just gnarly and intertwined and that's the way it is :) but there were two relatively easy steps that seemed to make sense and would help us manage this a bit better in the relatively near-term: > > 1/ refactor the mirage tool so that the dependencies between all `'a typ` and the opam packages and findlib packages that implement them are explicitly pulled into a single datastructure. > > 2/ refactor the mirage tool and current mirage library implementations so that the functions implementing the code generation that the mirage tool does (to create the `main.ml` when it compiles a `config.ml`) are moved out of the tool and into the implementations themselves. I think this one sounds useful, but has the potential to just be shuffling the problem around instead. We would move the code generation logic into the libraries, but now the `mirage` tool maintainer has to look around and rev all the libraries if they modify the main.ml code generation (for example, to add optional profiling hooks or something similar). I'm not really convinced the code motion would be worth it at this stage vs (for example) prototyping a metacaml-based staging framework and seeing what a printf-free tool would look like. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 02:23:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 02:23:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqZ-0008V8-Lk; Sun, 14 Dec 2014 02:23:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XzyqY-0008Ut-MV for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 02:23:46 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 74/54-09842-2B4FC845; Sun, 14 Dec 2014 02:23:46 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-21.messagelabs.com!1418523825!15391914!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.9 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4843 invoked from network); 14 Dec 2014 02:23:45 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2014 02:23:45 -0000 Received: from [10.252.134.97] (198.134.93.254 [198.134.93.254]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 39a67054; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 14 Dec 2014 02:29:28 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sat, 13 Dec 2014 21:27:26 +0000 Message-Id: <0AF57287-8C17-451D-BD50-05611FE1E8AC@recoil.org> References: To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: Thomas Gazagnaire , mirageos-devel Subject: Re: [MirageOS-devel] v1/v2/vN-- a discussion X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 28 Nov 2014, at 16:40, Richard Mortier wrote: > > all; > > just had a chat with thomas regarding the V1/V2 discussions from last week. this is my attempt to capture the results, which i fully expect thomas to have to correct :) > > the problem is essentially that we have several implicit dependencies that have to be captured between a library author and the mirage tool author: which opam packages contain libraries that implement which `mirage-types` signatures and also provide `'a impl` values satisfying `'a typ` types in the mirage tool. > > thus when a library author wants to rev a library (eg., dave wants to change V1.FS_LWT, or we want to support the equivalent of a `mirage-dev` branch) there are several things that may need updating: `mirage-types` has to have the signature updated, the implementations of that signature need to have their code updated, any dependencies between those implementations and other opam packages/ocamlfind packages need to be captured in the mirage tool (eg., Makefile generation to install correct packages and libraries), and the mirage tool needs to potentially have code generation for that implementation updated as well. this is all rather messy. > > thomas managed to explain things to me sufficiently that i realise this is just gnarly and intertwined and that's the way it is :) but there were two relatively easy steps that seemed to make sense and would help us manage this a bit better in the relatively near-term: > > 1/ refactor the mirage tool so that the dependencies between all `'a typ` and the opam packages and findlib packages that implement them are explicitly pulled into a single datastructure. > > 2/ refactor the mirage tool and current mirage library implementations so that the functions implementing the code generation that the mirage tool does (to create the `main.ml` when it compiles a `config.ml`) are moved out of the tool and into the implementations themselves. I think this one sounds useful, but has the potential to just be shuffling the problem around instead. We would move the code generation logic into the libraries, but now the `mirage` tool maintainer has to look around and rev all the libraries if they modify the main.ml code generation (for example, to add optional profiling hooks or something similar). I'm not really convinced the code motion would be worth it at this stage vs (for example) prototyping a metacaml-based staging framework and seeing what a printf-free tool would look like. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 12:58:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 12:58:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y08kJ-0003Et-99; Sun, 14 Dec 2014 12:57:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y08kH-0003Eo-Ry for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 12:57:58 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id FC/CE-02576-5598D845; Sun, 14 Dec 2014 12:57:57 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1418561875!11621127!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23039 invoked from network); 14 Dec 2014 12:57:56 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Dec 2014 12:57:56 -0000 Received: by mail-vc0-f175.google.com with SMTP id hy10so4757582vcb.20 for ; Sun, 14 Dec 2014 04:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aaqqYfP6mPyH4RxBaapHNlrw8sRkPEuYzPZUMbj6EVc=; b=fM5b6CbX5YR8LRms/mygAYY3buNodfOLhflR6wZ/njM+g6/z4AXfU/axzQh+ulBk4P 87+ykFqSNhS3xf43kwT1GNJqT8g2I1oyC15988o6ESqpPEynrtVq0Xj5DFDj9Q1qY/LZ yr8sLI+rOMqtmqlUdZ2RMZVU4IKzso02u/ogycf+3rH7Ov7SiLkVWTUI7ox4XWCcUssD o8NnJtdCSUHzjBlvBUF9fiUcBySUx9zh9HbNqD7ziJsLwruS4//7EYKONWE4VQgp4YLk hgs7UqKL5Vj3yYuye3USb1tMhbUHRowtpdORUZQWmhuJKiaZsIjd/ZOhXIzWPJi5ALyE XiWg== MIME-Version: 1.0 X-Received: by 10.221.41.67 with SMTP id tt3mr15667098vcb.47.1418561875023; Sun, 14 Dec 2014 04:57:55 -0800 (PST) Received: by 10.31.183.134 with HTTP; Sun, 14 Dec 2014 04:57:54 -0800 (PST) In-Reply-To: <86E6FB93-2376-4B04-9A4E-83BC77E05870@recoil.org> References: <20141205183153.GD19077@dezo.moloch.sk> <86E6FB93-2376-4B04-9A4E-83BC77E05870@recoil.org> Date: Sun, 14 Dec 2014 12:57:54 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: mirageos-devel Subject: Re: [MirageOS-devel] Fwd: [Xen-devel] RFC: Cleaning up the Mini-OS namespace X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org The library work is waiting for the ARM patches to be accepted first. The latest version is on my "devel" branch (which is regularly rebased against Xen master): https://github.com/talex5/xen/commits/devel In terms of upstreaming, the most obvious thing that needs doing is modifying Xen's stubdoms to use the library. Currently, they do some horrible make stuff to reach over and grab what they need from the extras/mini-os directory... Ian Jackson (I think) mentioned splitting Mini-OS into a separate repository, which would help a lot too. On 13 December 2014 at 20:32, Anil Madhavapeddy wrote: > Thomas(L), > > What's the status of your minios-as-a-library patches that we currently > have in mirage-xen-minios? They never got applied upstream did they? > > -anil > >> Begin forwarded message: >> >> Date: 5 December 2014 18:31:53 GMT >> From: Martin Lucina >> To: Antti Kantee >> Cc: Andrew Cooper , xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy , Samuel Thibault , Ian Jackson , Stefano Stabellini >> Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace >> >> pooka@iki.fi said: >>> I wonder if work is minimized if we attempt to merge before or after >>> we (I?) take the carving knife for a second round in the rumprun-xen >>> repo to minimize MiniOS to run only on top of itself. >> >> Before, I think. Minimizing our copy of Mini-OS duplicates what we would >> need to do to the upstream copy. >> >> I think the steps are roughly as follows: >> >> a) split the current rumprun-xen build out of the Mini-OS Makefile. >> b) replace our fork of Mini-OS with the vanilla upstream Mini-OS. >> c) re-apply my work and your work, while checking things keep working >> with upstream xen.git, until we get rumprun-xen working again. >> >> c) will leave us with a set of patches to upstream. >> >> Does this make sense? It's a fair amount of work but mostly retracing steps >> we've already done. >> >> It'd help if we had a full list of "what exactly needs to keep working >> upstream", see my other reply to Andrew. Maybe also osstest building and >> running Mini-OS related tests off our branch while we do the work? (Ian: >> ping? Doable?) >> >> Martin >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sun Dec 14 12:58:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 14 Dec 2014 12:58:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y08kJ-0003Et-99; Sun, 14 Dec 2014 12:57:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y08kH-0003Eo-Ry for mirageos-devel@lists.xenproject.org; Sun, 14 Dec 2014 12:57:58 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id FC/CE-02576-5598D845; Sun, 14 Dec 2014 12:57:57 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1418561875!11621127!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23039 invoked from network); 14 Dec 2014 12:57:56 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Dec 2014 12:57:56 -0000 Received: by mail-vc0-f175.google.com with SMTP id hy10so4757582vcb.20 for ; Sun, 14 Dec 2014 04:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aaqqYfP6mPyH4RxBaapHNlrw8sRkPEuYzPZUMbj6EVc=; b=fM5b6CbX5YR8LRms/mygAYY3buNodfOLhflR6wZ/njM+g6/z4AXfU/axzQh+ulBk4P 87+ykFqSNhS3xf43kwT1GNJqT8g2I1oyC15988o6ESqpPEynrtVq0Xj5DFDj9Q1qY/LZ yr8sLI+rOMqtmqlUdZ2RMZVU4IKzso02u/ogycf+3rH7Ov7SiLkVWTUI7ox4XWCcUssD o8NnJtdCSUHzjBlvBUF9fiUcBySUx9zh9HbNqD7ziJsLwruS4//7EYKONWE4VQgp4YLk hgs7UqKL5Vj3yYuye3USb1tMhbUHRowtpdORUZQWmhuJKiaZsIjd/ZOhXIzWPJi5ALyE XiWg== MIME-Version: 1.0 X-Received: by 10.221.41.67 with SMTP id tt3mr15667098vcb.47.1418561875023; Sun, 14 Dec 2014 04:57:55 -0800 (PST) Received: by 10.31.183.134 with HTTP; Sun, 14 Dec 2014 04:57:54 -0800 (PST) In-Reply-To: <86E6FB93-2376-4B04-9A4E-83BC77E05870@recoil.org> References: <20141205183153.GD19077@dezo.moloch.sk> <86E6FB93-2376-4B04-9A4E-83BC77E05870@recoil.org> Date: Sun, 14 Dec 2014 12:57:54 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: mirageos-devel Subject: Re: [MirageOS-devel] Fwd: [Xen-devel] RFC: Cleaning up the Mini-OS namespace X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org The library work is waiting for the ARM patches to be accepted first. The latest version is on my "devel" branch (which is regularly rebased against Xen master): https://github.com/talex5/xen/commits/devel In terms of upstreaming, the most obvious thing that needs doing is modifying Xen's stubdoms to use the library. Currently, they do some horrible make stuff to reach over and grab what they need from the extras/mini-os directory... Ian Jackson (I think) mentioned splitting Mini-OS into a separate repository, which would help a lot too. On 13 December 2014 at 20:32, Anil Madhavapeddy wrote: > Thomas(L), > > What's the status of your minios-as-a-library patches that we currently > have in mirage-xen-minios? They never got applied upstream did they? > > -anil > >> Begin forwarded message: >> >> Date: 5 December 2014 18:31:53 GMT >> From: Martin Lucina >> To: Antti Kantee >> Cc: Andrew Cooper , xen-devel@lists.xen.org, rumpkernel-users@lists.sourceforge.net, Anil Madhavapeddy , Samuel Thibault , Ian Jackson , Stefano Stabellini >> Subject: Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace >> >> pooka@iki.fi said: >>> I wonder if work is minimized if we attempt to merge before or after >>> we (I?) take the carving knife for a second round in the rumprun-xen >>> repo to minimize MiniOS to run only on top of itself. >> >> Before, I think. Minimizing our copy of Mini-OS duplicates what we would >> need to do to the upstream copy. >> >> I think the steps are roughly as follows: >> >> a) split the current rumprun-xen build out of the Mini-OS Makefile. >> b) replace our fork of Mini-OS with the vanilla upstream Mini-OS. >> c) re-apply my work and your work, while checking things keep working >> with upstream xen.git, until we get rumprun-xen working again. >> >> c) will leave us with a set of patches to upstream. >> >> Does this make sense? It's a fair amount of work but mostly retracing steps >> we've already done. >> >> It'd help if we had a full list of "what exactly needs to keep working >> upstream", see my other reply to Andrew. Maybe also osstest building and >> running Mini-OS related tests off our branch while we do the work? (Ian: >> ping? Doable?) >> >> Martin >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 03:56:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 03:56:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0MlS-0002dN-O2; Mon, 15 Dec 2014 03:56:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0MlR-0002d8-Ag for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 03:56:05 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 2E/EB-09842-4DB5E845; Mon, 15 Dec 2014 03:56:04 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1418615763!15558411!1 X-Originating-IP: [209.85.215.48] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18024 invoked from network); 15 Dec 2014 03:56:03 -0000 Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 03:56:03 -0000 Received: by mail-la0-f48.google.com with SMTP id gf13so8571950lab.21 for ; Sun, 14 Dec 2014 19:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zU5ONomH9f2+bGyxrvK3wQvBVh5+CTNuxsoFrg6cTFw=; b=byn2sSnXSXTnIM0BhwuN/LQFqmtZoZqxtq18b6sXSsy6OgUgPH6ntwR39I36RGa9ON oyTXEyJ7k+kJqLICDAPSj9/HdsQ5raVgRRWUN7I+crR6x5ZbcJ+Ngl6xwC9gDEM2u9kg RqfzuFngUbEapupi+0x7zEAHhxlEIwRAsJgRTY5hYcJFlj8WJAwP1y0T7NJzy5thiX81 /gkGb+Wyzy/LOAvNP7aCK575Q9lUT1WUFYajxWfWDXGHNjDbFNiZAQe/ij0yx1RJcVq2 W5URJoCC3P47lguo3RBbeQ78B+NPrAslqQ7GrPZNHmlXisbTZPhKx31qGHtRUMQM3PBH TJUw== MIME-Version: 1.0 X-Received: by 10.152.22.199 with SMTP id g7mr28280771laf.23.1418615763113; Sun, 14 Dec 2014 19:56:03 -0800 (PST) Received: by 10.112.0.104 with HTTP; Sun, 14 Dec 2014 19:56:03 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Dec 2014 22:56:03 -0500 X-Google-Sender-Auth: MKNeBMXQW11hrsybPbY5vDfwTEo Message-ID: From: Russ Pavlicek To: Russ Pavlicek Cc: "xen-users@lists.xen.org" , xen-api@lists.xen.org, xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, xen-devel@lists.xen.org Subject: Re: [MirageOS-devel] Monday is the Last Xen Project Document Day of 2014 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Reminder: Today is Document Day! Give someone a present and document a new capability, or improve an older page so it is up to date. More information is below. See you in #xendocs on IRC. On Thu, Dec 11, 2014 at 2:46 PM, Russ Pavlicek wrote: > Monday, December 15, will be our last Document Day of the year. > > Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays > which occur later in the month, we have scheduled Document Day for Monday. > > This is a great time to get our documentation ready for the new > release. Have you > added a new feature in this release? Make sure it is in the Wiki. > Have you noticed > pages which might be confusing for a new installation? Now is a great > time to clean > it up. Have you information on better integrating Xen Project with > other projects? > Share that information with others. > > All the information you need to participate in Document Day is here: > > http://wiki.xenproject.org/wiki/Xen_Document_Days > > If you get a few moments before Monday, please take a look at the > current TODO list to see other items which need attention: > > http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO > > Please think about how you can help out. If you haven't requested > to be made a Wiki editor, save time and do it now so you are ready to > go on Document Day. Just fill out the form below: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > We hope to see you Monday in #xendocs! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 03:56:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 03:56:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0MlS-0002dN-O2; Mon, 15 Dec 2014 03:56:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0MlR-0002d8-Ag for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 03:56:05 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 2E/EB-09842-4DB5E845; Mon, 15 Dec 2014 03:56:04 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1418615763!15558411!1 X-Originating-IP: [209.85.215.48] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18024 invoked from network); 15 Dec 2014 03:56:03 -0000 Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 03:56:03 -0000 Received: by mail-la0-f48.google.com with SMTP id gf13so8571950lab.21 for ; Sun, 14 Dec 2014 19:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zU5ONomH9f2+bGyxrvK3wQvBVh5+CTNuxsoFrg6cTFw=; b=byn2sSnXSXTnIM0BhwuN/LQFqmtZoZqxtq18b6sXSsy6OgUgPH6ntwR39I36RGa9ON oyTXEyJ7k+kJqLICDAPSj9/HdsQ5raVgRRWUN7I+crR6x5ZbcJ+Ngl6xwC9gDEM2u9kg RqfzuFngUbEapupi+0x7zEAHhxlEIwRAsJgRTY5hYcJFlj8WJAwP1y0T7NJzy5thiX81 /gkGb+Wyzy/LOAvNP7aCK575Q9lUT1WUFYajxWfWDXGHNjDbFNiZAQe/ij0yx1RJcVq2 W5URJoCC3P47lguo3RBbeQ78B+NPrAslqQ7GrPZNHmlXisbTZPhKx31qGHtRUMQM3PBH TJUw== MIME-Version: 1.0 X-Received: by 10.152.22.199 with SMTP id g7mr28280771laf.23.1418615763113; Sun, 14 Dec 2014 19:56:03 -0800 (PST) Received: by 10.112.0.104 with HTTP; Sun, 14 Dec 2014 19:56:03 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Dec 2014 22:56:03 -0500 X-Google-Sender-Auth: MKNeBMXQW11hrsybPbY5vDfwTEo Message-ID: From: Russ Pavlicek To: Russ Pavlicek Cc: "xen-users@lists.xen.org" , xen-api@lists.xen.org, xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, xen-devel@lists.xen.org Subject: Re: [MirageOS-devel] Monday is the Last Xen Project Document Day of 2014 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Reminder: Today is Document Day! Give someone a present and document a new capability, or improve an older page so it is up to date. More information is below. See you in #xendocs on IRC. On Thu, Dec 11, 2014 at 2:46 PM, Russ Pavlicek wrote: > Monday, December 15, will be our last Document Day of the year. > > Given the 4.5 RC4 Testing scheduled for Wednesday of next week and the holidays > which occur later in the month, we have scheduled Document Day for Monday. > > This is a great time to get our documentation ready for the new > release. Have you > added a new feature in this release? Make sure it is in the Wiki. > Have you noticed > pages which might be confusing for a new installation? Now is a great > time to clean > it up. Have you information on better integrating Xen Project with > other projects? > Share that information with others. > > All the information you need to participate in Document Day is here: > > http://wiki.xenproject.org/wiki/Xen_Document_Days > > If you get a few moments before Monday, please take a look at the > current TODO list to see other items which need attention: > > http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO > > Please think about how you can help out. If you haven't requested > to be made a Wiki editor, save time and do it now so you are ready to > go on Document Day. Just fill out the form below: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > We hope to see you Monday in #xendocs! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 11:09:53 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 11:09:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0TX8-0007dd-Tj; Mon, 15 Dec 2014 11:09:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0TX7-0007dL-3v for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:09:45 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id E5/27-26652-871CE845; Mon, 15 Dec 2014 11:09:44 +0000 X-Env-Sender: martin@lucina.net X-Msg-Ref: server-8.tower-206.messagelabs.com!1418641783!13342586!1 X-Originating-IP: [62.176.169.44] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25200 invoked from network); 15 Dec 2014 11:09:43 -0000 Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2014 11:09:43 -0000 Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89]) by mail.moloch.sk (Postfix) with ESMTPSA id 3DA60180AF55; Mon, 15 Dec 2014 12:09:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201309; t=1418641783; bh=fEvLuOVXNziLJuVYnCbnJvNGyTxjGAt+Lp3tIBM9siI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KpQpBgrxofYOwMD6cQpyIChm2prhwU3bgTBlEUEXHWuoinDY2GL0eLKX/LSjzrmPm UiU21tr6dxe74I/Kl5eUAZtA+P1BFmbTzXzE/GBQmzXD996OfLnDITyWUroqQS7A4N A9M2mo8abYAQLXwm9X0QOkQZJ/VP28HaANAws6FX5wAXyGI66k+uTjn7lSNScua9eb l+j72gXFN7goH8LdLF4qHc3SLIsHpNKxFYzGCWfjTXbFMtbzSHA6JB8rFTrgND12Pm COsruqAvnsPPnBsObiKQggwhrDJc2Yy/68HQdnT3ADcctxsBAJdFe9J6ssQSnkBsuc tvefvsYNghwVA== Received: by nodbug.moloch.sk (Postfix, from userid 1000) id F0BDA4C0E2E; Mon, 15 Dec 2014 12:10:18 +0100 (CET) Date: Mon, 15 Dec 2014 12:10:18 +0100 From: Martin Lucina To: Anil Madhavapeddy Message-ID: <20141215111018.GC27080@nodbug.moloch.sk> Mail-Followup-To: Anil Madhavapeddy , mirageos-devel@lists.xenproject.org References: <20141204143631.GE11192@dezo.moloch.sk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Anil, anil@recoil.org said: > There were a sequence of slow bits in xl that we progressively fixed. > Most of these should be winding their way upstream as they get cleaned up. > Improvements came from: > > 1) Replace hotplug script with minimal version (currently a shell script) > 2) Replace hotplug script with inline ioctl() gave even better results > as no forking happened at all. > 3) Parallelise hotplug with domain build. > 4) Don't block on primary console > 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. > > Number 3) is fairly invasive to libxl, and the XenstoreNG is still being > prepared for release, but the minimal ioctl is pretty easy and could be the > default. Right, 1) and 2) matches what we found with Ian J. while quickly looking at low-hanging fruit to optimize at the hack day after the conference. Is there a version of xen.git with these patches that I can build and use to test? I'd like to try spinning up large numbers of rump kernel based domUs which is impractical with current domain creation times. One thing not on your list is qemu spinup time; I presume this is because you are not using blkfront? The default backend for blkfront is qtap which unfortunately relies on qemu; vanilla Linux dom0 kernels don't appear to support any other backends (eg. blktap). > We're preparing a camera-ready paper on this for NSDI 2015, so I'll share > that with you privately and the camera-ready with the list (if anyone wants > to read it, please ask -- I just don't want the draft version to be > archived by crawlers and so am not posting it here). Yes, please. Martin _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 11:09:53 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 11:09:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0TX8-0007dd-Tj; Mon, 15 Dec 2014 11:09:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0TX7-0007dL-3v for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:09:45 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id E5/27-26652-871CE845; Mon, 15 Dec 2014 11:09:44 +0000 X-Env-Sender: martin@lucina.net X-Msg-Ref: server-8.tower-206.messagelabs.com!1418641783!13342586!1 X-Originating-IP: [62.176.169.44] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25200 invoked from network); 15 Dec 2014 11:09:43 -0000 Received: from chrocht.moloch.sk (HELO mail.moloch.sk) (62.176.169.44) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2014 11:09:43 -0000 Received: from nodbug.moloch.sk (chello089173022089.chello.sk [89.173.22.89]) by mail.moloch.sk (Postfix) with ESMTPSA id 3DA60180AF55; Mon, 15 Dec 2014 12:09:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201309; t=1418641783; bh=fEvLuOVXNziLJuVYnCbnJvNGyTxjGAt+Lp3tIBM9siI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KpQpBgrxofYOwMD6cQpyIChm2prhwU3bgTBlEUEXHWuoinDY2GL0eLKX/LSjzrmPm UiU21tr6dxe74I/Kl5eUAZtA+P1BFmbTzXzE/GBQmzXD996OfLnDITyWUroqQS7A4N A9M2mo8abYAQLXwm9X0QOkQZJ/VP28HaANAws6FX5wAXyGI66k+uTjn7lSNScua9eb l+j72gXFN7goH8LdLF4qHc3SLIsHpNKxFYzGCWfjTXbFMtbzSHA6JB8rFTrgND12Pm COsruqAvnsPPnBsObiKQggwhrDJc2Yy/68HQdnT3ADcctxsBAJdFe9J6ssQSnkBsuc tvefvsYNghwVA== Received: by nodbug.moloch.sk (Postfix, from userid 1000) id F0BDA4C0E2E; Mon, 15 Dec 2014 12:10:18 +0100 (CET) Date: Mon, 15 Dec 2014 12:10:18 +0100 From: Martin Lucina To: Anil Madhavapeddy Message-ID: <20141215111018.GC27080@nodbug.moloch.sk> Mail-Followup-To: Anil Madhavapeddy , mirageos-devel@lists.xenproject.org References: <20141204143631.GE11192@dezo.moloch.sk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Anil, anil@recoil.org said: > There were a sequence of slow bits in xl that we progressively fixed. > Most of these should be winding their way upstream as they get cleaned up. > Improvements came from: > > 1) Replace hotplug script with minimal version (currently a shell script) > 2) Replace hotplug script with inline ioctl() gave even better results > as no forking happened at all. > 3) Parallelise hotplug with domain build. > 4) Don't block on primary console > 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. > > Number 3) is fairly invasive to libxl, and the XenstoreNG is still being > prepared for release, but the minimal ioctl is pretty easy and could be the > default. Right, 1) and 2) matches what we found with Ian J. while quickly looking at low-hanging fruit to optimize at the hack day after the conference. Is there a version of xen.git with these patches that I can build and use to test? I'd like to try spinning up large numbers of rump kernel based domUs which is impractical with current domain creation times. One thing not on your list is qemu spinup time; I presume this is because you are not using blkfront? The default backend for blkfront is qtap which unfortunately relies on qemu; vanilla Linux dom0 kernels don't appear to support any other backends (eg. blktap). > We're preparing a camera-ready paper on this for NSDI 2015, so I'll share > that with you privately and the camera-ready with the list (if anyone wants > to read it, please ask -- I just don't want the draft version to be > archived by crawlers and so am not posting it here). Yes, please. Martin _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 11:56:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 11:56:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0UGk-00024B-38; Mon, 15 Dec 2014 11:56:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0UGj-000246-6v for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:56:53 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 6A/9F-31453-48CCE845; Mon, 15 Dec 2014 11:56:52 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-5.tower-206.messagelabs.com!1418644611!13357904!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17073 invoked from network); 15 Dec 2014 11:56:51 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2014 11:56:51 -0000 Received: from [172.16.1.102] (12.19.199.2 [12.19.199.2]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id c24fe99d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 15 Dec 2014 12:02:39 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141215111018.GC27080@nodbug.moloch.sk> Date: Mon, 15 Dec 2014 03:56:50 -0800 Message-Id: <4F4FD346-E883-4D3D-B5D1-A57EE5769D6E@recoil.org> References: <20141204143631.GE11192@dezo.moloch.sk> <20141215111018.GC27080@nodbug.moloch.sk> To: Martin Lucina X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 15 Dec 2014, at 03:10, Martin Lucina wrote: > > Hi Anil, > > anil@recoil.org said: >> There were a sequence of slow bits in xl that we progressively fixed. >> Most of these should be winding their way upstream as they get cleaned up. >> Improvements came from: >> >> 1) Replace hotplug script with minimal version (currently a shell script) >> 2) Replace hotplug script with inline ioctl() gave even better results >> as no forking happened at all. >> 3) Parallelise hotplug with domain build. >> 4) Don't block on primary console >> 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. >> >> Number 3) is fairly invasive to libxl, and the XenstoreNG is still being >> prepared for release, but the minimal ioctl is pretty easy and could be the >> default. > > Right, 1) and 2) matches what we found with Ian J. while quickly looking at > low-hanging fruit to optimize at the hack day after the conference. > > Is there a version of xen.git with these patches that I can build and use > to test? I'd like to try spinning up large numbers of rump kernel based > domUs which is impractical with current domain creation times. I'm travelling at the moment, but I can dig out the C file I wrote for the 2) case when I'm back next weekend. Jon, Dave, do you have the working tree for your XL patches available anywhere? > > One thing not on your list is qemu spinup time; I presume this is because > you are not using blkfront? The default backend for blkfront is qtap which > unfortunately relies on qemu; vanilla Linux dom0 kernels don't appear to > support any other backends (eg. blktap). > We do use blkfront, but not the qemu blkback (which I've never understood to be honest -- why introduce qemu into the driver equation unless it's absolutely necessary?). Xen-arm-builder has the blktap patches: https://github.com/mirage/xen-arm-builder/blob/master/patches/linux-0001-blktap2-fixups.xs.patch Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 11:56:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 11:56:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0UGk-00024B-38; Mon, 15 Dec 2014 11:56:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0UGj-000246-6v for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 11:56:53 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 6A/9F-31453-48CCE845; Mon, 15 Dec 2014 11:56:52 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-5.tower-206.messagelabs.com!1418644611!13357904!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17073 invoked from network); 15 Dec 2014 11:56:51 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2014 11:56:51 -0000 Received: from [172.16.1.102] (12.19.199.2 [12.19.199.2]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id c24fe99d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 15 Dec 2014 12:02:39 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <20141215111018.GC27080@nodbug.moloch.sk> Date: Mon, 15 Dec 2014 03:56:50 -0800 Message-Id: <4F4FD346-E883-4D3D-B5D1-A57EE5769D6E@recoil.org> References: <20141204143631.GE11192@dezo.moloch.sk> <20141215111018.GC27080@nodbug.moloch.sk> To: Martin Lucina X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 15 Dec 2014, at 03:10, Martin Lucina wrote: > > Hi Anil, > > anil@recoil.org said: >> There were a sequence of slow bits in xl that we progressively fixed. >> Most of these should be winding their way upstream as they get cleaned up. >> Improvements came from: >> >> 1) Replace hotplug script with minimal version (currently a shell script) >> 2) Replace hotplug script with inline ioctl() gave even better results >> as no forking happened at all. >> 3) Parallelise hotplug with domain build. >> 4) Don't block on primary console >> 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. >> >> Number 3) is fairly invasive to libxl, and the XenstoreNG is still being >> prepared for release, but the minimal ioctl is pretty easy and could be the >> default. > > Right, 1) and 2) matches what we found with Ian J. while quickly looking at > low-hanging fruit to optimize at the hack day after the conference. > > Is there a version of xen.git with these patches that I can build and use > to test? I'd like to try spinning up large numbers of rump kernel based > domUs which is impractical with current domain creation times. I'm travelling at the moment, but I can dig out the C file I wrote for the 2) case when I'm back next weekend. Jon, Dave, do you have the working tree for your XL patches available anywhere? > > One thing not on your list is qemu spinup time; I presume this is because > you are not using blkfront? The default backend for blkfront is qtap which > unfortunately relies on qemu; vanilla Linux dom0 kernels don't appear to > support any other backends (eg. blktap). > We do use blkfront, but not the qemu blkback (which I've never understood to be honest -- why introduce qemu into the driver equation unless it's absolutely necessary?). Xen-arm-builder has the blktap patches: https://github.com/mirage/xen-arm-builder/blob/master/patches/linux-0001-blktap2-fixups.xs.patch Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 13:13:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 13:13:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0VT4-0004DJ-FY; Mon, 15 Dec 2014 13:13:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0VRw-0004Cr-Nk for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 13:12:32 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id C8/0D-26858-F3EDE845; Mon, 15 Dec 2014 13:12:31 +0000 X-Env-Sender: magnus.skjegstad@cl.cam.ac.uk X-Msg-Ref: server-6.tower-31.messagelabs.com!1418649149!9002104!1 X-Originating-IP: [66.111.4.224] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17181 invoked from network); 15 Dec 2014 13:12:31 -0000 Received: from new2-smtp.messagingengine.com (HELO new2-smtp.messagingengine.com) (66.111.4.224) by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2014 13:12:31 -0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 6DEE610EE for ; Mon, 15 Dec 2014 08:12:28 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute3.internal (MEProxy); Mon, 15 Dec 2014 08:12:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to:cc :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=5yP0PLq5grHBdY3jdtRs TZwWre8=; b=bKlhzCqyiq9FhPnBTeCaffJY4ZkGmPeWd3EXM8mTIExlz0lebAEo VRPyfMF+SDFQ09B9wdVRk1FoU3fkNW8p5AYjDRBJCMr7GrpO3txBR6AgZDQVwWet Yij5eCvsONZAYMCQXTxhX98bWFUEKyT6Lsu9eVKLv01s69i6UkO1nWg= Received: by web2.nyi.internal (Postfix, from userid 99) id 0302E540619; Mon, 15 Dec 2014 08:12:27 -0500 (EST) Message-Id: <1418649147.1525.203023773.6B08B44B@webmail.messagingengine.com> X-Sasl-Enc: Iqvp1K/58ONwY70yF0MUsYCPZ34RkB73v+hdcRwi6Si0 1418649147 From: Magnus Skjegstad To: Anil Madhavapeddy , Martin Lucina MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface - ajax-54d79604 Date: Mon, 15 Dec 2014 13:12:27 +0000 In-Reply-To: <4F4FD346-E883-4D3D-B5D1-A57EE5769D6E@recoil.org> References: <20141204143631.GE11192@dezo.moloch.sk> <20141215111018.GC27080@nodbug.moloch.sk> <4F4FD346-E883-4D3D-B5D1-A57EE5769D6E@recoil.org> X-Mailman-Approved-At: Mon, 15 Dec 2014 13:13:41 +0000 Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On Mon, 15 Dec 2014, at 11:56, Anil Madhavapeddy wrote: > On 15 Dec 2014, at 03:10, Martin Lucina wrote: > > > > Hi Anil, > > > > anil@recoil.org said: > >> There were a sequence of slow bits in xl that we progressively fixed. > >> Most of these should be winding their way upstream as they get cleaned up. > >> Improvements came from: > >> > >> 1) Replace hotplug script with minimal version (currently a shell script) > >> 2) Replace hotplug script with inline ioctl() gave even better results > >> as no forking happened at all. > >> 3) Parallelise hotplug with domain build. > >> 4) Don't block on primary console > >> 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. > >> > >> Number 3) is fairly invasive to libxl, and the XenstoreNG is still being > >> prepared for release, but the minimal ioctl is pretty easy and could be the > >> default. > > > > Right, 1) and 2) matches what we found with Ian J. while quickly looking at > > low-hanging fruit to optimize at the hack day after the conference. > > > > Is there a version of xen.git with these patches that I can build and use > > to test? I'd like to try spinning up large numbers of rump kernel based > > domUs which is impractical with current domain creation times. > > I'm travelling at the moment, but I can dig out the C file I wrote for > the 2) case when I'm back next weekend. Jon, Dave, do you have the > working > tree for your XL patches available anywhere? This should be the C code we used for 2): https://github.com/MagnusS/jitsu/blob/master/add_vif.c > > > > > One thing not on your list is qemu spinup time; I presume this is because > > you are not using blkfront? The default backend for blkfront is qtap which > > unfortunately relies on qemu; vanilla Linux dom0 kernels don't appear to > > support any other backends (eg. blktap). > > > > We do use blkfront, but not the qemu blkback (which I've never understood > to be honest -- why introduce qemu into the driver equation unless it's > absolutely necessary?). Xen-arm-builder has the blktap patches: > https://github.com/mirage/xen-arm-builder/blob/master/patches/linux-0001-blktap2-fixups.xs.patch > > Anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel Magnus _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 13:13:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 13:13:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0VT4-0004DJ-FY; Mon, 15 Dec 2014 13:13:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0VRw-0004Cr-Nk for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 13:12:32 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id C8/0D-26858-F3EDE845; Mon, 15 Dec 2014 13:12:31 +0000 X-Env-Sender: magnus.skjegstad@cl.cam.ac.uk X-Msg-Ref: server-6.tower-31.messagelabs.com!1418649149!9002104!1 X-Originating-IP: [66.111.4.224] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17181 invoked from network); 15 Dec 2014 13:12:31 -0000 Received: from new2-smtp.messagingengine.com (HELO new2-smtp.messagingengine.com) (66.111.4.224) by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2014 13:12:31 -0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 6DEE610EE for ; Mon, 15 Dec 2014 08:12:28 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute3.internal (MEProxy); Mon, 15 Dec 2014 08:12:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to:cc :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=5yP0PLq5grHBdY3jdtRs TZwWre8=; b=bKlhzCqyiq9FhPnBTeCaffJY4ZkGmPeWd3EXM8mTIExlz0lebAEo VRPyfMF+SDFQ09B9wdVRk1FoU3fkNW8p5AYjDRBJCMr7GrpO3txBR6AgZDQVwWet Yij5eCvsONZAYMCQXTxhX98bWFUEKyT6Lsu9eVKLv01s69i6UkO1nWg= Received: by web2.nyi.internal (Postfix, from userid 99) id 0302E540619; Mon, 15 Dec 2014 08:12:27 -0500 (EST) Message-Id: <1418649147.1525.203023773.6B08B44B@webmail.messagingengine.com> X-Sasl-Enc: Iqvp1K/58ONwY70yF0MUsYCPZ34RkB73v+hdcRwi6Si0 1418649147 From: Magnus Skjegstad To: Anil Madhavapeddy , Martin Lucina MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface - ajax-54d79604 Date: Mon, 15 Dec 2014 13:12:27 +0000 In-Reply-To: <4F4FD346-E883-4D3D-B5D1-A57EE5769D6E@recoil.org> References: <20141204143631.GE11192@dezo.moloch.sk> <20141215111018.GC27080@nodbug.moloch.sk> <4F4FD346-E883-4D3D-B5D1-A57EE5769D6E@recoil.org> X-Mailman-Approved-At: Mon, 15 Dec 2014 13:13:41 +0000 Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Domain creation/boot times and Xen toolstack X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On Mon, 15 Dec 2014, at 11:56, Anil Madhavapeddy wrote: > On 15 Dec 2014, at 03:10, Martin Lucina wrote: > > > > Hi Anil, > > > > anil@recoil.org said: > >> There were a sequence of slow bits in xl that we progressively fixed. > >> Most of these should be winding their way upstream as they get cleaned up. > >> Improvements came from: > >> > >> 1) Replace hotplug script with minimal version (currently a shell script) > >> 2) Replace hotplug script with inline ioctl() gave even better results > >> as no forking happened at all. > >> 3) Parallelise hotplug with domain build. > >> 4) Don't block on primary console > >> 5) Use Dave's XenStore+Irmin with reduced transaction conflicts. > >> > >> Number 3) is fairly invasive to libxl, and the XenstoreNG is still being > >> prepared for release, but the minimal ioctl is pretty easy and could be the > >> default. > > > > Right, 1) and 2) matches what we found with Ian J. while quickly looking at > > low-hanging fruit to optimize at the hack day after the conference. > > > > Is there a version of xen.git with these patches that I can build and use > > to test? I'd like to try spinning up large numbers of rump kernel based > > domUs which is impractical with current domain creation times. > > I'm travelling at the moment, but I can dig out the C file I wrote for > the 2) case when I'm back next weekend. Jon, Dave, do you have the > working > tree for your XL patches available anywhere? This should be the C code we used for 2): https://github.com/MagnusS/jitsu/blob/master/add_vif.c > > > > > One thing not on your list is qemu spinup time; I presume this is because > > you are not using blkfront? The default backend for blkfront is qtap which > > unfortunately relies on qemu; vanilla Linux dom0 kernels don't appear to > > support any other backends (eg. blktap). > > > > We do use blkfront, but not the qemu blkback (which I've never understood > to be honest -- why introduce qemu into the driver equation unless it's > absolutely necessary?). Xen-arm-builder has the blktap patches: > https://github.com/mirage/xen-arm-builder/blob/master/patches/linux-0001-blktap2-fixups.xs.patch > > Anil > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel Magnus _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 19:33:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 19:33:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bOj-00010Y-Dv; Mon, 15 Dec 2014 19:33:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bOh-000101-Js; Mon, 15 Dec 2014 19:33:35 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id 7F/E4-17735-E873F845; Mon, 15 Dec 2014 19:33:34 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1418672013!11089956!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20996 invoked from network); 15 Dec 2014 19:33:34 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 19:33:34 -0000 Received: by mail-lb0-f172.google.com with SMTP id u10so9828915lbd.3 for ; Mon, 15 Dec 2014 11:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7JCCyf6D6ODSy4vnOa90gWOm+uFIx/9shetJ8P46w/w=; b=0lPeIKL1KavE5vlhlt0ZK3siMWqX/67GZ8psLRisgiAHyEOjPthGVoQwtRJKht0HyI i3lmi75MXlnJ7j7x/ZI4IpVa+Gm53icpQib0WbAhjw5+CHh9kIQ4uT/n8X91UxvbHYZp Z6TbOPE53maVPP4fhIRDF+oBw3FShl0MKpJ86fJavhwh7a+gSzUGjP/LT9AVyXY39QHp k0f9Dqzpjtr1bNmuAXW0gEDKe6KIHyaa5LqJSYll4Bh/8JCH3OO0YdeiekJNSjmw+1dG VT1ukNLUvL/AJVYb0ZDxMfFSRQ+K4nAesRFCHadpVMj1ekQxX7CboxLzNV80nsqj+mb+ z7CA== MIME-Version: 1.0 X-Received: by 10.152.22.199 with SMTP id g7mr32128361laf.23.1418672013522; Mon, 15 Dec 2014 11:33:33 -0800 (PST) Received: by 10.112.0.104 with HTTP; Mon, 15 Dec 2014 11:33:33 -0800 (PST) Date: Mon, 15 Dec 2014 14:33:33 -0500 X-Google-Sender-Auth: yMPoFFj8CUUqcuCLhNWJRWHDkNI Message-ID: From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-announce@lists.xenproject.org, xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, xen-api@lists.xen.org Subject: [MirageOS-devel] Xen Project 4.5 RC4 is Ready Today; Test Day is Wednesday X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Folks, This Wednesday, December 17, is our fourth and FINAL Test Day for the 4.5 release cycle (barring any changes which may result from Wednesday's Test Day). Release Candidate 4 is available for assessment today. If you've held off testing the new release until it matures, delay no longer! Test and state your concerns now or the next release you see could be the official one Information about testing this release can be found here: http://wiki.xenproject.org/wiki/Xen_4.5_RC4_test_instructions To learn more about Test Days, including the scheduled date for the final release, check out: http://wiki.xenproject.org/wiki/Xen_Project_Test_Days See you in #xentest on IRC this Wednesday for Test Day! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 19:33:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 19:33:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bOj-00010Y-Dv; Mon, 15 Dec 2014 19:33:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bOh-000101-Js; Mon, 15 Dec 2014 19:33:35 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id 7F/E4-17735-E873F845; Mon, 15 Dec 2014 19:33:34 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1418672013!11089956!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20996 invoked from network); 15 Dec 2014 19:33:34 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 19:33:34 -0000 Received: by mail-lb0-f172.google.com with SMTP id u10so9828915lbd.3 for ; Mon, 15 Dec 2014 11:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7JCCyf6D6ODSy4vnOa90gWOm+uFIx/9shetJ8P46w/w=; b=0lPeIKL1KavE5vlhlt0ZK3siMWqX/67GZ8psLRisgiAHyEOjPthGVoQwtRJKht0HyI i3lmi75MXlnJ7j7x/ZI4IpVa+Gm53icpQib0WbAhjw5+CHh9kIQ4uT/n8X91UxvbHYZp Z6TbOPE53maVPP4fhIRDF+oBw3FShl0MKpJ86fJavhwh7a+gSzUGjP/LT9AVyXY39QHp k0f9Dqzpjtr1bNmuAXW0gEDKe6KIHyaa5LqJSYll4Bh/8JCH3OO0YdeiekJNSjmw+1dG VT1ukNLUvL/AJVYb0ZDxMfFSRQ+K4nAesRFCHadpVMj1ekQxX7CboxLzNV80nsqj+mb+ z7CA== MIME-Version: 1.0 X-Received: by 10.152.22.199 with SMTP id g7mr32128361laf.23.1418672013522; Mon, 15 Dec 2014 11:33:33 -0800 (PST) Received: by 10.112.0.104 with HTTP; Mon, 15 Dec 2014 11:33:33 -0800 (PST) Date: Mon, 15 Dec 2014 14:33:33 -0500 X-Google-Sender-Auth: yMPoFFj8CUUqcuCLhNWJRWHDkNI Message-ID: From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-announce@lists.xenproject.org, xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, xen-api@lists.xen.org Subject: [MirageOS-devel] Xen Project 4.5 RC4 is Ready Today; Test Day is Wednesday X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Folks, This Wednesday, December 17, is our fourth and FINAL Test Day for the 4.5 release cycle (barring any changes which may result from Wednesday's Test Day). Release Candidate 4 is available for assessment today. If you've held off testing the new release until it matures, delay no longer! Test and state your concerns now or the next release you see could be the official one Information about testing this release can be found here: http://wiki.xenproject.org/wiki/Xen_4.5_RC4_test_instructions To learn more about Test Days, including the scheduled date for the final release, check out: http://wiki.xenproject.org/wiki/Xen_Project_Test_Days See you in #xentest on IRC this Wednesday for Test Day! _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 19:42:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 19:42:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bXV-0001d0-7D; Mon, 15 Dec 2014 19:42:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bXT-0001co-Gy for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 19:42:39 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 67/16-26858-EA93F845; Mon, 15 Dec 2014 19:42:38 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1418672557!9097670!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26257 invoked from network); 15 Dec 2014 19:42:37 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 19:42:37 -0000 Received: by mail-wg0-f48.google.com with SMTP id y19so15571805wgg.35 for ; Mon, 15 Dec 2014 11:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+RDlA3Vb8PiMFpEHCnJqagbnv5nq3RI6lBb2aNpYiFA=; b=J1sVPWHrDLXwyM6EsTSCiXe/e43BFHTFr9Juv37rZGZbRla6Kuv9tyvHGdQj3Yh/wh XjrTiMkjpEzCcMvK/WRZZrylMdun2b9dyIq78uqfDaHbbP7/jjqxKy0Lul/lDsl6O3X7 GMJ+JI9FKPTzeAPB5PYqXHzlCFfVHbSU+ul25jP1yafoUg/3Lb3kSxmBLljAtPL4VwUd bY6rbbOMvp2MPk+IvMtS54BhV240c8Fb2mSxTEkG2GiQFjgN8tOUo4EZtMM/gm+aECMH FC8vTac/I1NLkX212JqKmizGDpWIrP3Bs1WFpX4GVzPeAEe4E9jJ5ak+Bn7j8NdctsPR Spyw== X-Received: by 10.194.80.68 with SMTP id p4mr18936904wjx.108.1418672556818; Mon, 15 Dec 2014 11:42:36 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id p5sm14297763wix.7.2014.12.15.11.42.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 11:42:35 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> Date: Mon, 15 Dec 2014 19:42:33 +0000 Message-Id: References: <69D665AD-E191-40B2-8E41-0111697C2E7F@gazagnaire.org> <307C9C1D-71DC-4040-BFBD-E935201F9CAB@gazagnaire.org> <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> To: mirageos-devel X-Mailer: Apple Mail (2.1993) Subject: Re: [MirageOS-devel] Irmin roadmap X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, after 3 months of refactoring (!), 11,5k lines added and 8,8k lines removed, I am very happy to announce that I've merged my working patches into the master branch of Irmin. I'll pass the remaining of the week fixing the last quirks (mainly documentation related, but also around the command-line tool usability) before announcing the 0.9.0 release. One of the main change is the new public API with a proper documentation: http://samoht.github.io/irmin/ (although it needs more code examples[1]) Summary of the changes: * Expose a cleaner public API * Expose a cleaner API for the Unix backends * Expose a high-level REST API over HTTP (#80) * Rename `Origin` into `Task` and use it pervasively through the API * Add `remove_rec` to remove directories (#74, #85) * More efficient synchronization protocol between Irmin stores (#11) * Improve the efficiency of the Git backend * Remove dependency to `core_kernel` (#22, #81) * Remove dependency to `cryptokit` and `ocaml-sha` and use `nocrypto` instead * Fix writing contents at the root of the store (#73) * Fix the Git backend to stop constantly overwrite `.git/HEAD` (#76) * Add a limit on concurrently open files (#93, #75) As usual, feedback is welcome. The initial goal for the 1.0.0 release was to integrate Mirage and Irmin properly. That goal is very close now. What is missing: - Support the Git synchronisation protocol in Mirage. This means implementing Git.Sync.IO [2] - Add the right combinators in the mirage eDSL And that should be it. Best, Thomas [1] https://github.com/mirage/irmin/issues/99 [2] https://github.com/mirage/ocaml-git/blob/master/lib/sync.mli#L67 > On 21 Nov 2014, at 16:18, Thomas Gazagnaire wrote: > > Hi, > > I've spent the last week working on the new version of Irmin. This is still not finished but it is making good progress. A preliminary ocamldoc page is available online[1]. It is not complete and polished yet, but most parts are documented. > > The main changes are: > > - Improve compile time and portability: no more core_kernel and camlp4, now use nocrypto and mirage-tc > > - No more -pack. All the internal modules are prefixed by Ir_ and are not available to the users (the cmi are not installed) and the public module (with the public documentation) is Irmin > > - All the operations in a store now take a **mandatory** `origin` argument, even the read operation [2] (before, only the merge operations where requiring it). The origin contains the process/user name, the date, some (maybe structured) message, ... (this can be configured by the user). That origin value comes from the high-level call ("I want to add that value to my Irmin store") and are passed through all the low-level calls ("I need to create a new block in the block store, I need to update the head tag to point to the new head, etc) so you can very easily track every read and write operations in your store. My hope is that we can use that origin value to control the store encryption: you can store some keys in the origin and use them to encrypt on write and decrypt on read. Need more though on that, but I think we have everything needed now. > > - The high-level "branch-consistant" signature is simpler [3]. The internals of the contents, node, commit and tag stores are not exposed anymore. > > - The synchronisation functions are much more efficient and looks quite similar to what Git does, although we don't compress the data (yet) (but the slice[4] type is abstract, so we could do that later if needed, this involves tweaking [5]). > > What needs to be done: porting the backends, the http server and checking that everything still works fine. Hopefully this will be done early next week. > > Best, > Thomas > > [1]: http://samoht.github.io/irmin/ > [2]: http://samoht.github.io/irmin/Irmin.Store.RO.html > [3]: http://samoht.github.io/irmin/Irmin.Store.BC.html > [4]: http://samoht.github.io/irmin/Irmin.Store.BC.html#TYPEslice > [5]: https://github.com/samoht/irmin/blob/ab20999e43a9aa4a3bdb1733a55288080ff2c565/lib/ir_bc.ml#L488 > >> On 1 Oct 2014, at 21:38, Thomas Gazagnaire wrote: >> >> I'm very late on all of these points (although I almost have 1/ done, needs more polishing) but I've generated some docs which might be useful to people starting using the library: >> >> http://samoht.github.io/irmin/ >> >> Thomas >> >> On 9 Sep 2014, at 16:57, Thomas Gazagnaire wrote: >> >>> Hi all, >>> >>> Lots of people starting asked me about the status of Irmin. As you might have notice, I'vent had much time to spend on Irmin last month, but I plan to fix that. My current priorities are: >>> >>> 1/ make Irmin compiles on the Xen backend of Mirage. https://github.com/mirage/irmin/issues/81 >>> This means dropping the dependency to core_kernel (for now on). The external API will not change. >>> >>> 2/ improve the high-level JSON API. This is related to https://github.com/mirage/irmin/issues/80 >>> Currently, we only have a JSON API for the low-level stores, and the very partial implementation of the higher-level calls. Needs to complete and document that. >>> >>> 3/ implement a pure-ocaml Git server to be able to at least `git pull` from it. https://github.com/mirage/ocaml-git/issues/15 >>> Together with 1/ this will make possible to query the state of a running Mirage unikernel with a simple `git pull ` >>> >>> 4/ implement a simple distributed log server .https://github.com/mirage/irmin/issues/82 >>> Could use Benjamin's rope implementation, that I first need to release properly. >>> >>> 5/ try to come up with a solution to the "unlimited" memory/storage usage issues https://github.com/mirage/irmin/issues/83 >>> This is the most uncertain part of the short-term roadmap. I'll need to check again what are the limitation of Git shallow copies and see how we can use them to limit the history size to remember. >>> >>> There are also few open embarrassing bugs that I want to fix as well (regarding fd leaks ...). >>> >>> If anyone is interested to help me on any of these topics, please feel free to comment on the related issues on Github -- I'll gladly share the workload. Also, feel free to reply to that email if you think there is any important Imrin features that you think are missing now. >>> >>> Best, >>> Thomas >> > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 19:42:47 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 19:42:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bXV-0001d0-7D; Mon, 15 Dec 2014 19:42:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0bXT-0001co-Gy for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 19:42:39 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 67/16-26858-EA93F845; Mon, 15 Dec 2014 19:42:38 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1418672557!9097670!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26257 invoked from network); 15 Dec 2014 19:42:37 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 Dec 2014 19:42:37 -0000 Received: by mail-wg0-f48.google.com with SMTP id y19so15571805wgg.35 for ; Mon, 15 Dec 2014 11:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+RDlA3Vb8PiMFpEHCnJqagbnv5nq3RI6lBb2aNpYiFA=; b=J1sVPWHrDLXwyM6EsTSCiXe/e43BFHTFr9Juv37rZGZbRla6Kuv9tyvHGdQj3Yh/wh XjrTiMkjpEzCcMvK/WRZZrylMdun2b9dyIq78uqfDaHbbP7/jjqxKy0Lul/lDsl6O3X7 GMJ+JI9FKPTzeAPB5PYqXHzlCFfVHbSU+ul25jP1yafoUg/3Lb3kSxmBLljAtPL4VwUd bY6rbbOMvp2MPk+IvMtS54BhV240c8Fb2mSxTEkG2GiQFjgN8tOUo4EZtMM/gm+aECMH FC8vTac/I1NLkX212JqKmizGDpWIrP3Bs1WFpX4GVzPeAEe4E9jJ5ak+Bn7j8NdctsPR Spyw== X-Received: by 10.194.80.68 with SMTP id p4mr18936904wjx.108.1418672556818; Mon, 15 Dec 2014 11:42:36 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id p5sm14297763wix.7.2014.12.15.11.42.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 11:42:35 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> Date: Mon, 15 Dec 2014 19:42:33 +0000 Message-Id: References: <69D665AD-E191-40B2-8E41-0111697C2E7F@gazagnaire.org> <307C9C1D-71DC-4040-BFBD-E935201F9CAB@gazagnaire.org> <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> To: mirageos-devel X-Mailer: Apple Mail (2.1993) Subject: Re: [MirageOS-devel] Irmin roadmap X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi all, after 3 months of refactoring (!), 11,5k lines added and 8,8k lines removed, I am very happy to announce that I've merged my working patches into the master branch of Irmin. I'll pass the remaining of the week fixing the last quirks (mainly documentation related, but also around the command-line tool usability) before announcing the 0.9.0 release. One of the main change is the new public API with a proper documentation: http://samoht.github.io/irmin/ (although it needs more code examples[1]) Summary of the changes: * Expose a cleaner public API * Expose a cleaner API for the Unix backends * Expose a high-level REST API over HTTP (#80) * Rename `Origin` into `Task` and use it pervasively through the API * Add `remove_rec` to remove directories (#74, #85) * More efficient synchronization protocol between Irmin stores (#11) * Improve the efficiency of the Git backend * Remove dependency to `core_kernel` (#22, #81) * Remove dependency to `cryptokit` and `ocaml-sha` and use `nocrypto` instead * Fix writing contents at the root of the store (#73) * Fix the Git backend to stop constantly overwrite `.git/HEAD` (#76) * Add a limit on concurrently open files (#93, #75) As usual, feedback is welcome. The initial goal for the 1.0.0 release was to integrate Mirage and Irmin properly. That goal is very close now. What is missing: - Support the Git synchronisation protocol in Mirage. This means implementing Git.Sync.IO [2] - Add the right combinators in the mirage eDSL And that should be it. Best, Thomas [1] https://github.com/mirage/irmin/issues/99 [2] https://github.com/mirage/ocaml-git/blob/master/lib/sync.mli#L67 > On 21 Nov 2014, at 16:18, Thomas Gazagnaire wrote: > > Hi, > > I've spent the last week working on the new version of Irmin. This is still not finished but it is making good progress. A preliminary ocamldoc page is available online[1]. It is not complete and polished yet, but most parts are documented. > > The main changes are: > > - Improve compile time and portability: no more core_kernel and camlp4, now use nocrypto and mirage-tc > > - No more -pack. All the internal modules are prefixed by Ir_ and are not available to the users (the cmi are not installed) and the public module (with the public documentation) is Irmin > > - All the operations in a store now take a **mandatory** `origin` argument, even the read operation [2] (before, only the merge operations where requiring it). The origin contains the process/user name, the date, some (maybe structured) message, ... (this can be configured by the user). That origin value comes from the high-level call ("I want to add that value to my Irmin store") and are passed through all the low-level calls ("I need to create a new block in the block store, I need to update the head tag to point to the new head, etc) so you can very easily track every read and write operations in your store. My hope is that we can use that origin value to control the store encryption: you can store some keys in the origin and use them to encrypt on write and decrypt on read. Need more though on that, but I think we have everything needed now. > > - The high-level "branch-consistant" signature is simpler [3]. The internals of the contents, node, commit and tag stores are not exposed anymore. > > - The synchronisation functions are much more efficient and looks quite similar to what Git does, although we don't compress the data (yet) (but the slice[4] type is abstract, so we could do that later if needed, this involves tweaking [5]). > > What needs to be done: porting the backends, the http server and checking that everything still works fine. Hopefully this will be done early next week. > > Best, > Thomas > > [1]: http://samoht.github.io/irmin/ > [2]: http://samoht.github.io/irmin/Irmin.Store.RO.html > [3]: http://samoht.github.io/irmin/Irmin.Store.BC.html > [4]: http://samoht.github.io/irmin/Irmin.Store.BC.html#TYPEslice > [5]: https://github.com/samoht/irmin/blob/ab20999e43a9aa4a3bdb1733a55288080ff2c565/lib/ir_bc.ml#L488 > >> On 1 Oct 2014, at 21:38, Thomas Gazagnaire wrote: >> >> I'm very late on all of these points (although I almost have 1/ done, needs more polishing) but I've generated some docs which might be useful to people starting using the library: >> >> http://samoht.github.io/irmin/ >> >> Thomas >> >> On 9 Sep 2014, at 16:57, Thomas Gazagnaire wrote: >> >>> Hi all, >>> >>> Lots of people starting asked me about the status of Irmin. As you might have notice, I'vent had much time to spend on Irmin last month, but I plan to fix that. My current priorities are: >>> >>> 1/ make Irmin compiles on the Xen backend of Mirage. https://github.com/mirage/irmin/issues/81 >>> This means dropping the dependency to core_kernel (for now on). The external API will not change. >>> >>> 2/ improve the high-level JSON API. This is related to https://github.com/mirage/irmin/issues/80 >>> Currently, we only have a JSON API for the low-level stores, and the very partial implementation of the higher-level calls. Needs to complete and document that. >>> >>> 3/ implement a pure-ocaml Git server to be able to at least `git pull` from it. https://github.com/mirage/ocaml-git/issues/15 >>> Together with 1/ this will make possible to query the state of a running Mirage unikernel with a simple `git pull ` >>> >>> 4/ implement a simple distributed log server .https://github.com/mirage/irmin/issues/82 >>> Could use Benjamin's rope implementation, that I first need to release properly. >>> >>> 5/ try to come up with a solution to the "unlimited" memory/storage usage issues https://github.com/mirage/irmin/issues/83 >>> This is the most uncertain part of the short-term roadmap. I'll need to check again what are the limitation of Git shallow copies and see how we can use them to limit the history size to remember. >>> >>> There are also few open embarrassing bugs that I want to fix as well (regarding fd leaks ...). >>> >>> If anyone is interested to help me on any of these topics, please feel free to comment on the related issues on Github -- I'll gladly share the workload. Also, feel free to reply to that email if you think there is any important Imrin features that you think are missing now. >>> >>> Best, >>> Thomas >> > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 20:41:58 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 20:41:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0cSp-00032g-Lu; Mon, 15 Dec 2014 20:41:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0cSo-00032b-Ix for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 20:41:54 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 11/29-09842-1974F845; Mon, 15 Dec 2014 20:41:53 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-15.tower-21.messagelabs.com!1418676113!15751389!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13660 invoked from network); 15 Dec 2014 20:41:53 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-15.tower-21.messagelabs.com with SMTP; 15 Dec 2014 20:41:53 -0000 Received: from [172.20.10.2] (54-237.197-178.cust.bluewin.ch [178.197.237.54]) by smtp.webfaction.com (Postfix) with ESMTP id 8CE722078FEB; Mon, 15 Dec 2014 20:41:50 +0000 (UTC) Date: Mon, 15 Dec 2014 21:41:42 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Gazagnaire Message-ID: In-Reply-To: References: <69D665AD-E191-40B2-8E41-0111697C2E7F@gazagnaire.org> <307C9C1D-71DC-4040-BFBD-E935201F9CAB@gazagnaire.org> <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] Irmin roadmap X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbHVuZGksIDE1IGTDqWNlbWJyZSAyMDE0IMOgIDIwOjQyLCBUaG9tYXMgR2F6YWduYWlyZSBh IMOpY3JpdCA6Cj4gQXMgdXN1YWwsIGZlZWRiYWNrIGlzIHdlbGNvbWUuCgpDb25ncmF0dWxhdGlv bnMgb24gdGhlIEFQSSBkb2N1bWVudGF0aW9uIGVmZm9ydCAhIE1ha2VzIHlvdSB3YW50IHRvIHVz ZSBpdC4KCkJ0dy4gSSBxdWl0ZSBsaWtlZCB0aGF0IHR5cG8gWzFdOgoKIklybWluIHByb3ZpZGVz IHRoZSBmb2xsb3dbaW5nXSAqZ2luKiBmZWF0dXJlczogWy4uLl0iCgpQZXJzb25hbGx5IGdpbiBt YWtlcyBteSBzeW5jaHJvbml6YXRpb24gcHJpbWl0aXZlcyBzbG93ZXLigKYKCkJlc3QsCgpEYW5p ZWwKClsxXSBodHRwOi8vc2Ftb2h0LmdpdGh1Yi5pby9pcm1pbi9Jcm1pbi5odG1sIzFfSGlnaGxl dmVsU3RvcmVzCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Mon Dec 15 20:41:58 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 15 Dec 2014 20:41:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0cSp-00032g-Lu; Mon, 15 Dec 2014 20:41:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0cSo-00032b-Ix for mirageos-devel@lists.xenproject.org; Mon, 15 Dec 2014 20:41:54 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 11/29-09842-1974F845; Mon, 15 Dec 2014 20:41:53 +0000 X-Env-Sender: daniel.buenzli@erratique.ch X-Msg-Ref: server-15.tower-21.messagelabs.com!1418676113!15751389!1 X-Originating-IP: [74.55.86.74] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzQuNTUuODYuNzQgPT4gMzA4NTYz\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13660 invoked from network); 15 Dec 2014 20:41:53 -0000 Received: from mail6.webfaction.com (HELO smtp.webfaction.com) (74.55.86.74) by server-15.tower-21.messagelabs.com with SMTP; 15 Dec 2014 20:41:53 -0000 Received: from [172.20.10.2] (54-237.197-178.cust.bluewin.ch [178.197.237.54]) by smtp.webfaction.com (Postfix) with ESMTP id 8CE722078FEB; Mon, 15 Dec 2014 20:41:50 +0000 (UTC) Date: Mon, 15 Dec 2014 21:41:42 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Thomas Gazagnaire Message-ID: In-Reply-To: References: <69D665AD-E191-40B2-8E41-0111697C2E7F@gazagnaire.org> <307C9C1D-71DC-4040-BFBD-E935201F9CAB@gazagnaire.org> <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Disposition: inline Cc: mirageos-devel Subject: Re: [MirageOS-devel] Irmin roadmap X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org TGUgbHVuZGksIDE1IGTDqWNlbWJyZSAyMDE0IMOgIDIwOjQyLCBUaG9tYXMgR2F6YWduYWlyZSBh IMOpY3JpdCA6Cj4gQXMgdXN1YWwsIGZlZWRiYWNrIGlzIHdlbGNvbWUuCgpDb25ncmF0dWxhdGlv bnMgb24gdGhlIEFQSSBkb2N1bWVudGF0aW9uIGVmZm9ydCAhIE1ha2VzIHlvdSB3YW50IHRvIHVz ZSBpdC4KCkJ0dy4gSSBxdWl0ZSBsaWtlZCB0aGF0IHR5cG8gWzFdOgoKIklybWluIHByb3ZpZGVz IHRoZSBmb2xsb3dbaW5nXSAqZ2luKiBmZWF0dXJlczogWy4uLl0iCgpQZXJzb25hbGx5IGdpbiBt YWtlcyBteSBzeW5jaHJvbml6YXRpb24gcHJpbWl0aXZlcyBzbG93ZXLigKYKCkJlc3QsCgpEYW5p ZWwKClsxXSBodHRwOi8vc2Ftb2h0LmdpdGh1Yi5pby9pcm1pbi9Jcm1pbi5odG1sIzFfSGlnaGxl dmVsU3RvcmVzCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 10:15:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 10:15:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0p9l-0001jh-Jr; Tue, 16 Dec 2014 10:15:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0opC-0000wd-NA for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 09:53:50 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 74/3B-24124-E2100945; Tue, 16 Dec 2014 09:53:50 +0000 X-Env-Sender: david.allsopp@metastack.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1418723629!9447229!1 X-Originating-IP: [62.13.148.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24538 invoked from network); 16 Dec 2014 09:53:49 -0000 Received: from outmail148101.authsmtp.com (HELO outmail148101.authsmtp.com) (62.13.148.101) by server-11.tower-206.messagelabs.com with SMTP; 16 Dec 2014 09:53:49 -0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBG9rmAK053904; Tue, 16 Dec 2014 09:53:48 GMT Received: from romulus.metastack.com (cpc1-cmbg5-0-0-cust241.5-4.cable.virginm.net [81.98.252.242]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBG9rk8J055634; Tue, 16 Dec 2014 09:53:46 GMT Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id sBG9rjTF006563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 09:53:45 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 09:53:45 +0000 From: David Allsopp To: "opam-devel@lists.ocaml.org" , mirageos-devel Thread-Topic: [opam-devel] [MirageOS-devel] opam 1.1.1 and aspcud 1.9 Thread-Index: AQHQFiD0RjFt3vNfDUyH6UFsbwoCn5yMuuWAgAVCL5A= Date: Tue, 16 Dec 2014 09:53:45 +0000 Message-ID: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <20141211135600.GA30089@traveler> <3900186.VCNjxAKEzz@agaric> In-Reply-To: <3900186.VCNjxAKEzz@agaric> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.18] MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 6da5e23d-8509-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZRRob BmUNCCtbTh09DhhB HRYYMQJRIxwCUgFH N1teMltLNFBcHxBP AmAULwEHT19xWGdl awNbaAZXZkwAVwR0 WUBXQFdQCgdsAwMD AwEeHFoAAAwEI3YK ZUNnWHNfEkJ6cE4z RBoFEDgEZjN9YGUf WV1ZdlZQbQoceRtY alB9UXoNMGQEYy5j CTUebXgCOi1WLWFZ Tx8AKWdacmMKBDcz Sjc5WDkiA0ABcm17 KAQvLxZFWh9Xaw07 N1dpUEkAOAIeQlQY TikA X-Authentic-SMTP: 61633634383431.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.98.252.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Mailman-Approved-At: Tue, 16 Dec 2014 10:15:04 +0000 Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Louis Gesbert wrote: > For this specific bug,running "make tests" would have been enough > (I just tested on my VM). For being defensive and having ./configure > refuse newer version of dependencies, the m4 macros don't seem to > provide version filtering (only API testing. Here the API was > compatible, anyway that would have failed at build-time). Does > ocamlfind even provide an easy way to get the version of a package? Version filtering isn't what I meant, though - I meant semantic filtering, i.e. a relevant test case which fails for this "broken" version but works in the older versions (or corrected newer versions). IMO, version filtering is something packagers do with package meta-data; developers should use version filtering only because of API changes which isn't applicable here. > But my feeling is that what happened really shouldn't happen -- I > mean, a small, but API compatible change, that would cause the older > version to break _but not the newer version, just by chance_, so > that it could get unnoticed ? What are the odds of this happening > _again_ ? ;) Again, in my opinion, "once bitten, twice shy". My own personal experience is that if something like this has happened it is *very* likely it will happen again (and that's in no way a negative comment on any developers concerned!) There are plenty of other instances in configure scripts where semantics are tested rather than a version compatibility matrix (usually when probing the C compiler) so I don't think it's too unusual a thing to want to do? David _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 10:15:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 10:15:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0p9l-0001jh-Jr; Tue, 16 Dec 2014 10:15:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0opC-0000wd-NA for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 09:53:50 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 74/3B-24124-E2100945; Tue, 16 Dec 2014 09:53:50 +0000 X-Env-Sender: david.allsopp@metastack.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1418723629!9447229!1 X-Originating-IP: [62.13.148.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24538 invoked from network); 16 Dec 2014 09:53:49 -0000 Received: from outmail148101.authsmtp.com (HELO outmail148101.authsmtp.com) (62.13.148.101) by server-11.tower-206.messagelabs.com with SMTP; 16 Dec 2014 09:53:49 -0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBG9rmAK053904; Tue, 16 Dec 2014 09:53:48 GMT Received: from romulus.metastack.com (cpc1-cmbg5-0-0-cust241.5-4.cable.virginm.net [81.98.252.242]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBG9rk8J055634; Tue, 16 Dec 2014 09:53:46 GMT Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id sBG9rjTF006563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 09:53:45 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 09:53:45 +0000 From: David Allsopp To: "opam-devel@lists.ocaml.org" , mirageos-devel Thread-Topic: [opam-devel] [MirageOS-devel] opam 1.1.1 and aspcud 1.9 Thread-Index: AQHQFiD0RjFt3vNfDUyH6UFsbwoCn5yMuuWAgAVCL5A= Date: Tue, 16 Dec 2014 09:53:45 +0000 Message-ID: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <20141211135600.GA30089@traveler> <3900186.VCNjxAKEzz@agaric> In-Reply-To: <3900186.VCNjxAKEzz@agaric> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.18] MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 6da5e23d-8509-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZRRob BmUNCCtbTh09DhhB HRYYMQJRIxwCUgFH N1teMltLNFBcHxBP AmAULwEHT19xWGdl awNbaAZXZkwAVwR0 WUBXQFdQCgdsAwMD AwEeHFoAAAwEI3YK ZUNnWHNfEkJ6cE4z RBoFEDgEZjN9YGUf WV1ZdlZQbQoceRtY alB9UXoNMGQEYy5j CTUebXgCOi1WLWFZ Tx8AKWdacmMKBDcz Sjc5WDkiA0ABcm17 KAQvLxZFWh9Xaw07 N1dpUEkAOAIeQlQY TikA X-Authentic-SMTP: 61633634383431.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.98.252.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Mailman-Approved-At: Tue, 16 Dec 2014 10:15:04 +0000 Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Louis Gesbert wrote: > For this specific bug,running "make tests" would have been enough > (I just tested on my VM). For being defensive and having ./configure > refuse newer version of dependencies, the m4 macros don't seem to > provide version filtering (only API testing. Here the API was > compatible, anyway that would have failed at build-time). Does > ocamlfind even provide an easy way to get the version of a package? Version filtering isn't what I meant, though - I meant semantic filtering, i.e. a relevant test case which fails for this "broken" version but works in the older versions (or corrected newer versions). IMO, version filtering is something packagers do with package meta-data; developers should use version filtering only because of API changes which isn't applicable here. > But my feeling is that what happened really shouldn't happen -- I > mean, a small, but API compatible change, that would cause the older > version to break _but not the newer version, just by chance_, so > that it could get unnoticed ? What are the odds of this happening > _again_ ? ;) Again, in my opinion, "once bitten, twice shy". My own personal experience is that if something like this has happened it is *very* likely it will happen again (and that's in no way a negative comment on any developers concerned!) There are plenty of other instances in configure scripts where semantics are tested rather than a version compatibility matrix (usually when probing the C compiler) so I don't think it's too unusual a thing to want to do? David _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 14:54:49 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 14:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0tWM-0002hz-Fc; Tue, 16 Dec 2014 14:54:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0tWL-0002hu-71 for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 14:54:41 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id BE/AD-05632-0B740945; Tue, 16 Dec 2014 14:54:40 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1418741679!13788985!1 X-Originating-IP: [209.85.217.177] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11185 invoked from network); 16 Dec 2014 14:54:39 -0000 Received: from mail-lb0-f177.google.com (HELO mail-lb0-f177.google.com) (209.85.217.177) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 16 Dec 2014 14:54:39 -0000 Received: by mail-lb0-f177.google.com with SMTP id b6so10758107lbj.22 for ; Tue, 16 Dec 2014 06:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HqhQ2DhSkAc0opTS8V1NRQwet2pTkYUCMWHrDN+e4ak=; b=NyRVGfIMtiyE6KNXjTzcLY2izx8L9QAN1Y6/9cULPntx0Cc2zEY2XpWFv2D1l45dW3 T1xFGqqmzLOYJefHJ4cWPkIQog8u/CWWcm4594tfT795d95msOnyGB9C5VQI8IynuO0I oT1jD8Z5cUKwxVGZ7P44dfvcJvmy1vz7owTji+70ZndddrS4oHVXUH0fp7EYH5T/broq QTu4HMsOSTD5K9SLzYwVTVUnnESLUz3/+WoMkTERpgqmDHKUB/1vHcvnZI5h/Hgop/pe YqTpZU2jOZcwE+piaXRaSn7AJuTrlhAbHQPnAoFBM4cZ/Lv41eQE5O7qRddAqscE4PFz 9Xvg== MIME-Version: 1.0 X-Received: by 10.112.167.200 with SMTP id zq8mr36252266lbb.61.1418741678726; Tue, 16 Dec 2014 06:54:38 -0800 (PST) Received: by 10.112.48.65 with HTTP; Tue, 16 Dec 2014 06:54:38 -0800 (PST) In-Reply-To: <8C49B405-D4FA-4119-BE70-E798E0876157@recoil.org> References: <8C49B405-D4FA-4119-BE70-E798E0876157@recoil.org> Date: Tue, 16 Dec 2014 08:54:38 -0600 Message-ID: From: Brian Brietzke To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8355151094760235459==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8355151094760235459== Content-Type: multipart/alternative; boundary=001a11c2633ac9e2ea050a568978 --001a11c2633ac9e2ea050a568978 Content-Type: text/plain; charset=UTF-8 I'd be more than happy to share what I discover, but I'm not what you mean by a benchmark. I'm most looking to see how the mirage machine will work third party libraries, what configuration do you need and what kind of patterns work in and around those constructs. I have started with the mir-ping example ( wanted a fixed IP that I could change easily ) and have started working from there. My first trial is aimed at Redis since it's simple to setup, simple to run and easy to clean up after. All of the work is done over the tun/tap network interface running on an OS/X machine. I have been able to connect to the Redis server running on my local machine, and if I get the opportunity today I'll be saving / retrieving values. I'm open to feedback or areas of exploration that others might be interested in or guidance as to better approaches. On Sat, Dec 13, 2014 at 1:55 PM, Anil Madhavapeddy wrote: > > > > On 11 Dec 2014, at 01:53, Brian Brietzke wrote: > > > > There are implementations of the protocols for mysql and postgresql that > > popular. I've done some digging and have found pure ocaml > implementations > > for both redis and mongo. I'll have to do some experimenting and see > > what the results are like. > > It would actually be really useful to have a simple benchmark against > Redis and Mongo to put into mirage-skeleton. We could run it over > both TCP and Vchan as a much more realistic workload than the usual > iperf efforts. > > -anil > --001a11c2633ac9e2ea050a568978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd be more than happy to share what I discover, but I= 'm not what you mean by a benchmark.

I'm most lo= oking to see how the mirage machine will work third party libraries, what c= onfiguration do you need and what kind of patterns work in and around those= constructs.

I have started with the mir-ping exam= ple ( wanted a fixed IP that I could change easily ) and have started worki= ng from there.=C2=A0 My first trial is aimed at Redis since it's simple= to setup, simple to run and easy to clean up after.=C2=A0 All of the work = is done over the tun/tap network interface running on an OS/X machine.

I have been able to connect to the Redis server runnin= g on my local machine, and if I get the opportunity today I'll be savin= g / retrieving values. =C2=A0

I'm open to feed= back or areas of exploration that others might be interested in or guidance= as to better approaches. =C2=A0

=
On Sat, Dec 13, 2014 at 1:55 PM, Anil Madhavaped= dy <anil@recoil.org> wrote:

> On 11 Dec 2014, at 01:53, Brian Brietzke <bbrietzke@gmail.com> wrote:
>
> There are implementations of the protocols for mysql and postgresql th= at
> popular.=C2=A0 I've done some digging and have found pure ocaml im= plementations
> for both redis and mongo.=C2=A0 I'll have to do some experimenting= and see
> what the results are like.

It would actually be really useful to have a simple benchmark agains= t
Redis and Mongo to put into mirage-skeleton.=C2=A0 We could run it over
both TCP and Vchan as a much more realistic workload than the usual
iperf efforts.

-anil
--001a11c2633ac9e2ea050a568978-- --===============8355151094760235459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8355151094760235459==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 14:54:49 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 14:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0tWM-0002hz-Fc; Tue, 16 Dec 2014 14:54:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0tWL-0002hu-71 for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 14:54:41 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id BE/AD-05632-0B740945; Tue, 16 Dec 2014 14:54:40 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1418741679!13788985!1 X-Originating-IP: [209.85.217.177] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11185 invoked from network); 16 Dec 2014 14:54:39 -0000 Received: from mail-lb0-f177.google.com (HELO mail-lb0-f177.google.com) (209.85.217.177) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 16 Dec 2014 14:54:39 -0000 Received: by mail-lb0-f177.google.com with SMTP id b6so10758107lbj.22 for ; Tue, 16 Dec 2014 06:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HqhQ2DhSkAc0opTS8V1NRQwet2pTkYUCMWHrDN+e4ak=; b=NyRVGfIMtiyE6KNXjTzcLY2izx8L9QAN1Y6/9cULPntx0Cc2zEY2XpWFv2D1l45dW3 T1xFGqqmzLOYJefHJ4cWPkIQog8u/CWWcm4594tfT795d95msOnyGB9C5VQI8IynuO0I oT1jD8Z5cUKwxVGZ7P44dfvcJvmy1vz7owTji+70ZndddrS4oHVXUH0fp7EYH5T/broq QTu4HMsOSTD5K9SLzYwVTVUnnESLUz3/+WoMkTERpgqmDHKUB/1vHcvnZI5h/Hgop/pe YqTpZU2jOZcwE+piaXRaSn7AJuTrlhAbHQPnAoFBM4cZ/Lv41eQE5O7qRddAqscE4PFz 9Xvg== MIME-Version: 1.0 X-Received: by 10.112.167.200 with SMTP id zq8mr36252266lbb.61.1418741678726; Tue, 16 Dec 2014 06:54:38 -0800 (PST) Received: by 10.112.48.65 with HTTP; Tue, 16 Dec 2014 06:54:38 -0800 (PST) In-Reply-To: <8C49B405-D4FA-4119-BE70-E798E0876157@recoil.org> References: <8C49B405-D4FA-4119-BE70-E798E0876157@recoil.org> Date: Tue, 16 Dec 2014 08:54:38 -0600 Message-ID: From: Brian Brietzke To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Mirage and External Data Storage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8355151094760235459==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8355151094760235459== Content-Type: multipart/alternative; boundary=001a11c2633ac9e2ea050a568978 --001a11c2633ac9e2ea050a568978 Content-Type: text/plain; charset=UTF-8 I'd be more than happy to share what I discover, but I'm not what you mean by a benchmark. I'm most looking to see how the mirage machine will work third party libraries, what configuration do you need and what kind of patterns work in and around those constructs. I have started with the mir-ping example ( wanted a fixed IP that I could change easily ) and have started working from there. My first trial is aimed at Redis since it's simple to setup, simple to run and easy to clean up after. All of the work is done over the tun/tap network interface running on an OS/X machine. I have been able to connect to the Redis server running on my local machine, and if I get the opportunity today I'll be saving / retrieving values. I'm open to feedback or areas of exploration that others might be interested in or guidance as to better approaches. On Sat, Dec 13, 2014 at 1:55 PM, Anil Madhavapeddy wrote: > > > > On 11 Dec 2014, at 01:53, Brian Brietzke wrote: > > > > There are implementations of the protocols for mysql and postgresql that > > popular. I've done some digging and have found pure ocaml > implementations > > for both redis and mongo. I'll have to do some experimenting and see > > what the results are like. > > It would actually be really useful to have a simple benchmark against > Redis and Mongo to put into mirage-skeleton. We could run it over > both TCP and Vchan as a much more realistic workload than the usual > iperf efforts. > > -anil > --001a11c2633ac9e2ea050a568978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd be more than happy to share what I discover, but I= 'm not what you mean by a benchmark.

I'm most lo= oking to see how the mirage machine will work third party libraries, what c= onfiguration do you need and what kind of patterns work in and around those= constructs.

I have started with the mir-ping exam= ple ( wanted a fixed IP that I could change easily ) and have started worki= ng from there.=C2=A0 My first trial is aimed at Redis since it's simple= to setup, simple to run and easy to clean up after.=C2=A0 All of the work = is done over the tun/tap network interface running on an OS/X machine.

I have been able to connect to the Redis server runnin= g on my local machine, and if I get the opportunity today I'll be savin= g / retrieving values. =C2=A0

I'm open to feed= back or areas of exploration that others might be interested in or guidance= as to better approaches. =C2=A0

=
On Sat, Dec 13, 2014 at 1:55 PM, Anil Madhavaped= dy <anil@recoil.org> wrote:

> On 11 Dec 2014, at 01:53, Brian Brietzke <bbrietzke@gmail.com> wrote:
>
> There are implementations of the protocols for mysql and postgresql th= at
> popular.=C2=A0 I've done some digging and have found pure ocaml im= plementations
> for both redis and mongo.=C2=A0 I'll have to do some experimenting= and see
> what the results are like.

It would actually be really useful to have a simple benchmark agains= t
Redis and Mongo to put into mirage-skeleton.=C2=A0 We could run it over
both TCP and Vchan as a much more realistic workload than the usual
iperf efforts.

-anil
--001a11c2633ac9e2ea050a568978-- --===============8355151094760235459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8355151094760235459==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 18:43:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 18:43:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0x5T-0002kG-4s; Tue, 16 Dec 2014 18:43:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0wo8-0002Im-VE for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 18:25:17 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id E3/55-25714-C0970945; Tue, 16 Dec 2014 18:25:16 +0000 X-Env-Sender: jac22@cl.cam.ac.uk X-Msg-Ref: server-13.tower-206.messagelabs.com!1418754314!13719439!1 X-Originating-IP: [128.232.25.21] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13000 invoked from network); 16 Dec 2014 18:25:14 -0000 Received: from mta1.cl.cam.ac.uk (HELO mta1.cl.cam.ac.uk) (128.232.25.21) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2014 18:25:14 -0000 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 1Y0wo5-0007GB-7L; Tue, 16 Dec 2014 18:25:13 +0000 To: Thomas Gazagnaire In-reply-to: References: <69D665AD-E191-40B2-8E41-0111697C2E7F@gazagnaire.org> <307C9C1D-71DC-4040-BFBD-E935201F9CAB@gazagnaire.org> <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> Comments: In-reply-to Thomas Gazagnaire message dated "Mon, 15 Dec 2014 19:42:33 +0000." MIME-Version: 1.0 Content-ID: <12897.1418754309.1@cl.cam.ac.uk> Date: Tue, 16 Dec 2014 18:25:10 +0000 From: Jon Crowcroft Message-Id: X-Mailman-Approved-At: Tue, 16 Dec 2014 18:43:10 +0000 Cc: jac22@cl.cam.ac.uk, mirageos-devel Subject: Re: [MirageOS-devel] Irmin roadmap X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org wow max re factor! cool! In missive , Thomas Gazagnaire typed: >>Hi all, >> >>after 3 months of refactoring (!), 11,5k lines added and 8,8k lines removed, I am very happy to announce that I've merged my working patches into the master branch of Irmin. I'll pass the remaining of the week fixing the last quirks (mainly documentation related, but also around the command-line tool usability) before announcing the 0.9.0 release. >> >>One of the main change is the new public API with a proper documentation: http://samoht.github.io/irmin/ (although it needs more code examples[1]) >> >>Summary of the changes: >>* Expose a cleaner public API >>* Expose a cleaner API for the Unix backends >>* Expose a high-level REST API over HTTP (#80) >>* Rename `Origin` into `Task` and use it pervasively through the API >>* Add `remove_rec` to remove directories (#74, #85) >>* More efficient synchronization protocol between Irmin stores (#11) >>* Improve the efficiency of the Git backend >>* Remove dependency to `core_kernel` (#22, #81) >>* Remove dependency to `cryptokit` and `ocaml-sha` and use `nocrypto` instead >>* Fix writing contents at the root of the store (#73) >>* Fix the Git backend to stop constantly overwrite `.git/HEAD` (#76) >>* Add a limit on concurrently open files (#93, #75) >> >>As usual, feedback is welcome. >> >>The initial goal for the 1.0.0 release was to integrate Mirage and Irmin properly. That goal is very close now. What is missing: >>- Support the Git synchronisation protocol in Mirage. This means implementing Git.Sync.IO [2] >>- Add the right combinators in the mirage eDSL >>And that should be it. >> >>Best, >>Thomas >> >>[1] https://github.com/mirage/irmin/issues/99 >>[2] https://github.com/mirage/ocaml-git/blob/master/lib/sync.mli#L67 >> >>> On 21 Nov 2014, at 16:18, Thomas Gazagnaire wrote: >>> >>> Hi, >>> >>> I've spent the last week working on the new version of Irmin. This is still not finished but it is making good progress. A preliminary ocamldoc page is available online[1]. It is not complete and polished yet, but most parts are documented. >>> >>> The main changes are: >>> >>> - Improve compile time and portability: no more core_kernel and camlp4, now use nocrypto and mirage-tc >>> >>> - No more -pack. All the internal modules are prefixed by Ir_ and are not available to the users (the cmi are not installed) and the public module (with the public documentation) is Irmin >>> >>> - All the operations in a store now take a **mandatory** `origin` argument, even the read operation [2] (before, only the merge operations where requiring it). The origin contains the process/user name, the date, some (maybe structured) message, ... (this can be configured by the user). That origin value comes from the high-level call ("I want to add that value to my Irmin store") and are passed through all the low-level calls ("I need to create a new block in the block store, I need to update the head tag to point to the new head, etc) so you can very easily track every read and write operations in your store. My hope is that we can use that origin value to control the store encryption: you can store some keys in the origin and use them to encrypt on write and decrypt on read. Need more though on that, but I think we have everything needed now. >>> >>> - The high-level "branch-consistant" signature is simpler [3]. The internals of the contents, node, commit and tag stores are not exposed anymore. >>> >>> - The synchronisation functions are much more efficient and looks quite similar to what Git does, although we don't compress the data (yet) (but the slice[4] type is abstract, so we could do that later if needed, this involves tweaking [5]). >>> >>> What needs to be done: porting the backends, the http server and checking that everything still works fine. Hopefully this will be done early next week. >>> >>> Best, >>> Thomas >>> >>> [1]: http://samoht.github.io/irmin/ >>> [2]: http://samoht.github.io/irmin/Irmin.Store.RO.html >>> [3]: http://samoht.github.io/irmin/Irmin.Store.BC.html >>> [4]: http://samoht.github.io/irmin/Irmin.Store.BC.html#TYPEslice >>> [5]: https://github.com/samoht/irmin/blob/ab20999e43a9aa4a3bdb1733a55288080ff2c565/lib/ir_bc.ml#L488 >>> >>>> On 1 Oct 2014, at 21:38, Thomas Gazagnaire wrote: >>>> >>>> I'm very late on all of these points (although I almost have 1/ done, needs more polishing) but I've generated some docs which might be useful to people starting using the library: >>>> >>>> http://samoht.github.io/irmin/ >>>> >>>> Thomas >>>> >>>> On 9 Sep 2014, at 16:57, Thomas Gazagnaire wrote: >>>> >>>>> Hi all, >>>>> >>>>> Lots of people starting asked me about the status of Irmin. As you might have notice, I'vent had much time to spend on Irmin last month, but I plan to fix that. My current priorities are: >>>>> >>>>> 1/ make Irmin compiles on the Xen backend of Mirage. https://github.com/mirage/irmin/issues/81 >>>>> This means dropping the dependency to core_kernel (for now on). The external API will not change. >>>>> >>>>> 2/ improve the high-level JSON API. This is related to https://github.com/mirage/irmin/issues/80 >>>>> Currently, we only have a JSON API for the low-level stores, and the very partial implementation of the higher-level calls. Needs to complete and document that. >>>>> >>>>> 3/ implement a pure-ocaml Git server to be able to at least `git pull` from it. https://github.com/mirage/ocaml-git/issues/15 >>>>> Together with 1/ this will make possible to query the state of a running Mirage unikernel with a simple `git pull ` >>>>> >>>>> 4/ implement a simple distributed log server .https://github.com/mirage/irmin/issues/82 >>>>> Could use Benjamin's rope implementation, that I first need to release properly. >>>>> >>>>> 5/ try to come up with a solution to the "unlimited" memory/storage usage issues https://github.com/mirage/irmin/issues/83 >>>>> This is the most uncertain part of the short-term roadmap. I'll need to check again what are the limitation of Git shallow copies and see how we can use them to limit the history size to remember. >>>>> >>>>> There are also few open embarrassing bugs that I want to fix as well (regarding fd leaks ...). >>>>> >>>>> If anyone is interested to help me on any of these topics, please feel free to comment on the related issues on Github -- I'll gladly share the workload. Also, feel free to reply to that email if you think there is any important Imrin features that you think are missing now. >>>>> >>>>> Best, >>>>> Thomas >>>> >>> >> >> >>_______________________________________________ >>MirageOS-devel mailing list >>MirageOS-devel@lists.xenproject.org >>http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel cheers jon _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 18:43:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 18:43:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0x5T-0002kG-4s; Tue, 16 Dec 2014 18:43:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y0wo8-0002Im-VE for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 18:25:17 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id E3/55-25714-C0970945; Tue, 16 Dec 2014 18:25:16 +0000 X-Env-Sender: jac22@cl.cam.ac.uk X-Msg-Ref: server-13.tower-206.messagelabs.com!1418754314!13719439!1 X-Originating-IP: [128.232.25.21] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13000 invoked from network); 16 Dec 2014 18:25:14 -0000 Received: from mta1.cl.cam.ac.uk (HELO mta1.cl.cam.ac.uk) (128.232.25.21) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2014 18:25:14 -0000 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 1Y0wo5-0007GB-7L; Tue, 16 Dec 2014 18:25:13 +0000 To: Thomas Gazagnaire In-reply-to: References: <69D665AD-E191-40B2-8E41-0111697C2E7F@gazagnaire.org> <307C9C1D-71DC-4040-BFBD-E935201F9CAB@gazagnaire.org> <4BBAEAE9-F843-43C5-B46F-6575F4414186@gazagnaire.org> Comments: In-reply-to Thomas Gazagnaire message dated "Mon, 15 Dec 2014 19:42:33 +0000." MIME-Version: 1.0 Content-ID: <12897.1418754309.1@cl.cam.ac.uk> Date: Tue, 16 Dec 2014 18:25:10 +0000 From: Jon Crowcroft Message-Id: X-Mailman-Approved-At: Tue, 16 Dec 2014 18:43:10 +0000 Cc: jac22@cl.cam.ac.uk, mirageos-devel Subject: Re: [MirageOS-devel] Irmin roadmap X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org wow max re factor! cool! In missive , Thomas Gazagnaire typed: >>Hi all, >> >>after 3 months of refactoring (!), 11,5k lines added and 8,8k lines removed, I am very happy to announce that I've merged my working patches into the master branch of Irmin. I'll pass the remaining of the week fixing the last quirks (mainly documentation related, but also around the command-line tool usability) before announcing the 0.9.0 release. >> >>One of the main change is the new public API with a proper documentation: http://samoht.github.io/irmin/ (although it needs more code examples[1]) >> >>Summary of the changes: >>* Expose a cleaner public API >>* Expose a cleaner API for the Unix backends >>* Expose a high-level REST API over HTTP (#80) >>* Rename `Origin` into `Task` and use it pervasively through the API >>* Add `remove_rec` to remove directories (#74, #85) >>* More efficient synchronization protocol between Irmin stores (#11) >>* Improve the efficiency of the Git backend >>* Remove dependency to `core_kernel` (#22, #81) >>* Remove dependency to `cryptokit` and `ocaml-sha` and use `nocrypto` instead >>* Fix writing contents at the root of the store (#73) >>* Fix the Git backend to stop constantly overwrite `.git/HEAD` (#76) >>* Add a limit on concurrently open files (#93, #75) >> >>As usual, feedback is welcome. >> >>The initial goal for the 1.0.0 release was to integrate Mirage and Irmin properly. That goal is very close now. What is missing: >>- Support the Git synchronisation protocol in Mirage. This means implementing Git.Sync.IO [2] >>- Add the right combinators in the mirage eDSL >>And that should be it. >> >>Best, >>Thomas >> >>[1] https://github.com/mirage/irmin/issues/99 >>[2] https://github.com/mirage/ocaml-git/blob/master/lib/sync.mli#L67 >> >>> On 21 Nov 2014, at 16:18, Thomas Gazagnaire wrote: >>> >>> Hi, >>> >>> I've spent the last week working on the new version of Irmin. This is still not finished but it is making good progress. A preliminary ocamldoc page is available online[1]. It is not complete and polished yet, but most parts are documented. >>> >>> The main changes are: >>> >>> - Improve compile time and portability: no more core_kernel and camlp4, now use nocrypto and mirage-tc >>> >>> - No more -pack. All the internal modules are prefixed by Ir_ and are not available to the users (the cmi are not installed) and the public module (with the public documentation) is Irmin >>> >>> - All the operations in a store now take a **mandatory** `origin` argument, even the read operation [2] (before, only the merge operations where requiring it). The origin contains the process/user name, the date, some (maybe structured) message, ... (this can be configured by the user). That origin value comes from the high-level call ("I want to add that value to my Irmin store") and are passed through all the low-level calls ("I need to create a new block in the block store, I need to update the head tag to point to the new head, etc) so you can very easily track every read and write operations in your store. My hope is that we can use that origin value to control the store encryption: you can store some keys in the origin and use them to encrypt on write and decrypt on read. Need more though on that, but I think we have everything needed now. >>> >>> - The high-level "branch-consistant" signature is simpler [3]. The internals of the contents, node, commit and tag stores are not exposed anymore. >>> >>> - The synchronisation functions are much more efficient and looks quite similar to what Git does, although we don't compress the data (yet) (but the slice[4] type is abstract, so we could do that later if needed, this involves tweaking [5]). >>> >>> What needs to be done: porting the backends, the http server and checking that everything still works fine. Hopefully this will be done early next week. >>> >>> Best, >>> Thomas >>> >>> [1]: http://samoht.github.io/irmin/ >>> [2]: http://samoht.github.io/irmin/Irmin.Store.RO.html >>> [3]: http://samoht.github.io/irmin/Irmin.Store.BC.html >>> [4]: http://samoht.github.io/irmin/Irmin.Store.BC.html#TYPEslice >>> [5]: https://github.com/samoht/irmin/blob/ab20999e43a9aa4a3bdb1733a55288080ff2c565/lib/ir_bc.ml#L488 >>> >>>> On 1 Oct 2014, at 21:38, Thomas Gazagnaire wrote: >>>> >>>> I'm very late on all of these points (although I almost have 1/ done, needs more polishing) but I've generated some docs which might be useful to people starting using the library: >>>> >>>> http://samoht.github.io/irmin/ >>>> >>>> Thomas >>>> >>>> On 9 Sep 2014, at 16:57, Thomas Gazagnaire wrote: >>>> >>>>> Hi all, >>>>> >>>>> Lots of people starting asked me about the status of Irmin. As you might have notice, I'vent had much time to spend on Irmin last month, but I plan to fix that. My current priorities are: >>>>> >>>>> 1/ make Irmin compiles on the Xen backend of Mirage. https://github.com/mirage/irmin/issues/81 >>>>> This means dropping the dependency to core_kernel (for now on). The external API will not change. >>>>> >>>>> 2/ improve the high-level JSON API. This is related to https://github.com/mirage/irmin/issues/80 >>>>> Currently, we only have a JSON API for the low-level stores, and the very partial implementation of the higher-level calls. Needs to complete and document that. >>>>> >>>>> 3/ implement a pure-ocaml Git server to be able to at least `git pull` from it. https://github.com/mirage/ocaml-git/issues/15 >>>>> Together with 1/ this will make possible to query the state of a running Mirage unikernel with a simple `git pull ` >>>>> >>>>> 4/ implement a simple distributed log server .https://github.com/mirage/irmin/issues/82 >>>>> Could use Benjamin's rope implementation, that I first need to release properly. >>>>> >>>>> 5/ try to come up with a solution to the "unlimited" memory/storage usage issues https://github.com/mirage/irmin/issues/83 >>>>> This is the most uncertain part of the short-term roadmap. I'll need to check again what are the limitation of Git shallow copies and see how we can use them to limit the history size to remember. >>>>> >>>>> There are also few open embarrassing bugs that I want to fix as well (regarding fd leaks ...). >>>>> >>>>> If anyone is interested to help me on any of these topics, please feel free to comment on the related issues on Github -- I'll gladly share the workload. Also, feel free to reply to that email if you think there is any important Imrin features that you think are missing now. >>>>> >>>>> Best, >>>>> Thomas >>>> >>> >> >> >>_______________________________________________ >>MirageOS-devel mailing list >>MirageOS-devel@lists.xenproject.org >>http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel cheers jon _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:23:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:23:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11Si-0004uh-4d; Tue, 16 Dec 2014 23:23:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11Sh-0004uc-Kq for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:23:27 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 0B/E1-09842-FEEB0945; Tue, 16 Dec 2014 23:23:27 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-12.tower-21.messagelabs.com!1418772206!16059403!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13956 invoked from network); 16 Dec 2014 23:23:26 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-12.tower-21.messagelabs.com with SMTP; 16 Dec 2014 23:23:26 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 07A33473C87_490BEEEB for ; Tue, 16 Dec 2014 23:23:26 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id D7C9B430E48_490BEEDF for ; Tue, 16 Dec 2014 23:23:25 +0000 (GMT) Received: from host-2-100-253-149.as13285.net ([2.100.253.149] helo=[192.168.1.2]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y11Sf-0007z2-QM for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:23:25 +0000 Message-ID: <5490BEED.5050509@nottingham.ac.uk> Date: Tue, 16 Dec 2014 23:23:25 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I am wondering if the following issue is already addressed: https://github.com/mirage/mirage-tcpip/issues/33 https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:23:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:23:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11Si-0004uh-4d; Tue, 16 Dec 2014 23:23:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11Sh-0004uc-Kq for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:23:27 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 0B/E1-09842-FEEB0945; Tue, 16 Dec 2014 23:23:27 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-12.tower-21.messagelabs.com!1418772206!16059403!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13956 invoked from network); 16 Dec 2014 23:23:26 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-12.tower-21.messagelabs.com with SMTP; 16 Dec 2014 23:23:26 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 07A33473C87_490BEEEB for ; Tue, 16 Dec 2014 23:23:26 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id D7C9B430E48_490BEEDF for ; Tue, 16 Dec 2014 23:23:25 +0000 (GMT) Received: from host-2-100-253-149.as13285.net ([2.100.253.149] helo=[192.168.1.2]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y11Sf-0007z2-QM for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:23:25 +0000 Message-ID: <5490BEED.5050509@nottingham.ac.uk> Date: Tue, 16 Dec 2014 23:23:25 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org Subject: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I am wondering if the following issue is already addressed: https://github.com/mirage/mirage-tcpip/issues/33 https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:46:05 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:46:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11oZ-0005lY-Q8; Tue, 16 Dec 2014 23:46:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11oX-0005lT-5o for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:46:01 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 86/5D-09842-834C0945; Tue, 16 Dec 2014 23:46:00 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1418773559!16071863!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6386 invoked from network); 16 Dec 2014 23:45:59 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2014 23:45:59 -0000 Received: from [10.10.120.231] (50-197-184-177-static.hfc.comcastbusiness.net [50.197.184.177]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id fc5714e9; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 16 Dec 2014 23:51:51 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5490BEED.5050509@nottingham.ac.uk> Date: Tue, 16 Dec 2014 15:45:55 -0800 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 16 Dec 2014, at 15:23, Masoud Koleini wrote: > > I am wondering if the following issue is already addressed: > > https://github.com/mirage/mirage-tcpip/issues/33 > > https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html > It probably still happens at 64MB of RAM -- it requires some code to adjust the GC parameters in the OCaml runtime to trigger a collection more often. It should be harmless however, since (as the bug report observes), a failure to allocate an Io_page results in a GC compaction that frees up memory so that the allocation eventually succeeds. Any particular reason for asking -- is the bug affecting your switch somehow? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:46:05 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:46:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11oZ-0005lY-Q8; Tue, 16 Dec 2014 23:46:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11oX-0005lT-5o for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:46:01 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 86/5D-09842-834C0945; Tue, 16 Dec 2014 23:46:00 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1418773559!16071863!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6386 invoked from network); 16 Dec 2014 23:45:59 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2014 23:45:59 -0000 Received: from [10.10.120.231] (50-197-184-177-static.hfc.comcastbusiness.net [50.197.184.177]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id fc5714e9; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 16 Dec 2014 23:51:51 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5490BEED.5050509@nottingham.ac.uk> Date: Tue, 16 Dec 2014 15:45:55 -0800 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 16 Dec 2014, at 15:23, Masoud Koleini wrote: > > I am wondering if the following issue is already addressed: > > https://github.com/mirage/mirage-tcpip/issues/33 > > https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html > It probably still happens at 64MB of RAM -- it requires some code to adjust the GC parameters in the OCaml runtime to trigger a collection more often. It should be harmless however, since (as the bug report observes), a failure to allocate an Io_page results in a GC compaction that frees up memory so that the allocation eventually succeeds. Any particular reason for asking -- is the bug affecting your switch somehow? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:57:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:57:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11zO-00063B-Mx; Tue, 16 Dec 2014 23:57:14 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11zM-000636-Mc for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:57:12 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 1E/EA-25276-7D6C0945; Tue, 16 Dec 2014 23:57:11 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-21.messagelabs.com!1418774229!15717564!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12975 invoked from network); 16 Dec 2014 23:57:09 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-3.tower-21.messagelabs.com with SMTP; 16 Dec 2014 23:57:09 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2A1B2473C6E_490C6D5B for ; Tue, 16 Dec 2014 23:57:09 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 824D7430EBE_490C6D4F for ; Tue, 16 Dec 2014 23:57:08 +0000 (GMT) Received: from host-2-100-253-149.as13285.net ([2.100.253.149] helo=[192.168.1.2]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y11zI-0008JM-EK; Tue, 16 Dec 2014 23:57:08 +0000 Message-ID: <5490C6D4.3090102@nottingham.ac.uk> Date: Tue, 16 Dec 2014 23:57:08 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Anil Madhavapeddy References: <5490BEED.5050509@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. On 16/12/14 23:45, Anil Madhavapeddy wrote: > On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >> I am wondering if the following issue is already addressed: >> >> https://github.com/mirage/mirage-tcpip/issues/33 >> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> > It probably still happens at 64MB of RAM -- it requires some code to adjust > the GC parameters in the OCaml runtime to trigger a collection more often. > It should be harmless however, since (as the bug report observes), a failure > to allocate an Io_page results in a GC compaction that frees up memory so > that the allocation eventually succeeds. > > Any particular reason for asking -- is the bug affecting your switch somehow? > > -anil This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:57:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:57:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11zO-00063B-Mx; Tue, 16 Dec 2014 23:57:14 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y11zM-000636-Mc for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:57:12 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 1E/EA-25276-7D6C0945; Tue, 16 Dec 2014 23:57:11 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-21.messagelabs.com!1418774229!15717564!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12975 invoked from network); 16 Dec 2014 23:57:09 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-3.tower-21.messagelabs.com with SMTP; 16 Dec 2014 23:57:09 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2A1B2473C6E_490C6D5B for ; Tue, 16 Dec 2014 23:57:09 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 824D7430EBE_490C6D4F for ; Tue, 16 Dec 2014 23:57:08 +0000 (GMT) Received: from host-2-100-253-149.as13285.net ([2.100.253.149] helo=[192.168.1.2]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y11zI-0008JM-EK; Tue, 16 Dec 2014 23:57:08 +0000 Message-ID: <5490C6D4.3090102@nottingham.ac.uk> Date: Tue, 16 Dec 2014 23:57:08 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Anil Madhavapeddy References: <5490BEED.5050509@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. On 16/12/14 23:45, Anil Madhavapeddy wrote: > On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >> I am wondering if the following issue is already addressed: >> >> https://github.com/mirage/mirage-tcpip/issues/33 >> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> > It probably still happens at 64MB of RAM -- it requires some code to adjust > the GC parameters in the OCaml runtime to trigger a collection more often. > It should be harmless however, since (as the bug report observes), a failure > to allocate an Io_page results in a GC compaction that frees up memory so > that the allocation eventually succeeds. > > Any particular reason for asking -- is the bug affecting your switch somehow? > > -anil This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:59:34 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:59:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y121d-00064s-Vj; Tue, 16 Dec 2014 23:59:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y121c-00064n-JI for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:59:32 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 61/7E-15461-367C0945; Tue, 16 Dec 2014 23:59:31 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-21.messagelabs.com!1418774371!16073280!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12345 invoked from network); 16 Dec 2014 23:59:31 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2014 23:59:31 -0000 Received: from [10.10.120.231] (50-197-184-177-static.hfc.comcastbusiness.net [50.197.184.177]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 3be9aa4c; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 00:05:24 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5490C6D4.3090102@nottingham.ac.uk> Date: Tue, 16 Dec 2014 15:59:27 -0800 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org If you're running short of memory on 2GB, that indicates that there's a large amount of buffering going on. Are you seeing packet loss as a result? Please do make a note on the bug report that you're seeing this, and what the trigger conditions are. If you have a simple mirage-skeleton example of an Ethernet port flood that causes this, then that'll help fix it. -anil > On 16 Dec 2014, at 15:57, Masoud Koleini wrote: > > Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. > > On 16/12/14 23:45, Anil Madhavapeddy wrote: >> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>> I am wondering if the following issue is already addressed: >>> >>> https://github.com/mirage/mirage-tcpip/issues/33 >>> >>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>> >> It probably still happens at 64MB of RAM -- it requires some code to adjust >> the GC parameters in the OCaml runtime to trigger a collection more often. >> It should be harmless however, since (as the bug report observes), a failure >> to allocate an Io_page results in a GC compaction that frees up memory so >> that the allocation eventually succeeds. >> >> Any particular reason for asking -- is the bug affecting your switch somehow? >> >> -anil > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Tue Dec 16 23:59:34 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 16 Dec 2014 23:59:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y121d-00064s-Vj; Tue, 16 Dec 2014 23:59:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y121c-00064n-JI for mirageos-devel@lists.xenproject.org; Tue, 16 Dec 2014 23:59:32 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 61/7E-15461-367C0945; Tue, 16 Dec 2014 23:59:31 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-21.messagelabs.com!1418774371!16073280!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12345 invoked from network); 16 Dec 2014 23:59:31 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2014 23:59:31 -0000 Received: from [10.10.120.231] (50-197-184-177-static.hfc.comcastbusiness.net [50.197.184.177]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 3be9aa4c; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 00:05:24 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5490C6D4.3090102@nottingham.ac.uk> Date: Tue, 16 Dec 2014 15:59:27 -0800 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org If you're running short of memory on 2GB, that indicates that there's a large amount of buffering going on. Are you seeing packet loss as a result? Please do make a note on the bug report that you're seeing this, and what the trigger conditions are. If you have a simple mirage-skeleton example of an Ethernet port flood that causes this, then that'll help fix it. -anil > On 16 Dec 2014, at 15:57, Masoud Koleini wrote: > > Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. > > On 16/12/14 23:45, Anil Madhavapeddy wrote: >> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>> I am wondering if the following issue is already addressed: >>> >>> https://github.com/mirage/mirage-tcpip/issues/33 >>> >>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>> >> It probably still happens at 64MB of RAM -- it requires some code to adjust >> the GC parameters in the OCaml runtime to trigger a collection more often. >> It should be harmless however, since (as the bug report observes), a failure >> to allocate an Io_page results in a GC compaction that frees up memory so >> that the allocation eventually succeeds. >> >> Any particular reason for asking -- is the bug affecting your switch somehow? >> >> -anil > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 01:13:30 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 01:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y13B6-0003Wo-Tq; Wed, 17 Dec 2014 01:13:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y13B5-0003Wj-El for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 01:13:23 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 1B/48-28865-2B8D0945; Wed, 17 Dec 2014 01:13:22 +0000 X-Env-Sender: louis.gesbert@ocamlpro.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1418778801!13731103!1 X-Originating-IP: [212.227.126.131] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31403 invoked from network); 17 Dec 2014 01:13:21 -0000 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.131) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 01:13:21 -0000 Received: from agaric.localnet ([111.64.65.75]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0MHfXI-1Y4LUo16nU-003OLu; Wed, 17 Dec 2014 02:13:10 +0100 From: Louis Gesbert To: opam-devel@lists.ocaml.org Date: Wed, 17 Dec 2014 10:13:05 +0900 Message-ID: <3966385.O0j2Ln9Ulu@agaric> Organization: OCamlPro User-Agent: KMail/4.14.1 (Linux/3.16-2-amd64; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <3900186.VCNjxAKEzz@agaric> MIME-Version: 1.0 X-Provags-ID: V03:K0:5/ch/dgYZp+Ymyvw66SrCxRkR9k0N/TkYiD6iQSh3fhIcaZeSJN 2yk/u9FfQd4Ecmact28Qe/2OCy8W81EW8RqQ8wGJLppqlcO9qYBCtneJSoSsfIsixfUX0WE 4OkoQUG2/FFSIGaMSG1fT3lbQWHGFZ/vUBAtO1J40MoRq3jirHrthfpjkxeu97/5raswDwG DuoqbrDMeSz+hdxAzWGxQ== X-UI-Out-Filterresults: notjunk:1; Cc: David Allsopp , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5058901093563747745==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============5058901093563747745== Content-Type: multipart/alternative; boundary="nextPart1567570.WshI9bNNGz" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1567570.WshI9bNNGz Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" > Again, in my opinion, "once bitten, twice shy". My own personal experience is that if something like this has happened it is *very* likely it will happen again (and that's in no way a negative comment on any developers concerned!) > > There are plenty of other instances in configure scripts where semantics are tested rather than a version compatibility matrix (usually when probing the C compiler) so I don't think it's too unusual a thing to want to do? Yup, I was half-joking... In this case though I have really no idea of what precise aspects of the semantics we may want to check (to be honest, I didn't even dig enough to see what change caused that bug -- because by the time it was done Opam was already fixed ; it's most likely a change in the Debian module, and what I can tell is that we _were_ assuming a consistent cudf-version numbering scheme among slightly different package universes, which wasn't specified. Also, that could well have had that kind of consequences ; but I'm still speculating). My point was that if we stick to specified APIs, we _shouldn't_ run into that ; as for the semantics, really, I don't see better than running `make tests` for testing them, and shouldn't that sound obvious before shipping a package ? --nextPart1567570.WshI9bNNGz Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

> Again, in my opinion, "once bitten, twice shy". My own personal experience is that if something like this has happened it is *very* likely it will happen again (and that's in no way a negative comment on any developers concerned!)

>

> There are plenty of other instances in configure scripts where semantics are tested rather than a version compatibility matrix (usually when probing the C compiler) so I don't think it's too unusual a thing to want to do?

 

Yup, I was half-joking... In this case though I have really no idea of what precise aspects of the semantics we may want to check (to be honest, I didn't even dig enough to see what change caused that bug -- because by the time it was done Opam was already fixed ; it's most likely a change in the Debian module, and what I can tell is that we _were_ assuming a consistent cudf-version numbering scheme among slightly different package universes, which wasn't specified. Also, that could well have had that kind of consequences ; but I'm still speculating).

 

My point was that if we stick to specified APIs, we _shouldn't_ run into that ; as for the semantics, really, I don't see better than running `make tests` for testing them, and shouldn't that sound obvious before shipping a package ?

 

--nextPart1567570.WshI9bNNGz-- --===============5058901093563747745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5058901093563747745==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 01:13:30 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 01:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y13B6-0003Wo-Tq; Wed, 17 Dec 2014 01:13:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y13B5-0003Wj-El for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 01:13:23 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 1B/48-28865-2B8D0945; Wed, 17 Dec 2014 01:13:22 +0000 X-Env-Sender: louis.gesbert@ocamlpro.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1418778801!13731103!1 X-Originating-IP: [212.227.126.131] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31403 invoked from network); 17 Dec 2014 01:13:21 -0000 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.131) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 01:13:21 -0000 Received: from agaric.localnet ([111.64.65.75]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0MHfXI-1Y4LUo16nU-003OLu; Wed, 17 Dec 2014 02:13:10 +0100 From: Louis Gesbert To: opam-devel@lists.ocaml.org Date: Wed, 17 Dec 2014 10:13:05 +0900 Message-ID: <3966385.O0j2Ln9Ulu@agaric> Organization: OCamlPro User-Agent: KMail/4.14.1 (Linux/3.16-2-amd64; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: <8014D6E0-3AA1-4391-A278-A9D630FB77F2@recoil.org> <3900186.VCNjxAKEzz@agaric> MIME-Version: 1.0 X-Provags-ID: V03:K0:5/ch/dgYZp+Ymyvw66SrCxRkR9k0N/TkYiD6iQSh3fhIcaZeSJN 2yk/u9FfQd4Ecmact28Qe/2OCy8W81EW8RqQ8wGJLppqlcO9qYBCtneJSoSsfIsixfUX0WE 4OkoQUG2/FFSIGaMSG1fT3lbQWHGFZ/vUBAtO1J40MoRq3jirHrthfpjkxeu97/5raswDwG DuoqbrDMeSz+hdxAzWGxQ== X-UI-Out-Filterresults: notjunk:1; Cc: David Allsopp , mirageos-devel Subject: Re: [MirageOS-devel] [opam-devel] opam 1.1.1 and aspcud 1.9 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5058901093563747745==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============5058901093563747745== Content-Type: multipart/alternative; boundary="nextPart1567570.WshI9bNNGz" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1567570.WshI9bNNGz Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" > Again, in my opinion, "once bitten, twice shy". My own personal experience is that if something like this has happened it is *very* likely it will happen again (and that's in no way a negative comment on any developers concerned!) > > There are plenty of other instances in configure scripts where semantics are tested rather than a version compatibility matrix (usually when probing the C compiler) so I don't think it's too unusual a thing to want to do? Yup, I was half-joking... In this case though I have really no idea of what precise aspects of the semantics we may want to check (to be honest, I didn't even dig enough to see what change caused that bug -- because by the time it was done Opam was already fixed ; it's most likely a change in the Debian module, and what I can tell is that we _were_ assuming a consistent cudf-version numbering scheme among slightly different package universes, which wasn't specified. Also, that could well have had that kind of consequences ; but I'm still speculating). My point was that if we stick to specified APIs, we _shouldn't_ run into that ; as for the semantics, really, I don't see better than running `make tests` for testing them, and shouldn't that sound obvious before shipping a package ? --nextPart1567570.WshI9bNNGz Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

> Again, in my opinion, "once bitten, twice shy". My own personal experience is that if something like this has happened it is *very* likely it will happen again (and that's in no way a negative comment on any developers concerned!)

>

> There are plenty of other instances in configure scripts where semantics are tested rather than a version compatibility matrix (usually when probing the C compiler) so I don't think it's too unusual a thing to want to do?

 

Yup, I was half-joking... In this case though I have really no idea of what precise aspects of the semantics we may want to check (to be honest, I didn't even dig enough to see what change caused that bug -- because by the time it was done Opam was already fixed ; it's most likely a change in the Debian module, and what I can tell is that we _were_ assuming a consistent cudf-version numbering scheme among slightly different package universes, which wasn't specified. Also, that could well have had that kind of consequences ; but I'm still speculating).

 

My point was that if we stick to specified APIs, we _shouldn't_ run into that ; as for the semantics, really, I don't see better than running `make tests` for testing them, and shouldn't that sound obvious before shipping a package ?

 

--nextPart1567570.WshI9bNNGz-- --===============5058901093563747745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5058901093563747745==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 11:32:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 11:32:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1CqQ-00030o-4Y; Wed, 17 Dec 2014 11:32:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1CqN-00030j-PG for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 11:32:40 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 56/08-02712-7D961945; Wed, 17 Dec 2014 11:32:39 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1418815958!12305387!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29380 invoked from network); 17 Dec 2014 11:32:38 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 11:32:38 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id ee42122e; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 11:38:31 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 17 Dec 2014 03:32:33 -0800 Message-Id: <4CF51750-C5B8-4A3F-886A-4BFE1FD7007B@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org And just to confirm that we have no packet loss, I left parallel ping floods running for a day. The variance is due to the GC compactions: 478535022 packets transmitted, 478535022 received, 0% packet loss, time 42469559ms rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 ms -anil > On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: > > If you're running short of memory on 2GB, that indicates that there's a large amount of buffering going on. Are you seeing packet loss as a result? > > Please do make a note on the bug report that you're seeing this, and what the trigger conditions are. If you have a simple mirage-skeleton example of an Ethernet port flood that causes this, then that'll help fix it. > > -anil > >> On 16 Dec 2014, at 15:57, Masoud Koleini wrote: >> >> Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. >> >> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>> I am wondering if the following issue is already addressed: >>>> >>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>> >>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>> >>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>> the GC parameters in the OCaml runtime to trigger a collection more often. >>> It should be harmless however, since (as the bug report observes), a failure >>> to allocate an Io_page results in a GC compaction that frees up memory so >>> that the allocation eventually succeeds. >>> >>> Any particular reason for asking -- is the bug affecting your switch somehow? >>> >>> -anil >> >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 11:32:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 11:32:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1CqQ-00030o-4Y; Wed, 17 Dec 2014 11:32:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1CqN-00030j-PG for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 11:32:40 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id 56/08-02712-7D961945; Wed, 17 Dec 2014 11:32:39 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-27.messagelabs.com!1418815958!12305387!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29380 invoked from network); 17 Dec 2014 11:32:38 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 11:32:38 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id ee42122e; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 11:38:31 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 17 Dec 2014 03:32:33 -0800 Message-Id: <4CF51750-C5B8-4A3F-886A-4BFE1FD7007B@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org And just to confirm that we have no packet loss, I left parallel ping floods running for a day. The variance is due to the GC compactions: 478535022 packets transmitted, 478535022 received, 0% packet loss, time 42469559ms rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 ms -anil > On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: > > If you're running short of memory on 2GB, that indicates that there's a large amount of buffering going on. Are you seeing packet loss as a result? > > Please do make a note on the bug report that you're seeing this, and what the trigger conditions are. If you have a simple mirage-skeleton example of an Ethernet port flood that causes this, then that'll help fix it. > > -anil > >> On 16 Dec 2014, at 15:57, Masoud Koleini wrote: >> >> Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. >> >> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>> I am wondering if the following issue is already addressed: >>>> >>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>> >>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>> >>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>> the GC parameters in the OCaml runtime to trigger a collection more often. >>> It should be harmless however, since (as the bug report observes), a failure >>> to allocate an Io_page results in a GC compaction that frees up memory so >>> that the allocation eventually succeeds. >>> >>> Any particular reason for asking -- is the bug affecting your switch somehow? >>> >>> -anil >> >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 12:34:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 12:34:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DoD-0004wa-BM; Wed, 17 Dec 2014 12:34:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DoC-0004wV-0S for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:34:28 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 7D/86-28865-35871945; Wed, 17 Dec 2014 12:34:27 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-5.tower-206.messagelabs.com!1418819666!13847785!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19276 invoked from network); 17 Dec 2014 12:34:26 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-5.tower-206.messagelabs.com with SMTP; 17 Dec 2014 12:34:26 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D909130C941_4917851B for ; Wed, 17 Dec 2014 12:34:25 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 970F72FA3DD_4917851F for ; Wed, 17 Dec 2014 12:34:25 +0000 (GMT) Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1Do9-0007wO-Is; Wed, 17 Dec 2014 12:34:25 +0000 From: Richard Mortier To: Anil Madhavapeddy Date: Wed, 17 Dec 2014 12:34:23 +0000 Thread-Topic: [MirageOS-devel] Memory exhaustion in Mirage Thread-Index: AdAZ9cpbkooVvbykTF2Tbwh7nD2I4w== Message-ID: <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> In-Reply-To: <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7489980045809121404==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7489980045809121404== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii to check-- that's flood ping from a standard ping on linux hitting a uniker= nel, rather than flood pinging from within a unikernel to something else, c= orrect? (don't know if it's significant but might help masoud in tracking down his = issue.) On 17 Dec 2014, at 11:32, Anil Madhavapeddy wrote: > And just to confirm that we have no packet loss, I left parallel ping flo= ods running for a day. The variance is due to the GC compactions: >=20 > 478535022 packets transmitted, 478535022 received, 0% packet loss, time 4= 2469559ms > rtt min/avg/max/mdev =3D 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065= ms >=20 > -anil >=20 >> On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: >>=20 >> If you're running short of memory on 2GB, that indicates that there's a = large amount of buffering going on. Are you seeing packet loss as a result? >>=20 >> Please do make a note on the bug report that you're seeing this, and wha= t the trigger conditions are. If you have a simple mirage-skeleton example= of an Ethernet port flood that causes this, then that'll help fix it. >>=20 >> -anil >>=20 >>> On 16 Dec 2014, at 15:57, Masoud Koleini wrote: >>>=20 >>> Yes, I have faced this problem several times when flooding the input po= rt (similar error on the console). The allocated memory for the switch is 2= GB, which is much higher than 64MB, but I guess bit rate should be higher t= oo. >>>=20 >>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>> I am wondering if the following issue is already addressed: >>>>>=20 >>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>>=20 >>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>>=20 >>>> It probably still happens at 64MB of RAM -- it requires some code to a= djust >>>> the GC parameters in the OCaml runtime to trigger a collection more of= ten. >>>> It should be harmless however, since (as the bug report observes), a f= ailure >>>> to allocate an Io_page results in a GC compaction that frees up memory= so >>>> that the allocation eventually succeeds. >>>>=20 >>>> Any particular reason for asking -- is the bug affecting your switch s= omehow? >>>>=20 >>>> -anil >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> This message and any attachment are intended solely for the addressee a= nd may contain confidential information. If you have received this message = in error, please send it back to me, and immediately delete it. Please do= not use, copy or disclose the information contained in this message or in = any attachment. Any views or opinions expressed by the author of this emai= l do not necessarily reflect the views of the University of Nottingham. >>>=20 >>> This message has been checked for viruses but the contents of an attach= ment may still contain software viruses which could damage your computer sy= stem, you are advised to perform your own checks. Email communications with= the University of Nottingham may be monitored as permitted by UK legislati= on. >>>=20 >>=20 >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>=20 >=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkXhPAAoJEOLF27JWwSg3Y9cP/A/02zePFOFWkbzP68URVWUu t3uqlS5yCI1gu57+jJYf5Z4H7HcXQyHh8ulnd4+v3oCrc/WVNikEi/a1SmkmBy4P veEONBNumLTU/tGofarNsjPEOlvxmD9YV3FV6Uho9rdKxOIqwD8ib+1dsJvjRXzN 4ywQAGkDhPS+cYLIbl2m7O7aSJSyBn6xxTPe0kRGc3C5kHpRY/y5BDcz0LRt0f5X AjYqOlG/vNYTGO7c4z8nCpliTDhCka9/OTRDHDJvGJO5toUQNMHpy32dKCsucu91 cUgHxGmPFXsmR72CPoWPsZoBNsFb+tg08ext6y3mGVsw95XYSIA/fGzmKsRZ4CA8 5z2Q3aE3OnB4yxz5U5q08IOkhxVlBcaPO7EG6RN6h7fTuvIyE67XGNw00kJcxJTx +cy/BJZO8cbBCjAHuvp+RW7m6Nvi7s+H6mpHWlDy1shOsgxfOEibXbNv6NRHAL6+ y2oq8gJKjNTtHMGRCCRTzXlDRkEFbdULQRdfMelgLhL9svy4gSNAP64v8pa/rrNY bStDPwsI2jdlwhFkuabYN/jvTiYUMJy4mRA2Lv5Nj8mSLAo8gUia1EOXi1iNnukv H1w8lxBHVAEKO53NSQTcKxgJls3UDAXrLPp+tzUuAmnw/TCzZdIgU3GdxvQaSRaz VUF6CFYL8azMZUQoMQEZ =4kdj -----END PGP SIGNATURE----- --Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635-- --===============7489980045809121404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7489980045809121404==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 12:34:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 12:34:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DoD-0004wa-BM; Wed, 17 Dec 2014 12:34:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DoC-0004wV-0S for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:34:28 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 7D/86-28865-35871945; Wed, 17 Dec 2014 12:34:27 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-5.tower-206.messagelabs.com!1418819666!13847785!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19276 invoked from network); 17 Dec 2014 12:34:26 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-5.tower-206.messagelabs.com with SMTP; 17 Dec 2014 12:34:26 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D909130C941_4917851B for ; Wed, 17 Dec 2014 12:34:25 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 970F72FA3DD_4917851F for ; Wed, 17 Dec 2014 12:34:25 +0000 (GMT) Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1Do9-0007wO-Is; Wed, 17 Dec 2014 12:34:25 +0000 From: Richard Mortier To: Anil Madhavapeddy Date: Wed, 17 Dec 2014 12:34:23 +0000 Thread-Topic: [MirageOS-devel] Memory exhaustion in Mirage Thread-Index: AdAZ9cpbkooVvbykTF2Tbwh7nD2I4w== Message-ID: <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> In-Reply-To: <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7489980045809121404==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7489980045809121404== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii to check-- that's flood ping from a standard ping on linux hitting a uniker= nel, rather than flood pinging from within a unikernel to something else, c= orrect? (don't know if it's significant but might help masoud in tracking down his = issue.) On 17 Dec 2014, at 11:32, Anil Madhavapeddy wrote: > And just to confirm that we have no packet loss, I left parallel ping flo= ods running for a day. The variance is due to the GC compactions: >=20 > 478535022 packets transmitted, 478535022 received, 0% packet loss, time 4= 2469559ms > rtt min/avg/max/mdev =3D 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065= ms >=20 > -anil >=20 >> On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: >>=20 >> If you're running short of memory on 2GB, that indicates that there's a = large amount of buffering going on. Are you seeing packet loss as a result? >>=20 >> Please do make a note on the bug report that you're seeing this, and wha= t the trigger conditions are. If you have a simple mirage-skeleton example= of an Ethernet port flood that causes this, then that'll help fix it. >>=20 >> -anil >>=20 >>> On 16 Dec 2014, at 15:57, Masoud Koleini wrote: >>>=20 >>> Yes, I have faced this problem several times when flooding the input po= rt (similar error on the console). The allocated memory for the switch is 2= GB, which is much higher than 64MB, but I guess bit rate should be higher t= oo. >>>=20 >>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>> I am wondering if the following issue is already addressed: >>>>>=20 >>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>>=20 >>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>>=20 >>>> It probably still happens at 64MB of RAM -- it requires some code to a= djust >>>> the GC parameters in the OCaml runtime to trigger a collection more of= ten. >>>> It should be harmless however, since (as the bug report observes), a f= ailure >>>> to allocate an Io_page results in a GC compaction that frees up memory= so >>>> that the allocation eventually succeeds. >>>>=20 >>>> Any particular reason for asking -- is the bug affecting your switch s= omehow? >>>>=20 >>>> -anil >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> This message and any attachment are intended solely for the addressee a= nd may contain confidential information. If you have received this message = in error, please send it back to me, and immediately delete it. Please do= not use, copy or disclose the information contained in this message or in = any attachment. Any views or opinions expressed by the author of this emai= l do not necessarily reflect the views of the University of Nottingham. >>>=20 >>> This message has been checked for viruses but the contents of an attach= ment may still contain software viruses which could damage your computer sy= stem, you are advised to perform your own checks. Email communications with= the University of Nottingham may be monitored as permitted by UK legislati= on. >>>=20 >>=20 >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>=20 >=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkXhPAAoJEOLF27JWwSg3Y9cP/A/02zePFOFWkbzP68URVWUu t3uqlS5yCI1gu57+jJYf5Z4H7HcXQyHh8ulnd4+v3oCrc/WVNikEi/a1SmkmBy4P veEONBNumLTU/tGofarNsjPEOlvxmD9YV3FV6Uho9rdKxOIqwD8ib+1dsJvjRXzN 4ywQAGkDhPS+cYLIbl2m7O7aSJSyBn6xxTPe0kRGc3C5kHpRY/y5BDcz0LRt0f5X AjYqOlG/vNYTGO7c4z8nCpliTDhCka9/OTRDHDJvGJO5toUQNMHpy32dKCsucu91 cUgHxGmPFXsmR72CPoWPsZoBNsFb+tg08ext6y3mGVsw95XYSIA/fGzmKsRZ4CA8 5z2Q3aE3OnB4yxz5U5q08IOkhxVlBcaPO7EG6RN6h7fTuvIyE67XGNw00kJcxJTx +cy/BJZO8cbBCjAHuvp+RW7m6Nvi7s+H6mpHWlDy1shOsgxfOEibXbNv6NRHAL6+ y2oq8gJKjNTtHMGRCCRTzXlDRkEFbdULQRdfMelgLhL9svy4gSNAP64v8pa/rrNY bStDPwsI2jdlwhFkuabYN/jvTiYUMJy4mRA2Lv5Nj8mSLAo8gUia1EOXi1iNnukv H1w8lxBHVAEKO53NSQTcKxgJls3UDAXrLPp+tzUuAmnw/TCzZdIgU3GdxvQaSRaz VUF6CFYL8azMZUQoMQEZ =4kdj -----END PGP SIGNATURE----- --Apple-Mail=_F3F7002F-255E-460E-B846-02C0AF648635-- --===============7489980045809121404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7489980045809121404==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 12:41:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 12:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DvE-0004ys-WE; Wed, 17 Dec 2014 12:41:45 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DvE-0004yl-4d for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:41:44 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id CC/DC-14727-70A71945; Wed, 17 Dec 2014 12:41:43 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-206.messagelabs.com!1418820102!8461746!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28619 invoked from network); 17 Dec 2014 12:41:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 12:41:42 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 1cf1d2a7; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 12:47:35 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> Date: Wed, 17 Dec 2014 04:41:37 -0800 Message-Id: <1BDD9091-40BA-4CBC-A353-8E3E6FD04F89@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org That's correct. It's pinging from dom0 to the unikernel domU. -anil > On 17 Dec 2014, at 04:34, Richard Mortier wrote: > > to check-- that's flood ping from a standard ping on linux hitting a unikernel, rather than flood pinging from within a unikernel to something else, correct? > > (don't know if it's significant but might help masoud in tracking down his issue.) > > On 17 Dec 2014, at 11:32, Anil Madhavapeddy wrote: > >> And just to confirm that we have no packet loss, I left parallel ping floods running for a day. The variance is due to the GC compactions: >> >> 478535022 packets transmitted, 478535022 received, 0% packet loss, time 42469559ms >> rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 ms >> >> -anil >> >>> On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: >>> >>> If you're running short of memory on 2GB, that indicates that there's a large amount of buffering going on. Are you seeing packet loss as a result? >>> >>> Please do make a note on the bug report that you're seeing this, and what the trigger conditions are. If you have a simple mirage-skeleton example of an Ethernet port flood that causes this, then that'll help fix it. >>> >>> -anil >>> >>>> On 16 Dec 2014, at 15:57, Masoud Koleini wrote: >>>> >>>> Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. >>>> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>>> I am wondering if the following issue is already addressed: >>>>>> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>>> >>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>>> >>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>>>> the GC parameters in the OCaml runtime to trigger a collection more often. >>>>> It should be harmless however, since (as the bug report observes), a failure >>>>> to allocate an Io_page results in a GC compaction that frees up memory so >>>>> that the allocation eventually succeeds. >>>>> >>>>> Any particular reason for asking -- is the bug affecting your switch somehow? >>>>> >>>>> -anil >>>> >>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>>> >>> >>> >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > -- > Cheers, > > R. > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ] > > > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 12:41:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 12:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DvE-0004ys-WE; Wed, 17 Dec 2014 12:41:45 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1DvE-0004yl-4d for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:41:44 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id CC/DC-14727-70A71945; Wed, 17 Dec 2014 12:41:43 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-206.messagelabs.com!1418820102!8461746!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28619 invoked from network); 17 Dec 2014 12:41:42 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 12:41:42 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 1cf1d2a7; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 12:47:35 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> Date: Wed, 17 Dec 2014 04:41:37 -0800 Message-Id: <1BDD9091-40BA-4CBC-A353-8E3E6FD04F89@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org That's correct. It's pinging from dom0 to the unikernel domU. -anil > On 17 Dec 2014, at 04:34, Richard Mortier wrote: > > to check-- that's flood ping from a standard ping on linux hitting a unikernel, rather than flood pinging from within a unikernel to something else, correct? > > (don't know if it's significant but might help masoud in tracking down his issue.) > > On 17 Dec 2014, at 11:32, Anil Madhavapeddy wrote: > >> And just to confirm that we have no packet loss, I left parallel ping floods running for a day. The variance is due to the GC compactions: >> >> 478535022 packets transmitted, 478535022 received, 0% packet loss, time 42469559ms >> rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 ms >> >> -anil >> >>> On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: >>> >>> If you're running short of memory on 2GB, that indicates that there's a large amount of buffering going on. Are you seeing packet loss as a result? >>> >>> Please do make a note on the bug report that you're seeing this, and what the trigger conditions are. If you have a simple mirage-skeleton example of an Ethernet port flood that causes this, then that'll help fix it. >>> >>> -anil >>> >>>> On 16 Dec 2014, at 15:57, Masoud Koleini wrote: >>>> >>>> Yes, I have faced this problem several times when flooding the input port (similar error on the console). The allocated memory for the switch is 2GB, which is much higher than 64MB, but I guess bit rate should be higher too. >>>> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>>> I am wondering if the following issue is already addressed: >>>>>> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>>> >>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>>> >>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>>>> the GC parameters in the OCaml runtime to trigger a collection more often. >>>>> It should be harmless however, since (as the bug report observes), a failure >>>>> to allocate an Io_page results in a GC compaction that frees up memory so >>>>> that the allocation eventually succeeds. >>>>> >>>>> Any particular reason for asking -- is the bug affecting your switch somehow? >>>>> >>>>> -anil >>>> >>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>>> >>> >>> >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > -- > Cheers, > > R. > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ] > > > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 13:01:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 13:01:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1EES-0005tu-0D; Wed, 17 Dec 2014 13:01:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1EEQ-0005tp-6x for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 13:01:34 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 87/30-25276-DAE71945; Wed, 17 Dec 2014 13:01:33 +0000 X-Env-Sender: muellerseg@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1418821290!16230381!1 X-Originating-IP: [209.85.223.181] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25446 invoked from network); 17 Dec 2014 13:01:31 -0000 Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2014 13:01:31 -0000 Received: by mail-ie0-f181.google.com with SMTP id tp5so14438308ieb.26 for ; Wed, 17 Dec 2014 05:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F6AyjDSoWZfM2xAVrAkr7W0y4Ux5e+cGKwQnb6xZ8wo=; b=RDuwkiXPc2PebfC9xTUyGQ+Yk+xsnGgiDh1OMJkb34JVRzu3VvgqS+cx7l7TS0RuwU 73sn2HSi00vtGOEJkbEPS94rmHsO6o6Jh11YyKmNIDWp4noIoNlpu3sZNg3jRQiZA+ei +M4eTW7Xnh3ekwumFjUU+yJcN9EXsAIM3Qlr1naYrotJ7MaB/ToMsA5685+RiV5gYKjE X65bAHbTQC5+hRWcX7IVwSpGcpJY95R0VAYFHfuUJB0DRPw6Z/er72ST+UpkDEBV7ajl o1lg4UJnKeDq4tdsm+WNkHaliwhBLrQ9prh8ZafsqvaLZx4L8JQl8wktXwqyWta7bFWc Yzkg== MIME-Version: 1.0 X-Received: by 10.50.50.133 with SMTP id c5mr7786389igo.15.1418821290491; Wed, 17 Dec 2014 05:01:30 -0800 (PST) Received: by 10.42.40.146 with HTTP; Wed, 17 Dec 2014 05:01:30 -0800 (PST) In-Reply-To: <1BDD9091-40BA-4CBC-A353-8E3E6FD04F89@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> <1BDD9091-40BA-4CBC-A353-8E3E6FD04F89@recoil.org> Date: Wed, 17 Dec 2014 14:01:30 +0100 Message-ID: From: Sbstn Mlr To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1166972822026847888==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1166972822026847888== Content-Type: multipart/alternative; boundary=047d7b874d0e050345050a691355 --047d7b874d0e050345050a691355 Content-Type: text/plain; charset=UTF-8 Hi, I have encountered a similar problem. Here a small example (echoes ethernet frames) running on xen: open Lwt module Main (C: V1_LWT.CONSOLE) (N: V1_LWT.NETWORK) = struct let start console network = let acceptPacket buffer = N.write network buffer in N.listen network acceptPacket end This example works fine for low traffic rates with several thousand packets per second. If I increase the packet rate to 50000 packets per second the program starts to drop packets. After a few seconds this message appears several times: Cannot handle page request order 1! memalign(4096, 4096) failed. And the program stops working. Cheers, S. 2014-12-17 13:41 GMT+01:00 Anil Madhavapeddy : > > That's correct. It's pinging from dom0 to the unikernel domU. > > -anil > > > On 17 Dec 2014, at 04:34, Richard Mortier < > Richard.Mortier@nottingham.ac.uk> wrote: > > > > to check-- that's flood ping from a standard ping on linux hitting a > unikernel, rather than flood pinging from within a unikernel to something > else, correct? > > > > (don't know if it's significant but might help masoud in tracking down > his issue.) > > > > On 17 Dec 2014, at 11:32, Anil Madhavapeddy wrote: > > > >> And just to confirm that we have no packet loss, I left parallel ping > floods running for a day. The variance is due to the GC compactions: > >> > >> 478535022 packets transmitted, 478535022 received, 0% packet loss, time > 42469559ms > >> rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 > ms > >> > >> -anil > >> > >>> On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: > >>> > >>> If you're running short of memory on 2GB, that indicates that there's > a large amount of buffering going on. Are you seeing packet loss as a > result? > >>> > >>> Please do make a note on the bug report that you're seeing this, and > what the trigger conditions are. If you have a simple mirage-skeleton > example of an Ethernet port flood that causes this, then that'll help fix > it. > >>> > >>> -anil > >>> > >>>> On 16 Dec 2014, at 15:57, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>> > >>>> Yes, I have faced this problem several times when flooding the input > port (similar error on the console). The allocated memory for the switch is > 2GB, which is much higher than 64MB, but I guess bit rate should be higher > too. > >>>> > >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: > >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>>>> I am wondering if the following issue is already addressed: > >>>>>> > >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 > >>>>>> > >>>>>> > https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html > >>>>>> > >>>>> It probably still happens at 64MB of RAM -- it requires some code to > adjust > >>>>> the GC parameters in the OCaml runtime to trigger a collection more > often. > >>>>> It should be harmless however, since (as the bug report observes), a > failure > >>>>> to allocate an Io_page results in a GC compaction that frees up > memory so > >>>>> that the allocation eventually succeeds. > >>>>> > >>>>> Any particular reason for asking -- is the bug affecting your switch > somehow? > >>>>> > >>>>> -anil > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > >>>> > >>>> This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > >>>> > >>> > >>> > >>> _______________________________________________ > >>> MirageOS-devel mailing list > >>> MirageOS-devel@lists.xenproject.org > >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >>> > >> > >> > >> _______________________________________________ > >> MirageOS-devel mailing list > >> MirageOS-devel@lists.xenproject.org > >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > > -- > > Cheers, > > > > R. > > > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk > subsequently. ] > > > > > > > > > > > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --047d7b874d0e050345050a691355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have encountered a similar proble= m. Here a small example (echoes ethernet frames) running on xen:
=

open Lwt

module Main (C: V1_LW= T.CONSOLE) (N: V1_LWT.NETWORK) =3D struct

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 let start console network =3D
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 let acceptPacket buffer =3D
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 N.write network buffer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 N.listen network acceptPacket

end

This example works fine for low traffi= c rates with several thousand packets per second.

= If I increase the packet rate to 50000 packets per second the program start= s to drop packets. After a few seconds this message appears several times:= =C2=A0

Cannot handle page request order 1!
memalign(4096, 4096) failed.

And the= program stops working.=C2=A0

Cheers,
S.=



2014-12-17 13:41 GMT+01:00 Anil Madhavapeddy <anil@recoil.org>:
That's correct.=C2=A0 It's pingi= ng from dom0 to the unikernel domU.

-anil

> On 17 Dec 2014, at 04:34, Richard Mortier <Richard.Mortier@nottingham.ac.uk> wrote:=
>
> to check-- that's flood ping from a standard ping on linux hitting= a unikernel, rather than flood pinging from within a unikernel to somethin= g else, correct?
>
> (don't know if it's significant but might help masoud in track= ing down his issue.)
>
> On 17 Dec 2014, at 11:32, Anil Madhavapeddy <anil@recoil.org> wrote:
>
>> And just to confirm that we have no packet loss, I left parallel p= ing floods running for a day.=C2=A0 The variance is due to the GC compactio= ns:
>>
>> 478535022 packets transmitted, 478535022 received, 0% packet loss,= time 42469559ms
>> rtt min/avg/max/mdev =3D 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.08= 8/0.065 ms
>>
>> -anil
>>
>>> On 16 Dec 2014, at 15:59, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>
>>> If you're running short of memory on 2GB, that indicates t= hat there's a large amount of buffering going on.=C2=A0 Are you seeing = packet loss as a result?
>>>
>>> Please do make a note on the bug report that you're seeing= this, and what the trigger conditions are.=C2=A0 If you have a simple mira= ge-skeleton example of an Ethernet port flood that causes this, then that&#= 39;ll help fix it.
>>>
>>> -anil
>>>
>>>> On 16 Dec 2014, at 15:57, Masoud Koleini <masoud.koleini@nottingham.ac.uk&g= t; wrote:
>>>>
>>>> Yes, I have faced this problem several times when flooding= the input port (similar error on the console). The allocated memory for th= e switch is 2GB, which is much higher than 64MB, but I guess bit rate shoul= d be higher too.
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk= > wrote:
>>>>>> I am wondering if the following issue is already a= ddressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/= 33
>>>>>>
>>>>>> https://lists.cam.ac.uk/p= ipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it require= s some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a co= llection more often.
>>>>> It should be harmless however, since (as the bug repor= t observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that= frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecti= ng your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for th= e addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete it= .=C2=A0 =C2=A0Please do not use, copy or disclose the information contained= in this message or in any attachment.=C2=A0 Any views or opinions expresse= d by the author of this email do not necessarily reflect the views of the U= niversity of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents= of an attachment may still contain software viruses which could damage you= r computer system, you are advised to perform your own checks. Email commun= ications with the University of Nottingham may be monitored as permitted by= UK legislation.
>>>>
>>>
>>>
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageO= S-devel@lists.xenproject.org
>>> http://lists.xenproject.org/cgi-bin/mai= lman/listinfo/mirageos-devel
>>>
>>
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-de= vel@lists.xenproject.org
>> http://lists.xenproject.org/cgi-bin/mailman= /listinfo/mirageos-devel
>
>
> --
> Cheers,
>
> R.
>
> [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ]
>
>
>
>
>
>
>
> This message and any attachment are intended solely for the addressee = and may contain confidential information. If you have received this message= in error, please send it back to me, and immediately delete it.=C2=A0 =C2= =A0Please do not use, copy or disclose the information contained in this me= ssage or in any attachment.=C2=A0 Any views or opinions expressed by the au= thor of this email do not necessarily reflect the views of the University o= f Nottingham.
>
> This message has been checked for viruses but the contents of an attac= hment may still contain software viruses which could damage your computer s= ystem, you are advised to perform your own checks. Email communications wit= h the University of Nottingham may be monitored as permitted by UK legislat= ion.
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel
--047d7b874d0e050345050a691355-- --===============1166972822026847888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1166972822026847888==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 13:01:37 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 13:01:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1EES-0005tu-0D; Wed, 17 Dec 2014 13:01:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1EEQ-0005tp-6x for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 13:01:34 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 87/30-25276-DAE71945; Wed, 17 Dec 2014 13:01:33 +0000 X-Env-Sender: muellerseg@gmail.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1418821290!16230381!1 X-Originating-IP: [209.85.223.181] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25446 invoked from network); 17 Dec 2014 13:01:31 -0000 Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2014 13:01:31 -0000 Received: by mail-ie0-f181.google.com with SMTP id tp5so14438308ieb.26 for ; Wed, 17 Dec 2014 05:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F6AyjDSoWZfM2xAVrAkr7W0y4Ux5e+cGKwQnb6xZ8wo=; b=RDuwkiXPc2PebfC9xTUyGQ+Yk+xsnGgiDh1OMJkb34JVRzu3VvgqS+cx7l7TS0RuwU 73sn2HSi00vtGOEJkbEPS94rmHsO6o6Jh11YyKmNIDWp4noIoNlpu3sZNg3jRQiZA+ei +M4eTW7Xnh3ekwumFjUU+yJcN9EXsAIM3Qlr1naYrotJ7MaB/ToMsA5685+RiV5gYKjE X65bAHbTQC5+hRWcX7IVwSpGcpJY95R0VAYFHfuUJB0DRPw6Z/er72ST+UpkDEBV7ajl o1lg4UJnKeDq4tdsm+WNkHaliwhBLrQ9prh8ZafsqvaLZx4L8JQl8wktXwqyWta7bFWc Yzkg== MIME-Version: 1.0 X-Received: by 10.50.50.133 with SMTP id c5mr7786389igo.15.1418821290491; Wed, 17 Dec 2014 05:01:30 -0800 (PST) Received: by 10.42.40.146 with HTTP; Wed, 17 Dec 2014 05:01:30 -0800 (PST) In-Reply-To: <1BDD9091-40BA-4CBC-A353-8E3E6FD04F89@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <20141217113300.BBB4F725E24_49169ECB@uidappmx05.nottingham.ac.uk> <929E25F1-3D0B-4025-9AB4-15697A2184F2@nottingham.ac.uk> <1BDD9091-40BA-4CBC-A353-8E3E6FD04F89@recoil.org> Date: Wed, 17 Dec 2014 14:01:30 +0100 Message-ID: From: Sbstn Mlr To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1166972822026847888==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1166972822026847888== Content-Type: multipart/alternative; boundary=047d7b874d0e050345050a691355 --047d7b874d0e050345050a691355 Content-Type: text/plain; charset=UTF-8 Hi, I have encountered a similar problem. Here a small example (echoes ethernet frames) running on xen: open Lwt module Main (C: V1_LWT.CONSOLE) (N: V1_LWT.NETWORK) = struct let start console network = let acceptPacket buffer = N.write network buffer in N.listen network acceptPacket end This example works fine for low traffic rates with several thousand packets per second. If I increase the packet rate to 50000 packets per second the program starts to drop packets. After a few seconds this message appears several times: Cannot handle page request order 1! memalign(4096, 4096) failed. And the program stops working. Cheers, S. 2014-12-17 13:41 GMT+01:00 Anil Madhavapeddy : > > That's correct. It's pinging from dom0 to the unikernel domU. > > -anil > > > On 17 Dec 2014, at 04:34, Richard Mortier < > Richard.Mortier@nottingham.ac.uk> wrote: > > > > to check-- that's flood ping from a standard ping on linux hitting a > unikernel, rather than flood pinging from within a unikernel to something > else, correct? > > > > (don't know if it's significant but might help masoud in tracking down > his issue.) > > > > On 17 Dec 2014, at 11:32, Anil Madhavapeddy wrote: > > > >> And just to confirm that we have no packet loss, I left parallel ping > floods running for a day. The variance is due to the GC compactions: > >> > >> 478535022 packets transmitted, 478535022 received, 0% packet loss, time > 42469559ms > >> rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 > ms > >> > >> -anil > >> > >>> On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: > >>> > >>> If you're running short of memory on 2GB, that indicates that there's > a large amount of buffering going on. Are you seeing packet loss as a > result? > >>> > >>> Please do make a note on the bug report that you're seeing this, and > what the trigger conditions are. If you have a simple mirage-skeleton > example of an Ethernet port flood that causes this, then that'll help fix > it. > >>> > >>> -anil > >>> > >>>> On 16 Dec 2014, at 15:57, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>> > >>>> Yes, I have faced this problem several times when flooding the input > port (similar error on the console). The allocated memory for the switch is > 2GB, which is much higher than 64MB, but I guess bit rate should be higher > too. > >>>> > >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: > >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>>>> I am wondering if the following issue is already addressed: > >>>>>> > >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 > >>>>>> > >>>>>> > https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html > >>>>>> > >>>>> It probably still happens at 64MB of RAM -- it requires some code to > adjust > >>>>> the GC parameters in the OCaml runtime to trigger a collection more > often. > >>>>> It should be harmless however, since (as the bug report observes), a > failure > >>>>> to allocate an Io_page results in a GC compaction that frees up > memory so > >>>>> that the allocation eventually succeeds. > >>>>> > >>>>> Any particular reason for asking -- is the bug affecting your switch > somehow? > >>>>> > >>>>> -anil > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > >>>> > >>>> This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > >>>> > >>> > >>> > >>> _______________________________________________ > >>> MirageOS-devel mailing list > >>> MirageOS-devel@lists.xenproject.org > >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >>> > >> > >> > >> _______________________________________________ > >> MirageOS-devel mailing list > >> MirageOS-devel@lists.xenproject.org > >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > > -- > > Cheers, > > > > R. > > > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk > subsequently. ] > > > > > > > > > > > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --047d7b874d0e050345050a691355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have encountered a similar proble= m. Here a small example (echoes ethernet frames) running on xen:
=

open Lwt

module Main (C: V1_LW= T.CONSOLE) (N: V1_LWT.NETWORK) =3D struct

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 let start console network =3D
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 let acceptPacket buffer =3D
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 N.write network buffer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 N.listen network acceptPacket

end

This example works fine for low traffi= c rates with several thousand packets per second.

= If I increase the packet rate to 50000 packets per second the program start= s to drop packets. After a few seconds this message appears several times:= =C2=A0

Cannot handle page request order 1!
memalign(4096, 4096) failed.

And the= program stops working.=C2=A0

Cheers,
S.=



2014-12-17 13:41 GMT+01:00 Anil Madhavapeddy <anil@recoil.org>:
That's correct.=C2=A0 It's pingi= ng from dom0 to the unikernel domU.

-anil

> On 17 Dec 2014, at 04:34, Richard Mortier <Richard.Mortier@nottingham.ac.uk> wrote:=
>
> to check-- that's flood ping from a standard ping on linux hitting= a unikernel, rather than flood pinging from within a unikernel to somethin= g else, correct?
>
> (don't know if it's significant but might help masoud in track= ing down his issue.)
>
> On 17 Dec 2014, at 11:32, Anil Madhavapeddy <anil@recoil.org> wrote:
>
>> And just to confirm that we have no packet loss, I left parallel p= ing floods running for a day.=C2=A0 The variance is due to the GC compactio= ns:
>>
>> 478535022 packets transmitted, 478535022 received, 0% packet loss,= time 42469559ms
>> rtt min/avg/max/mdev =3D 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.08= 8/0.065 ms
>>
>> -anil
>>
>>> On 16 Dec 2014, at 15:59, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>
>>> If you're running short of memory on 2GB, that indicates t= hat there's a large amount of buffering going on.=C2=A0 Are you seeing = packet loss as a result?
>>>
>>> Please do make a note on the bug report that you're seeing= this, and what the trigger conditions are.=C2=A0 If you have a simple mira= ge-skeleton example of an Ethernet port flood that causes this, then that&#= 39;ll help fix it.
>>>
>>> -anil
>>>
>>>> On 16 Dec 2014, at 15:57, Masoud Koleini <masoud.koleini@nottingham.ac.uk&g= t; wrote:
>>>>
>>>> Yes, I have faced this problem several times when flooding= the input port (similar error on the console). The allocated memory for th= e switch is 2GB, which is much higher than 64MB, but I guess bit rate shoul= d be higher too.
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk= > wrote:
>>>>>> I am wondering if the following issue is already a= ddressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/= 33
>>>>>>
>>>>>> https://lists.cam.ac.uk/p= ipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it require= s some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a co= llection more often.
>>>>> It should be harmless however, since (as the bug repor= t observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that= frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecti= ng your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for th= e addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete it= .=C2=A0 =C2=A0Please do not use, copy or disclose the information contained= in this message or in any attachment.=C2=A0 Any views or opinions expresse= d by the author of this email do not necessarily reflect the views of the U= niversity of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents= of an attachment may still contain software viruses which could damage you= r computer system, you are advised to perform your own checks. Email commun= ications with the University of Nottingham may be monitored as permitted by= UK legislation.
>>>>
>>>
>>>
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageO= S-devel@lists.xenproject.org
>>> http://lists.xenproject.org/cgi-bin/mai= lman/listinfo/mirageos-devel
>>>
>>
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-de= vel@lists.xenproject.org
>> http://lists.xenproject.org/cgi-bin/mailman= /listinfo/mirageos-devel
>
>
> --
> Cheers,
>
> R.
>
> [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ]
>
>
>
>
>
>
>
> This message and any attachment are intended solely for the addressee = and may contain confidential information. If you have received this message= in error, please send it back to me, and immediately delete it.=C2=A0 =C2= =A0Please do not use, copy or disclose the information contained in this me= ssage or in any attachment.=C2=A0 Any views or opinions expressed by the au= thor of this email do not necessarily reflect the views of the University o= f Nottingham.
>
> This message has been checked for viruses but the contents of an attac= hment may still contain software viruses which could damage your computer s= ystem, you are advised to perform your own checks. Email communications wit= h the University of Nottingham may be monitored as permitted by UK legislat= ion.
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel
--047d7b874d0e050345050a691355-- --===============1166972822026847888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1166972822026847888==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 14:29:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 14:29:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1FbQ-00005W-De; Wed, 17 Dec 2014 14:29:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1FbO-00005R-Hk for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 14:29:22 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 5A/83-22737-14391945; Wed, 17 Dec 2014 14:29:21 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1418826560!9777798!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31001 invoked from network); 17 Dec 2014 14:29:20 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2014 14:29:20 -0000 Received: by mail-lb0-f171.google.com with SMTP id w7so8616151lbi.30 for ; Wed, 17 Dec 2014 06:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PaM3MCijbL5Oe8c77KOmozWCtYQsGxXzHEm28/weehY=; b=FrxEL75LOWqgAEumem9QbLqnRfGBlFju8PQQIkVr3Xf4xy7TdBV41K20wVvii/0TjE pLnqUq4OYpMupxyGR8mdeRC/kxN6RypC1NAiizqO9kJCH1mLjm1b7JUwj3PFA+T65+20 Lndv/kTaic2CgdPnYXNi6Nh44RiNRMtU8DkprsR5hxIU0wl425yhTGcrtDDAxPyoNdUO A6fULlkfa5ENUqI83qyl4vThTeHieaEb0fC5hgWDEfmnlyd0svpQfrLIetAEDL4PW/mu C9w/CT4FJw/ecLR9MeAF649lLtCAC2iEJQCSfljSFPs0EJyQ61WdsVtwfli6TCH+pZdr WxTQ== MIME-Version: 1.0 X-Received: by 10.112.135.197 with SMTP id pu5mr41126857lbb.22.1418826559892; Wed, 17 Dec 2014 06:29:19 -0800 (PST) Received: by 10.25.207.3 with HTTP; Wed, 17 Dec 2014 06:29:19 -0800 (PST) Date: Wed, 17 Dec 2014 14:29:19 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org The TLS work requires ctypes and zarith to run on Xen. I now have ctypes building with Xen support, but zarith is more difficult. Hannes previously got it to work here: http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html However, this was compiling against the local (e.g. Linux) headers, not the Mini-OS ones. It seems to work, but it's obviously not ideal. If we simply add the Mini-OS headers to the gcc search path, then things actually get worse, because they're inconsistent with the system headers. In particular, gmp probes for various header files, finds some Linux-specific ones, and then gets upset when they don't work. Ideally, Mini-OS would compile with -nostdinc and provide all the headers it needs itself. Unfortunately, this requires adding a lot of standard headers with information the C compiler already knows. It seems you can't do this automatically: http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc I tried adding the ones that seemed to be missing. These were needed to compile Mini-OS itself with -nostdinc: inttypes.h limits.h stdarg.h stddef.h stdint.h strings.h However, to compile other programs (e.g. openlibm) requires more. For example: sys/cdefs.h complex.h (this is as far as I've got) In short, there's a fair bit of work needed to get everything compiling against the correct headers. It's also not completely clear to me how to package 3rd-party libraries such as zarith, which are unlikely to accept patches for our xen_linkopts system (which is essentially a hack around the current lack of cross-compilation support in opam). We previously discussed adding opam depexts to the official package, pointing to our own zarith-xen package for the C stubs. However, this relies on our package providing exactly the correct versions of the C stubs to work with the main package. Not impossible with some version constraints, but it seems messy. Another option is to have our own mirage-zarith package and get everything to depend on that. But we'll be incompatible with any OCaml library using the official version then. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 14:29:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 14:29:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1FbQ-00005W-De; Wed, 17 Dec 2014 14:29:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1FbO-00005R-Hk for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 14:29:22 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 5A/83-22737-14391945; Wed, 17 Dec 2014 14:29:21 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1418826560!9777798!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31001 invoked from network); 17 Dec 2014 14:29:20 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2014 14:29:20 -0000 Received: by mail-lb0-f171.google.com with SMTP id w7so8616151lbi.30 for ; Wed, 17 Dec 2014 06:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PaM3MCijbL5Oe8c77KOmozWCtYQsGxXzHEm28/weehY=; b=FrxEL75LOWqgAEumem9QbLqnRfGBlFju8PQQIkVr3Xf4xy7TdBV41K20wVvii/0TjE pLnqUq4OYpMupxyGR8mdeRC/kxN6RypC1NAiizqO9kJCH1mLjm1b7JUwj3PFA+T65+20 Lndv/kTaic2CgdPnYXNi6Nh44RiNRMtU8DkprsR5hxIU0wl425yhTGcrtDDAxPyoNdUO A6fULlkfa5ENUqI83qyl4vThTeHieaEb0fC5hgWDEfmnlyd0svpQfrLIetAEDL4PW/mu C9w/CT4FJw/ecLR9MeAF649lLtCAC2iEJQCSfljSFPs0EJyQ61WdsVtwfli6TCH+pZdr WxTQ== MIME-Version: 1.0 X-Received: by 10.112.135.197 with SMTP id pu5mr41126857lbb.22.1418826559892; Wed, 17 Dec 2014 06:29:19 -0800 (PST) Received: by 10.25.207.3 with HTTP; Wed, 17 Dec 2014 06:29:19 -0800 (PST) Date: Wed, 17 Dec 2014 14:29:19 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org The TLS work requires ctypes and zarith to run on Xen. I now have ctypes building with Xen support, but zarith is more difficult. Hannes previously got it to work here: http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html However, this was compiling against the local (e.g. Linux) headers, not the Mini-OS ones. It seems to work, but it's obviously not ideal. If we simply add the Mini-OS headers to the gcc search path, then things actually get worse, because they're inconsistent with the system headers. In particular, gmp probes for various header files, finds some Linux-specific ones, and then gets upset when they don't work. Ideally, Mini-OS would compile with -nostdinc and provide all the headers it needs itself. Unfortunately, this requires adding a lot of standard headers with information the C compiler already knows. It seems you can't do this automatically: http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc I tried adding the ones that seemed to be missing. These were needed to compile Mini-OS itself with -nostdinc: inttypes.h limits.h stdarg.h stddef.h stdint.h strings.h However, to compile other programs (e.g. openlibm) requires more. For example: sys/cdefs.h complex.h (this is as far as I've got) In short, there's a fair bit of work needed to get everything compiling against the correct headers. It's also not completely clear to me how to package 3rd-party libraries such as zarith, which are unlikely to accept patches for our xen_linkopts system (which is essentially a hack around the current lack of cross-compilation support in opam). We previously discussed adding opam depexts to the official package, pointing to our own zarith-xen package for the C stubs. However, this relies on our package providing exactly the correct versions of the C stubs to work with the main package. Not impossible with some version constraints, but it seems messy. Another option is to have our own mirage-zarith package and get everything to depend on that. But we'll be incompatible with any OCaml library using the official version then. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 14:41:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 14:41:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Fmo-0000Lk-CR; Wed, 17 Dec 2014 14:41:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Fmm-0000Lf-Gw for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 14:41:08 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id EB/93-25547-30691945; Wed, 17 Dec 2014 14:41:07 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-3.tower-31.messagelabs.com!1418827266!14101250!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10721 invoked from network); 17 Dec 2014 14:41:06 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 14:41:06 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 311c14ac; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 14:47:01 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 17 Dec 2014 06:41:01 -0800 Message-Id: <4654F66B-C4EB-48E6-B4D0-19044C02ED52@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 Dec 2014, at 06:29, Thomas Leonard wrote: > > The TLS work requires ctypes and zarith to run on Xen. I now have > ctypes building with Xen support, but zarith is more difficult. > > Hannes previously got it to work here: > > http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html > > However, this was compiling against the local (e.g. Linux) headers, > not the Mini-OS ones. It seems to work, but it's obviously not ideal. > > If we simply add the Mini-OS headers to the gcc search path, then > things actually get worse, because they're inconsistent with the > system headers. In particular, gmp probes for various header files, > finds some Linux-specific ones, and then gets upset when they don't > work. > > Ideally, Mini-OS would compile with -nostdinc and provide all the > headers it needs itself. Unfortunately, this requires adding a lot of > standard headers with information the C compiler already knows. It > seems you can't do this automatically: > > http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc > > I tried adding the ones that seemed to be missing. These were needed > to compile Mini-OS itself with -nostdinc: > > inttypes.h > limits.h > stdarg.h > stddef.h > stdint.h > strings.h > > However, to compile other programs (e.g. openlibm) requires more. For example: > > sys/cdefs.h > complex.h > > (this is as far as I've got) > > In short, there's a fair bit of work needed to get everything > compiling against the correct headers. MiniOS uses the gcc search path to find some of these headers; https://github.com/mirage/xen/blob/master/stubdom/Makefile#L35 # Do not use host headers and libs GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ TARGET_CPPFLAGS += -nostdinc TARGET_CPPFLAGS += -isystem $(MINI_OS)/include/posix TARGET_CPPFLAGS += -isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include TARGET_CPPFLAGS += -isystem $(GCC_INSTALL)include Does something like this help, or is the problem the include_next of stdint.h that means that it's needed on the search path anyway? > It's also not completely clear to me how to package 3rd-party > libraries such as zarith, which are unlikely to accept patches for our > xen_linkopts system (which is essentially a hack around the current > lack of cross-compilation support in opam). > > We previously discussed adding opam depexts to the official package, > pointing to our own zarith-xen package for the C stubs. However, this > relies on our package providing exactly the correct versions of the C > stubs to work with the main package. Not impossible with some version > constraints, but it seems messy. It's a little messy, but it would work with the version constraints (especially given how infrequently zarith is updated). Best option for now? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 14:41:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 14:41:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Fmo-0000Lk-CR; Wed, 17 Dec 2014 14:41:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Fmm-0000Lf-Gw for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 14:41:08 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id EB/93-25547-30691945; Wed, 17 Dec 2014 14:41:07 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-3.tower-31.messagelabs.com!1418827266!14101250!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10721 invoked from network); 17 Dec 2014 14:41:06 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 14:41:06 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 311c14ac; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 14:47:01 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 17 Dec 2014 06:41:01 -0800 Message-Id: <4654F66B-C4EB-48E6-B4D0-19044C02ED52@recoil.org> References: To: Thomas Leonard X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 Dec 2014, at 06:29, Thomas Leonard wrote: > > The TLS work requires ctypes and zarith to run on Xen. I now have > ctypes building with Xen support, but zarith is more difficult. > > Hannes previously got it to work here: > > http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html > > However, this was compiling against the local (e.g. Linux) headers, > not the Mini-OS ones. It seems to work, but it's obviously not ideal. > > If we simply add the Mini-OS headers to the gcc search path, then > things actually get worse, because they're inconsistent with the > system headers. In particular, gmp probes for various header files, > finds some Linux-specific ones, and then gets upset when they don't > work. > > Ideally, Mini-OS would compile with -nostdinc and provide all the > headers it needs itself. Unfortunately, this requires adding a lot of > standard headers with information the C compiler already knows. It > seems you can't do this automatically: > > http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc > > I tried adding the ones that seemed to be missing. These were needed > to compile Mini-OS itself with -nostdinc: > > inttypes.h > limits.h > stdarg.h > stddef.h > stdint.h > strings.h > > However, to compile other programs (e.g. openlibm) requires more. For example: > > sys/cdefs.h > complex.h > > (this is as far as I've got) > > In short, there's a fair bit of work needed to get everything > compiling against the correct headers. MiniOS uses the gcc search path to find some of these headers; https://github.com/mirage/xen/blob/master/stubdom/Makefile#L35 # Do not use host headers and libs GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ TARGET_CPPFLAGS += -nostdinc TARGET_CPPFLAGS += -isystem $(MINI_OS)/include/posix TARGET_CPPFLAGS += -isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include TARGET_CPPFLAGS += -isystem $(GCC_INSTALL)include Does something like this help, or is the problem the include_next of stdint.h that means that it's needed on the search path anyway? > It's also not completely clear to me how to package 3rd-party > libraries such as zarith, which are unlikely to accept patches for our > xen_linkopts system (which is essentially a hack around the current > lack of cross-compilation support in opam). > > We previously discussed adding opam depexts to the official package, > pointing to our own zarith-xen package for the C stubs. However, this > relies on our package providing exactly the correct versions of the C > stubs to work with the main package. Not impossible with some version > constraints, but it seems messy. It's a little messy, but it would work with the version constraints (especially given how infrequently zarith is updated). Best option for now? -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 15:06:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 15:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1GB2-00014C-CA; Wed, 17 Dec 2014 15:06:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1GAr-000144-9a for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 15:06:01 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id 4F/23-17735-8DB91945; Wed, 17 Dec 2014 15:06:00 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1418828758!14061942!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1553 invoked from network); 17 Dec 2014 15:05:59 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2014 15:05:59 -0000 Received: by mail-la0-f43.google.com with SMTP id s18so13377910lam.30 for ; Wed, 17 Dec 2014 07:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5s7apnoPf35xZXJBi68DHJ0OWEAvRZw5+JKAAWrUQgo=; b=iX/rNVFdIb5gkMxtbl6vnw1FaYeEC82iUwsNZohtPq+HCq8L9tmPFEfFRIA45Wy6qw AjuK34POq47N1U82MfIu8JCmQxz8xTaFSuq0F/MI6Wj2fgYB8ZlSM8xhAU4MGhYekpWu MTIUC4dyRnd3P4VufloZT9y9dQh1T07VzKJG+u6CB+PJ+YcHsUbzEoxmWWhMC50rJdMP x1JMgaOeCia5/XSqlVVvcRz23Jc6pYTVrr2OonQlRBsqABhTd1YmyYTFNmx0I7u5B3pk Qg9NS6Re8vifFCJQ9SMR5cFVD+VLyh4Iqp4lNud7UMqb9p74C0LbzeYeP5tm8nSaUWG4 WPFw== MIME-Version: 1.0 X-Received: by 10.152.25.129 with SMTP id c1mr42335984lag.9.1418828758405; Wed, 17 Dec 2014 07:05:58 -0800 (PST) Received: by 10.25.207.3 with HTTP; Wed, 17 Dec 2014 07:05:58 -0800 (PST) In-Reply-To: <4654F66B-C4EB-48E6-B4D0-19044C02ED52@recoil.org> References: <4654F66B-C4EB-48E6-B4D0-19044C02ED52@recoil.org> Date: Wed, 17 Dec 2014 15:05:58 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 14:41, Anil Madhavapeddy wrote: > On 17 Dec 2014, at 06:29, Thomas Leonard wrote: >> >> The TLS work requires ctypes and zarith to run on Xen. I now have >> ctypes building with Xen support, but zarith is more difficult. >> >> Hannes previously got it to work here: >> >> http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html >> >> However, this was compiling against the local (e.g. Linux) headers, >> not the Mini-OS ones. It seems to work, but it's obviously not ideal. >> >> If we simply add the Mini-OS headers to the gcc search path, then >> things actually get worse, because they're inconsistent with the >> system headers. In particular, gmp probes for various header files, >> finds some Linux-specific ones, and then gets upset when they don't >> work. >> >> Ideally, Mini-OS would compile with -nostdinc and provide all the >> headers it needs itself. Unfortunately, this requires adding a lot of >> standard headers with information the C compiler already knows. It >> seems you can't do this automatically: >> >> http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc >> >> I tried adding the ones that seemed to be missing. These were needed >> to compile Mini-OS itself with -nostdinc: >> >> inttypes.h >> limits.h >> stdarg.h >> stddef.h >> stdint.h >> strings.h >> >> However, to compile other programs (e.g. openlibm) requires more. For example: >> >> sys/cdefs.h >> complex.h >> >> (this is as far as I've got) >> >> In short, there's a fair bit of work needed to get everything >> compiling against the correct headers. > > MiniOS uses the gcc search path to find some of these headers; > https://github.com/mirage/xen/blob/master/stubdom/Makefile#L35 > > # Do not use host headers and libs > GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') > TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ > TARGET_CPPFLAGS += -nostdinc > TARGET_CPPFLAGS += -isystem $(MINI_OS)/include/posix > TARGET_CPPFLAGS += -isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include > TARGET_CPPFLAGS += -isystem $(GCC_INSTALL)include > > Does something like this help, or is the problem the include_next > of stdint.h that means that it's needed on the search path anyway? Ah, that saves finding BSD-licensed versions to include! Strange that they use it for building the stubdoms against Mini-OS, but not for Mini-OS itself. There was an include_next problem somewhere, but I can't remember where. I think it could be avoided with the freestanding option, but I'm not sure what other effects that has (as I recall, it resulted in less efficient code, anyway). >> It's also not completely clear to me how to package 3rd-party >> libraries such as zarith, which are unlikely to accept patches for our >> xen_linkopts system (which is essentially a hack around the current >> lack of cross-compilation support in opam). >> >> We previously discussed adding opam depexts to the official package, >> pointing to our own zarith-xen package for the C stubs. However, this >> relies on our package providing exactly the correct versions of the C >> stubs to work with the main package. Not impossible with some version >> constraints, but it seems messy. > > It's a little messy, but it would work with the version constraints > (especially given how infrequently zarith is updated). Best option > for now? > > -anil -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 15:06:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 15:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1GB2-00014C-CA; Wed, 17 Dec 2014 15:06:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1GAr-000144-9a for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 15:06:01 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id 4F/23-17735-8DB91945; Wed, 17 Dec 2014 15:06:00 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1418828758!14061942!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1553 invoked from network); 17 Dec 2014 15:05:59 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 17 Dec 2014 15:05:59 -0000 Received: by mail-la0-f43.google.com with SMTP id s18so13377910lam.30 for ; Wed, 17 Dec 2014 07:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5s7apnoPf35xZXJBi68DHJ0OWEAvRZw5+JKAAWrUQgo=; b=iX/rNVFdIb5gkMxtbl6vnw1FaYeEC82iUwsNZohtPq+HCq8L9tmPFEfFRIA45Wy6qw AjuK34POq47N1U82MfIu8JCmQxz8xTaFSuq0F/MI6Wj2fgYB8ZlSM8xhAU4MGhYekpWu MTIUC4dyRnd3P4VufloZT9y9dQh1T07VzKJG+u6CB+PJ+YcHsUbzEoxmWWhMC50rJdMP x1JMgaOeCia5/XSqlVVvcRz23Jc6pYTVrr2OonQlRBsqABhTd1YmyYTFNmx0I7u5B3pk Qg9NS6Re8vifFCJQ9SMR5cFVD+VLyh4Iqp4lNud7UMqb9p74C0LbzeYeP5tm8nSaUWG4 WPFw== MIME-Version: 1.0 X-Received: by 10.152.25.129 with SMTP id c1mr42335984lag.9.1418828758405; Wed, 17 Dec 2014 07:05:58 -0800 (PST) Received: by 10.25.207.3 with HTTP; Wed, 17 Dec 2014 07:05:58 -0800 (PST) In-Reply-To: <4654F66B-C4EB-48E6-B4D0-19044C02ED52@recoil.org> References: <4654F66B-C4EB-48E6-B4D0-19044C02ED52@recoil.org> Date: Wed, 17 Dec 2014 15:05:58 +0000 Message-ID: From: Thomas Leonard To: Anil Madhavapeddy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 14:41, Anil Madhavapeddy wrote: > On 17 Dec 2014, at 06:29, Thomas Leonard wrote: >> >> The TLS work requires ctypes and zarith to run on Xen. I now have >> ctypes building with Xen support, but zarith is more difficult. >> >> Hannes previously got it to work here: >> >> http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html >> >> However, this was compiling against the local (e.g. Linux) headers, >> not the Mini-OS ones. It seems to work, but it's obviously not ideal. >> >> If we simply add the Mini-OS headers to the gcc search path, then >> things actually get worse, because they're inconsistent with the >> system headers. In particular, gmp probes for various header files, >> finds some Linux-specific ones, and then gets upset when they don't >> work. >> >> Ideally, Mini-OS would compile with -nostdinc and provide all the >> headers it needs itself. Unfortunately, this requires adding a lot of >> standard headers with information the C compiler already knows. It >> seems you can't do this automatically: >> >> http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc >> >> I tried adding the ones that seemed to be missing. These were needed >> to compile Mini-OS itself with -nostdinc: >> >> inttypes.h >> limits.h >> stdarg.h >> stddef.h >> stdint.h >> strings.h >> >> However, to compile other programs (e.g. openlibm) requires more. For example: >> >> sys/cdefs.h >> complex.h >> >> (this is as far as I've got) >> >> In short, there's a fair bit of work needed to get everything >> compiling against the correct headers. > > MiniOS uses the gcc search path to find some of these headers; > https://github.com/mirage/xen/blob/master/stubdom/Makefile#L35 > > # Do not use host headers and libs > GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') > TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ > TARGET_CPPFLAGS += -nostdinc > TARGET_CPPFLAGS += -isystem $(MINI_OS)/include/posix > TARGET_CPPFLAGS += -isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include > TARGET_CPPFLAGS += -isystem $(GCC_INSTALL)include > > Does something like this help, or is the problem the include_next > of stdint.h that means that it's needed on the search path anyway? Ah, that saves finding BSD-licensed versions to include! Strange that they use it for building the stubdoms against Mini-OS, but not for Mini-OS itself. There was an include_next problem somewhere, but I can't remember where. I think it could be avoided with the freestanding option, but I'm not sure what other effects that has (as I recall, it resulted in less efficient code, anyway). >> It's also not completely clear to me how to package 3rd-party >> libraries such as zarith, which are unlikely to accept patches for our >> xen_linkopts system (which is essentially a hack around the current >> lack of cross-compilation support in opam). >> >> We previously discussed adding opam depexts to the official package, >> pointing to our own zarith-xen package for the C stubs. However, this >> relies on our package providing exactly the correct versions of the C >> stubs to work with the main package. Not impossible with some version >> constraints, but it seems messy. > > It's a little messy, but it would work with the version constraints > (especially given how infrequently zarith is updated). Best option > for now? > > -anil -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 16:08:29 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 16:08:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1H9C-0000YB-TS; Wed, 17 Dec 2014 16:08:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1H9B-0000Y6-5Q for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 16:08:21 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 92/AB-27785-47AA1945; Wed, 17 Dec 2014 16:08:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1418832499!15724481!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24018 invoked from network); 17 Dec 2014 16:08:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 16:08:19 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id b622457c; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 16:14:15 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy Date: Wed, 17 Dec 2014 08:08:18 -0800 Message-Id: <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> To: mirageos-devel X-Mailer: Apple Mail (2.1993) Cc: Lars Kurth Subject: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. -anil > Begin forwarded message: > > From: Lars Kurth > Subject: Xen Booth @ FOSDEM - call for demo's at the booth > Date: 17 December 2014 07:17:09 GMT-8 > To: publicity@lists.xenproject.org > > Hi all, > I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know > a) What days you will be at FOSDEM > b) What you'd demonstrate - a headline + a paragraph > Regards > Lars _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 16:08:29 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 16:08:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1H9C-0000YB-TS; Wed, 17 Dec 2014 16:08:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1H9B-0000Y6-5Q for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 16:08:21 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 92/AB-27785-47AA1945; Wed, 17 Dec 2014 16:08:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-27.messagelabs.com!1418832499!15724481!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24018 invoked from network); 17 Dec 2014 16:08:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 16:08:19 -0000 Received: from [192.168.4.225] (12.207.17.3 [12.207.17.3]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id b622457c; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 16:14:15 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy Date: Wed, 17 Dec 2014 08:08:18 -0800 Message-Id: <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> To: mirageos-devel X-Mailer: Apple Mail (2.1993) Cc: Lars Kurth Subject: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. -anil > Begin forwarded message: > > From: Lars Kurth > Subject: Xen Booth @ FOSDEM - call for demo's at the booth > Date: 17 December 2014 07:17:09 GMT-8 > To: publicity@lists.xenproject.org > > Hi all, > I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know > a) What days you will be at FOSDEM > b) What you'd demonstrate - a headline + a paragraph > Regards > Lars _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 18:06:11 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 18:06:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Iz8-00066q-CP; Wed, 17 Dec 2014 18:06:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Iz7-00066l-Gl for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 18:06:05 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id F8/56-02697-C06C1945; Wed, 17 Dec 2014 18:06:04 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-206.messagelabs.com!1418839563!6364176!1 X-Originating-IP: [128.243.43.120] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26160 invoked from network); 17 Dec 2014 18:06:03 -0000 Received: from uidappmx05.nottingham.ac.uk (HELO uidappmx05.nottingham.ac.uk) (128.243.43.120) by server-3.tower-206.messagelabs.com with SMTP; 17 Dec 2014 18:06:03 -0000 Received: from uidappmx05.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7864D725E3F_491C60BB for ; Wed, 17 Dec 2014 18:06:03 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx05.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 0C7D87183CE_491C60BF for ; Wed, 17 Dec 2014 18:06:03 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1Iz5-0005kb-03; Wed, 17 Dec 2014 18:06:03 +0000 Message-ID: <5491C606.500@nottingham.ac.uk> Date: Wed, 17 Dec 2014 18:05:58 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard , Anil Madhavapeddy References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks Thomas for the great tracing tool! The following is a very simple unikernel with two interfaces, which redirects frames captured on the first interface to the second one: https://github.com/koleini/parallelisation The problem is that in a high packet rate (more than 80'000 pps), switch stops receiving. The goal is to spot the problem and enhance the throughput of Mirage netif. Test environment consists of another vm running a traffic generator and sending frames of a specific pattern (UDP frames of size 100 bytes) over the bridge that connects to the first interface of the unikernel. Unikernel forwards frames by collecting a number of frames from input queue and running the same number of threads that write them to the output interface. Two trace files are uploaded to the repo. The first file is the output of this configuration. This trace shows that each netif write locks until the thread that writes on the front-end connection to the ring is returned (function write_already_locked.) For the second trace, the return of the thread is ignored (commenting out "lwt () = th in" in write_already_locked). This considerably increases switching speed, but after some running time, it looks that after garbage collection, similar problem happens. Thomas and Anil, any idea from given traces, and how it is possible to make the traces more informative? Thanks. On 28/11/14 16:55, Thomas Leonard wrote: > On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>> On 28 Nov 2014, at 16:03, Masoud Koleini wrote: >>> >>> Thanks Anil. >>> >>>> - graph the ring utilisation to see if it's always full (Thomas Leonard's profiling patches should help here) >>> Would you please point me out to the profiling patches? >> See: http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ > The installation instructions here are for the previous version > (though they should still work). If you want to try the latest > version, the current Git mirage allows you to pass a ~tracing argument > to "register" in your config.ml, e.g. > > let tracing = mprof_trace ~size:1000000 () in > register "myunikernel" ~tracing [ > main $ ... > ] > > This uses a newer version of the profiling API. You should generally > "opam pin" the #tracing2 branches rather than #tracing to use it. > > Note also that it doesn't currently record ring utilisation, so you'll > still need to do some work to get that. You could use the > MProf.Counter interface, in which case the GUI will display it as a > graph over the trace. > >>>> - try to reduce the parallelisation to see if some condition there alleviates the issue to track it down. >>> Reducing the maximum number of threads running in parallel reduced CPU utilization, and vm was functioning for a much longer time, but the same problem occurred at the end. >>> >>> It might be more useful looking at the code. Please have a look at the function "f_thread" in the file uploaded on the following repo: >>> >>> https://github.com/koleini/parallelisation >> That's a lot of code to try and distill down a test case. Try to cut it down significantly by building a minimal Ethernet traffic generator that outputs frames with a predictable pattern in the frame, and a receiver that will check that the pattern is received as expected. >> >> Then you can try out your parallel algorithm variations on the simple Ethernet sender/receiver and narrow down the problem without all the other concerns. >> >> Once the bug is tracked down, we can add the sender/receiver into mirage-skeleton and use it as a test case to ensure that this functional never regresses in the future. Line rate Ethernet transmission has worked in the past, but we never added a test case to ensure it stays working. >> >> Anil >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 18:06:11 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 18:06:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Iz8-00066q-CP; Wed, 17 Dec 2014 18:06:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Iz7-00066l-Gl for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 18:06:05 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id F8/56-02697-C06C1945; Wed, 17 Dec 2014 18:06:04 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-206.messagelabs.com!1418839563!6364176!1 X-Originating-IP: [128.243.43.120] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26160 invoked from network); 17 Dec 2014 18:06:03 -0000 Received: from uidappmx05.nottingham.ac.uk (HELO uidappmx05.nottingham.ac.uk) (128.243.43.120) by server-3.tower-206.messagelabs.com with SMTP; 17 Dec 2014 18:06:03 -0000 Received: from uidappmx05.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7864D725E3F_491C60BB for ; Wed, 17 Dec 2014 18:06:03 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx05.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 0C7D87183CE_491C60BF for ; Wed, 17 Dec 2014 18:06:03 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1Iz5-0005kb-03; Wed, 17 Dec 2014 18:06:03 +0000 Message-ID: <5491C606.500@nottingham.ac.uk> Date: Wed, 17 Dec 2014 18:05:58 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard , Anil Madhavapeddy References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Thanks Thomas for the great tracing tool! The following is a very simple unikernel with two interfaces, which redirects frames captured on the first interface to the second one: https://github.com/koleini/parallelisation The problem is that in a high packet rate (more than 80'000 pps), switch stops receiving. The goal is to spot the problem and enhance the throughput of Mirage netif. Test environment consists of another vm running a traffic generator and sending frames of a specific pattern (UDP frames of size 100 bytes) over the bridge that connects to the first interface of the unikernel. Unikernel forwards frames by collecting a number of frames from input queue and running the same number of threads that write them to the output interface. Two trace files are uploaded to the repo. The first file is the output of this configuration. This trace shows that each netif write locks until the thread that writes on the front-end connection to the ring is returned (function write_already_locked.) For the second trace, the return of the thread is ignored (commenting out "lwt () = th in" in write_already_locked). This considerably increases switching speed, but after some running time, it looks that after garbage collection, similar problem happens. Thomas and Anil, any idea from given traces, and how it is possible to make the traces more informative? Thanks. On 28/11/14 16:55, Thomas Leonard wrote: > On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>> On 28 Nov 2014, at 16:03, Masoud Koleini wrote: >>> >>> Thanks Anil. >>> >>>> - graph the ring utilisation to see if it's always full (Thomas Leonard's profiling patches should help here) >>> Would you please point me out to the profiling patches? >> See: http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ > The installation instructions here are for the previous version > (though they should still work). If you want to try the latest > version, the current Git mirage allows you to pass a ~tracing argument > to "register" in your config.ml, e.g. > > let tracing = mprof_trace ~size:1000000 () in > register "myunikernel" ~tracing [ > main $ ... > ] > > This uses a newer version of the profiling API. You should generally > "opam pin" the #tracing2 branches rather than #tracing to use it. > > Note also that it doesn't currently record ring utilisation, so you'll > still need to do some work to get that. You could use the > MProf.Counter interface, in which case the GUI will display it as a > graph over the trace. > >>>> - try to reduce the parallelisation to see if some condition there alleviates the issue to track it down. >>> Reducing the maximum number of threads running in parallel reduced CPU utilization, and vm was functioning for a much longer time, but the same problem occurred at the end. >>> >>> It might be more useful looking at the code. Please have a look at the function "f_thread" in the file uploaded on the following repo: >>> >>> https://github.com/koleini/parallelisation >> That's a lot of code to try and distill down a test case. Try to cut it down significantly by building a minimal Ethernet traffic generator that outputs frames with a predictable pattern in the frame, and a receiver that will check that the pattern is received as expected. >> >> Then you can try out your parallel algorithm variations on the simple Ethernet sender/receiver and narrow down the problem without all the other concerns. >> >> Once the bug is tracked down, we can add the sender/receiver into mirage-skeleton and use it as a test case to ensure that this functional never regresses in the future. Line rate Ethernet transmission has worked in the past, but we never added a test case to ensure it stays working. >> >> Anil >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 19:07:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 19:07:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Jws-00081h-IU; Wed, 17 Dec 2014 19:07:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Jwr-00081c-5o for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 19:07:49 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id E7/E2-28296-484D1945; Wed, 17 Dec 2014 19:07:48 +0000 X-Env-Sender: mindy@somerandomidiot.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1418843267!14166976!1 X-Originating-IP: [217.70.183.197] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 17 Dec 2014 19:07:48 -0000 Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net) (217.70.183.197) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 19:07:48 -0000 Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id C0F0941C064 for ; Wed, 17 Dec 2014 20:07:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TriFvP5Dcj44 for ; Wed, 17 Dec 2014 20:07:46 +0100 (CET) X-Originating-IP: 198.27.62.74 Received: from [192.168.10.218] (unknown [198.27.62.74]) (Authenticated sender: guybrush@somerandomidiot.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 39D6C41C079 for ; Wed, 17 Dec 2014 20:07:45 +0100 (CET) Message-ID: <5491D4AD.3070804@somerandomidiot.com> Date: Wed, 17 Dec 2014 13:08:29 -0600 From: Mindy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> In-Reply-To: <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I've been thinking about attending. I'd be especially enthusiastic about doing so if I knew I'd see some friendly faces :) -Mindy On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: > Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. > > -anil > >> Begin forwarded message: >> >> From: Lars Kurth >> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >> Date: 17 December 2014 07:17:09 GMT-8 >> To: publicity@lists.xenproject.org >> >> Hi all, >> I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know >> a) What days you will be at FOSDEM >> b) What you'd demonstrate - a headline + a paragraph >> Regards >> Lars > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 19:07:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 19:07:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Jws-00081h-IU; Wed, 17 Dec 2014 19:07:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Jwr-00081c-5o for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 19:07:49 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id E7/E2-28296-484D1945; Wed, 17 Dec 2014 19:07:48 +0000 X-Env-Sender: mindy@somerandomidiot.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1418843267!14166976!1 X-Originating-IP: [217.70.183.197] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 17 Dec 2014 19:07:48 -0000 Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net) (217.70.183.197) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 19:07:48 -0000 Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id C0F0941C064 for ; Wed, 17 Dec 2014 20:07:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TriFvP5Dcj44 for ; Wed, 17 Dec 2014 20:07:46 +0100 (CET) X-Originating-IP: 198.27.62.74 Received: from [192.168.10.218] (unknown [198.27.62.74]) (Authenticated sender: guybrush@somerandomidiot.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 39D6C41C079 for ; Wed, 17 Dec 2014 20:07:45 +0100 (CET) Message-ID: <5491D4AD.3070804@somerandomidiot.com> Date: Wed, 17 Dec 2014 13:08:29 -0600 From: Mindy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> In-Reply-To: <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I've been thinking about attending. I'd be especially enthusiastic about doing so if I knew I'd see some friendly faces :) -Mindy On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: > Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. > > -anil > >> Begin forwarded message: >> >> From: Lars Kurth >> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >> Date: 17 December 2014 07:17:09 GMT-8 >> To: publicity@lists.xenproject.org >> >> Hi all, >> I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know >> a) What days you will be at FOSDEM >> b) What you'd demonstrate - a headline + a paragraph >> Regards >> Lars > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 20:31:02 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 20:31:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1LFH-0001nr-26; Wed, 17 Dec 2014 20:30:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1LFF-0001nm-N7 for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 20:30:53 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 7F/BA-22777-DF7E1945; Wed, 17 Dec 2014 20:30:53 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-206.messagelabs.com!1418848252!8672218!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32434 invoked from network); 17 Dec 2014 20:30:52 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 20:30:52 -0000 Received: from [IPv6:2601:9:4f00:3600:c49e:e235:a766:a4d1] (2601:9:4f00:3600:c49e:e235:a766:a4d1 [IPv6:2601:9:4f00:3600:c49e:e235:a766:a4d1]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id ef4d52a4; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 20:36:47 +0000 (GMT) References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> <5491D4AD.3070804@somerandomidiot.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5491D4AD.3070804@somerandomidiot.com> Message-Id: <13231EEC-E1E3-4A2B-841C-3F755C9B7A4C@recoil.org> X-Mailer: iPhone Mail (12B435) From: Anil Madhavapeddy Date: Wed, 17 Dec 2014 12:30:50 -0800 To: Mindy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I'll try to attend, but need to check on teaching schedule. Mort isn't teaching next term, hint hint :-) > On 17 Dec 2014, at 11:08, Mindy wrote: > > I've been thinking about attending. I'd be especially enthusiastic about doing so if I knew I'd see some friendly faces :) > > -Mindy > >> On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: >> Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. >> >> -anil >> >>> Begin forwarded message: >>> >>> From: Lars Kurth >>> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >>> Date: 17 December 2014 07:17:09 GMT-8 >>> To: publicity@lists.xenproject.org >>> >>> Hi all, >>> I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know >>> a) What days you will be at FOSDEM >>> b) What you'd demonstrate - a headline + a paragraph >>> Regards >>> Lars >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 17 20:31:02 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 17 Dec 2014 20:31:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1LFH-0001nr-26; Wed, 17 Dec 2014 20:30:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1LFF-0001nm-N7 for mirageos-devel@lists.xenproject.org; Wed, 17 Dec 2014 20:30:53 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 7F/BA-22777-DF7E1945; Wed, 17 Dec 2014 20:30:53 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-10.tower-206.messagelabs.com!1418848252!8672218!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32434 invoked from network); 17 Dec 2014 20:30:52 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2014 20:30:52 -0000 Received: from [IPv6:2601:9:4f00:3600:c49e:e235:a766:a4d1] (2601:9:4f00:3600:c49e:e235:a766:a4d1 [IPv6:2601:9:4f00:3600:c49e:e235:a766:a4d1]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id ef4d52a4; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 17 Dec 2014 20:36:47 +0000 (GMT) References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> <5491D4AD.3070804@somerandomidiot.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5491D4AD.3070804@somerandomidiot.com> Message-Id: <13231EEC-E1E3-4A2B-841C-3F755C9B7A4C@recoil.org> X-Mailer: iPhone Mail (12B435) From: Anil Madhavapeddy Date: Wed, 17 Dec 2014 12:30:50 -0800 To: Mindy Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I'll try to attend, but need to check on teaching schedule. Mort isn't teaching next term, hint hint :-) > On 17 Dec 2014, at 11:08, Mindy wrote: > > I've been thinking about attending. I'd be especially enthusiastic about doing so if I knew I'd see some friendly faces :) > > -Mindy > >> On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: >> Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. >> >> -anil >> >>> Begin forwarded message: >>> >>> From: Lars Kurth >>> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >>> Date: 17 December 2014 07:17:09 GMT-8 >>> To: publicity@lists.xenproject.org >>> >>> Hi all, >>> I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know >>> a) What days you will be at FOSDEM >>> b) What you'd demonstrate - a headline + a paragraph >>> Regards >>> Lars >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 09:56:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 09:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1XpE-0002ll-Ob; Thu, 18 Dec 2014 09:56:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1XpD-0002lb-4i for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 09:56:51 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 95/3E-02697-2E4A2945; Thu, 18 Dec 2014 09:56:50 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1418896609!8651635!1 X-Originating-IP: [209.85.217.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27569 invoked from network); 18 Dec 2014 09:56:49 -0000 Received: from mail-lb0-f177.google.com (HELO mail-lb0-f177.google.com) (209.85.217.177) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 09:56:49 -0000 Received: by mail-lb0-f177.google.com with SMTP id b6so643567lbj.8 for ; Thu, 18 Dec 2014 01:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ruaC9S9mVvFZVZmFdxrWz//gOt1afAbupYTJMll9Ppw=; b=cWlLH9xrzF5i//7be1esOKhvF0ZO6OYxvgYAIzljW8taeSxkAdcF0UnY23o9pyi1y2 3v1uWJk0tS3ro5ThuqPhirIwHqLZZTZL+vDpESWqw8fxLBvY5rhD50bi6zVlEiy3fUC7 2tL65PQ+E5SzzsONMQPCRNoa07UqY8n9+lquBBWygo7UL7O7bQbhIEbqmm4GroGLHanh JiDumfmNxVRmWdfdArCe6vsur+ypPCtK+U/R4QnMN0c9QFR3o8jXM4ZRE+kSEvIVhoJn CJjIgqWcWVpdPcCLG+bo7Y1XJ5OwanwzQUrMY1UVdNM1AUQe46OSEqhgyIMBSIY6h9yI kxGQ== MIME-Version: 1.0 X-Received: by 10.152.234.140 with SMTP id ue12mr1272564lac.78.1418896608763; Thu, 18 Dec 2014 01:56:48 -0800 (PST) Received: by 10.25.207.3 with HTTP; Thu, 18 Dec 2014 01:56:48 -0800 (PST) In-Reply-To: <5491C606.500@nottingham.ac.uk> References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> Date: Thu, 18 Dec 2014 09:56:48 +0000 Message-ID: From: Thomas Leonard To: Masoud Koleini Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 18:05, Masoud Koleini wrote: > Thanks Thomas for the great tracing tool! > > The following is a very simple unikernel with two interfaces, which > redirects frames captured on the first interface to the second one: > > https://github.com/koleini/parallelisation > > The problem is that in a high packet rate (more than 80'000 pps), switch > stops receiving. The goal is to spot the problem and enhance the throughput > of Mirage netif. I don't know if this is the problem, but in the code, I see you do: listen if1 if2 >> (forward_thread if2) This ignores the result from listen, so if the listen thread later fails then the error will be discarded. I'd try something like this: Lwt.choose [ listen if1 if2; forward_thread if2 ] (and lose the "return" at the end of listen) I really think the >> operator should be banned... > Test environment consists of another vm running a traffic generator and > sending frames of a specific pattern (UDP frames of size 100 bytes) over the > bridge that connects to the first interface of the unikernel. Unikernel > forwards frames by collecting a number of frames from input queue and > running the same number of threads that write them to the output interface. > > Two trace files are uploaded to the repo. The first file is the output of > this configuration. This trace shows that each netif write locks until the > thread that writes on the front-end connection to the ring is returned > (function write_already_locked.) > > For the second trace, the return of the thread is ignored (commenting out > "lwt () = th in" in write_already_locked). This considerably increases > switching speed, but after some running time, it looks that after garbage > collection, similar problem happens. > > Thomas and Anil, any idea from given traces, and how it is possible to make > the traces more informative? > > Thanks. > > > On 28/11/14 16:55, Thomas Leonard wrote: >> >> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>> >>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>> wrote: >>>> >>>> Thanks Anil. >>>> >>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>> Leonard's profiling patches should help here) >>>> >>>> Would you please point me out to the profiling patches? >>> >>> See: >>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >> >> The installation instructions here are for the previous version >> (though they should still work). If you want to try the latest >> version, the current Git mirage allows you to pass a ~tracing argument >> to "register" in your config.ml, e.g. >> >> let tracing = mprof_trace ~size:1000000 () in >> register "myunikernel" ~tracing [ >> main $ ... >> ] >> >> This uses a newer version of the profiling API. You should generally >> "opam pin" the #tracing2 branches rather than #tracing to use it. >> >> Note also that it doesn't currently record ring utilisation, so you'll >> still need to do some work to get that. You could use the >> MProf.Counter interface, in which case the GUI will display it as a >> graph over the trace. >> >>>>> - try to reduce the parallelisation to see if some condition there >>>>> alleviates the issue to track it down. >>>> >>>> Reducing the maximum number of threads running in parallel reduced CPU >>>> utilization, and vm was functioning for a much longer time, but the same >>>> problem occurred at the end. >>>> >>>> It might be more useful looking at the code. Please have a look at the >>>> function "f_thread" in the file uploaded on the following repo: >>>> >>>> https://github.com/koleini/parallelisation >>> >>> That's a lot of code to try and distill down a test case. Try to cut it >>> down significantly by building a minimal Ethernet traffic generator that >>> outputs frames with a predictable pattern in the frame, and a receiver that >>> will check that the pattern is received as expected. >>> >>> Then you can try out your parallel algorithm variations on the simple >>> Ethernet sender/receiver and narrow down the problem without all the other >>> concerns. >>> >>> Once the bug is tracked down, we can add the sender/receiver into >>> mirage-skeleton and use it as a test case to ensure that this functional >>> never regresses in the future. Line rate Ethernet transmission has worked >>> in the past, but we never added a test case to ensure it stays working. >>> >>> Anil >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> > > > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 09:56:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 09:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1XpE-0002ll-Ob; Thu, 18 Dec 2014 09:56:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1XpD-0002lb-4i for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 09:56:51 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 95/3E-02697-2E4A2945; Thu, 18 Dec 2014 09:56:50 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1418896609!8651635!1 X-Originating-IP: [209.85.217.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27569 invoked from network); 18 Dec 2014 09:56:49 -0000 Received: from mail-lb0-f177.google.com (HELO mail-lb0-f177.google.com) (209.85.217.177) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 09:56:49 -0000 Received: by mail-lb0-f177.google.com with SMTP id b6so643567lbj.8 for ; Thu, 18 Dec 2014 01:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ruaC9S9mVvFZVZmFdxrWz//gOt1afAbupYTJMll9Ppw=; b=cWlLH9xrzF5i//7be1esOKhvF0ZO6OYxvgYAIzljW8taeSxkAdcF0UnY23o9pyi1y2 3v1uWJk0tS3ro5ThuqPhirIwHqLZZTZL+vDpESWqw8fxLBvY5rhD50bi6zVlEiy3fUC7 2tL65PQ+E5SzzsONMQPCRNoa07UqY8n9+lquBBWygo7UL7O7bQbhIEbqmm4GroGLHanh JiDumfmNxVRmWdfdArCe6vsur+ypPCtK+U/R4QnMN0c9QFR3o8jXM4ZRE+kSEvIVhoJn CJjIgqWcWVpdPcCLG+bo7Y1XJ5OwanwzQUrMY1UVdNM1AUQe46OSEqhgyIMBSIY6h9yI kxGQ== MIME-Version: 1.0 X-Received: by 10.152.234.140 with SMTP id ue12mr1272564lac.78.1418896608763; Thu, 18 Dec 2014 01:56:48 -0800 (PST) Received: by 10.25.207.3 with HTTP; Thu, 18 Dec 2014 01:56:48 -0800 (PST) In-Reply-To: <5491C606.500@nottingham.ac.uk> References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> Date: Thu, 18 Dec 2014 09:56:48 +0000 Message-ID: From: Thomas Leonard To: Masoud Koleini Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 18:05, Masoud Koleini wrote: > Thanks Thomas for the great tracing tool! > > The following is a very simple unikernel with two interfaces, which > redirects frames captured on the first interface to the second one: > > https://github.com/koleini/parallelisation > > The problem is that in a high packet rate (more than 80'000 pps), switch > stops receiving. The goal is to spot the problem and enhance the throughput > of Mirage netif. I don't know if this is the problem, but in the code, I see you do: listen if1 if2 >> (forward_thread if2) This ignores the result from listen, so if the listen thread later fails then the error will be discarded. I'd try something like this: Lwt.choose [ listen if1 if2; forward_thread if2 ] (and lose the "return" at the end of listen) I really think the >> operator should be banned... > Test environment consists of another vm running a traffic generator and > sending frames of a specific pattern (UDP frames of size 100 bytes) over the > bridge that connects to the first interface of the unikernel. Unikernel > forwards frames by collecting a number of frames from input queue and > running the same number of threads that write them to the output interface. > > Two trace files are uploaded to the repo. The first file is the output of > this configuration. This trace shows that each netif write locks until the > thread that writes on the front-end connection to the ring is returned > (function write_already_locked.) > > For the second trace, the return of the thread is ignored (commenting out > "lwt () = th in" in write_already_locked). This considerably increases > switching speed, but after some running time, it looks that after garbage > collection, similar problem happens. > > Thomas and Anil, any idea from given traces, and how it is possible to make > the traces more informative? > > Thanks. > > > On 28/11/14 16:55, Thomas Leonard wrote: >> >> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>> >>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>> wrote: >>>> >>>> Thanks Anil. >>>> >>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>> Leonard's profiling patches should help here) >>>> >>>> Would you please point me out to the profiling patches? >>> >>> See: >>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >> >> The installation instructions here are for the previous version >> (though they should still work). If you want to try the latest >> version, the current Git mirage allows you to pass a ~tracing argument >> to "register" in your config.ml, e.g. >> >> let tracing = mprof_trace ~size:1000000 () in >> register "myunikernel" ~tracing [ >> main $ ... >> ] >> >> This uses a newer version of the profiling API. You should generally >> "opam pin" the #tracing2 branches rather than #tracing to use it. >> >> Note also that it doesn't currently record ring utilisation, so you'll >> still need to do some work to get that. You could use the >> MProf.Counter interface, in which case the GUI will display it as a >> graph over the trace. >> >>>>> - try to reduce the parallelisation to see if some condition there >>>>> alleviates the issue to track it down. >>>> >>>> Reducing the maximum number of threads running in parallel reduced CPU >>>> utilization, and vm was functioning for a much longer time, but the same >>>> problem occurred at the end. >>>> >>>> It might be more useful looking at the code. Please have a look at the >>>> function "f_thread" in the file uploaded on the following repo: >>>> >>>> https://github.com/koleini/parallelisation >>> >>> That's a lot of code to try and distill down a test case. Try to cut it >>> down significantly by building a minimal Ethernet traffic generator that >>> outputs frames with a predictable pattern in the frame, and a receiver that >>> will check that the pattern is received as expected. >>> >>> Then you can try out your parallel algorithm variations on the simple >>> Ethernet sender/receiver and narrow down the problem without all the other >>> concerns. >>> >>> Once the bug is tracked down, we can add the sender/receiver into >>> mirage-skeleton and use it as a test case to ensure that this functional >>> never regresses in the future. Line rate Ethernet transmission has worked >>> in the past, but we never added a test case to ensure it stays working. >>> >>> Anil >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> > > > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 10:23:25 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 10:23:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YEu-0004WD-AD; Thu, 18 Dec 2014 10:23:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YEt-0004W6-Eh for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 10:23:23 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id B1/99-27785-A1BA2945; Thu, 18 Dec 2014 10:23:22 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-11.tower-27.messagelabs.com!1418898201!12555709!1 X-Originating-IP: [128.243.43.120] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10995 invoked from network); 18 Dec 2014 10:23:21 -0000 Received: from uidappmx05.nottingham.ac.uk (HELO uidappmx05.nottingham.ac.uk) (128.243.43.120) by server-11.tower-27.messagelabs.com with SMTP; 18 Dec 2014 10:23:21 -0000 Received: from uidappmx05.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 60B42725D48_492AB19B for ; Thu, 18 Dec 2014 10:23:21 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx05.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 3A79371CAD8_492AB18F for ; Thu, 18 Dec 2014 10:23:20 +0000 (GMT) Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1YEq-0001yX-5A; Thu, 18 Dec 2014 10:23:20 +0000 From: Richard Mortier To: Anil Madhavapeddy Date: Thu, 18 Dec 2014 10:23:17 +0000 Thread-Topic: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth Thread-Index: AdAarKTQ0wOPX4nATJSUysFe9Khn9g== Message-ID: <085EF669-48EA-4F19-B2EB-8C5C629D6028@nottingham.ac.uk> References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> <5491D4AD.3070804@somerandomidiot.com> <20141217203128.83B0030CA1E_491E820B@uidappmx06.nottingham.ac.uk> In-Reply-To: <20141217203128.83B0030CA1E_491E820B@uidappmx06.nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0433702990083735488==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0433702990083735488== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii it's a saturday/sunday-- you teach on a sunday now?! :) i'll look into it... but i'd encourage anyone else who's interested to go if they can -- i've on= ly been the once but fosdem was interesting, fun, and a nice atmosphere! On 17 Dec 2014, at 20:30, Anil Madhavapeddy wrote: > I'll try to attend, but need to check on teaching schedule. Mort isn't te= aching next term, hint hint :-) >=20 >=20 >=20 >> On 17 Dec 2014, at 11:08, Mindy wrote: >>=20 >> I've been thinking about attending. I'd be especially enthusiastic abou= t doing so if I knew I'd see some friendly faces :) >>=20 >> -Mindy >>=20 >>> On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: >>> Would anyone like to attend FOSDEM this year? Mort and I were there la= st year, and there was a healthy amount of traffic/demonstrations going on = about Mirage at the Xen booth. >>>=20 >>> -anil >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: Lars Kurth >>>> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >>>> Date: 17 December 2014 07:17:09 GMT-8 >>>> To: publicity@lists.xenproject.org >>>>=20 >>>> Hi all, >>>> I was just notified that the Xen Project's booth was accepted at FOSDE= M this year. As last year, I am happy for vendors and community members to = give demos. There has to be an open source angle of some sort, otherwise I = would be breaking FOSDEM rules. If you want to make use of the offer, pleas= e get back to me and let me know >>>> a) What days you will be at FOSDEM >>>> b) What you'd demonstrate - a headline + a paragraph >>>> Regards >>>> Lars >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>=20 >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkqsVAAoJEOLF27JWwSg3YgUQAI5W+u1ivJeYsYftXH4Tos0f Ft97l1BpLFrREcTxACvjrPt1CbQELMUqAtGiyX2mfl+tyc0FKiAoitxbe2TCQe24 EOMymwvhbiv+vp4amqsRNvJN+Z8fLqcflEXSjoZKd6YUQu5TTrcPcc7Y2tbO9S8d p3RcjgGV9epv2PVGTpXFnMc2T2HZEIqQlzzL0uUuAYMvP8SjT6e0oH+jGHQkbwcT uM5pnQ/AU63VNR1hKZZYkevshow+h20jBh1GW4VXsXgwp2ZnYABlFPfF/9NdEnCs lHA++0/WdMD0BsWgBSW+tM2IWDuKo/ufTjxOXQiSPOzUOz/i1xuVcExzZvqb+wi+ s9uC5J+9mgaj2A6IoW2S+pxC6txSKjMXNvr1rQeFUP4KG1NAUeTnke2MS2s9Z2lw 7DZ6Cj+0DbG+KdnJ6eTD4aYGpPIsxOlW9ML7qVDEP4hDAow5FWk/nkEyaX7VKtKD t//mJ81BelxaoTT0jwf9H20GO5l9dQR7HVMRDNZTXmJDpfwNpu3Z0c0GoESXRlnr JDWVU0WL1LT0ay/9gw5q/2HYodzEh7DZ/bzsa8phWa4Etu8mXuZ9YCR3QI6CU/im WRkeo6gYzDGzTRO3MA35BGk93oRSsCfOerwy8FytsizcF8pnaEh52K7hP7OLhoAA gqIxtbU67EQ783V4f3dL =ygfG -----END PGP SIGNATURE----- --Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D-- --===============0433702990083735488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0433702990083735488==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 10:23:25 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 10:23:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YEu-0004WD-AD; Thu, 18 Dec 2014 10:23:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YEt-0004W6-Eh for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 10:23:23 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id B1/99-27785-A1BA2945; Thu, 18 Dec 2014 10:23:22 +0000 X-Env-Sender: Richard.Mortier@nottingham.ac.uk X-Msg-Ref: server-11.tower-27.messagelabs.com!1418898201!12555709!1 X-Originating-IP: [128.243.43.120] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10995 invoked from network); 18 Dec 2014 10:23:21 -0000 Received: from uidappmx05.nottingham.ac.uk (HELO uidappmx05.nottingham.ac.uk) (128.243.43.120) by server-11.tower-27.messagelabs.com with SMTP; 18 Dec 2014 10:23:21 -0000 Received: from uidappmx05.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 60B42725D48_492AB19B for ; Thu, 18 Dec 2014 10:23:21 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx05.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 3A79371CAD8_492AB18F for ; Thu, 18 Dec 2014 10:23:20 +0000 (GMT) Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1YEq-0001yX-5A; Thu, 18 Dec 2014 10:23:20 +0000 From: Richard Mortier To: Anil Madhavapeddy Date: Thu, 18 Dec 2014 10:23:17 +0000 Thread-Topic: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth Thread-Index: AdAarKTQ0wOPX4nATJSUysFe9Khn9g== Message-ID: <085EF669-48EA-4F19-B2EB-8C5C629D6028@nottingham.ac.uk> References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> <5491D4AD.3070804@somerandomidiot.com> <20141217203128.83B0030CA1E_491E820B@uidappmx06.nottingham.ac.uk> In-Reply-To: <20141217203128.83B0030CA1E_491E820B@uidappmx06.nottingham.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0433702990083735488==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0433702990083735488== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii it's a saturday/sunday-- you teach on a sunday now?! :) i'll look into it... but i'd encourage anyone else who's interested to go if they can -- i've on= ly been the once but fosdem was interesting, fun, and a nice atmosphere! On 17 Dec 2014, at 20:30, Anil Madhavapeddy wrote: > I'll try to attend, but need to check on teaching schedule. Mort isn't te= aching next term, hint hint :-) >=20 >=20 >=20 >> On 17 Dec 2014, at 11:08, Mindy wrote: >>=20 >> I've been thinking about attending. I'd be especially enthusiastic abou= t doing so if I knew I'd see some friendly faces :) >>=20 >> -Mindy >>=20 >>> On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: >>> Would anyone like to attend FOSDEM this year? Mort and I were there la= st year, and there was a healthy amount of traffic/demonstrations going on = about Mirage at the Xen booth. >>>=20 >>> -anil >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: Lars Kurth >>>> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >>>> Date: 17 December 2014 07:17:09 GMT-8 >>>> To: publicity@lists.xenproject.org >>>>=20 >>>> Hi all, >>>> I was just notified that the Xen Project's booth was accepted at FOSDE= M this year. As last year, I am happy for vendors and community members to = give demos. There has to be an open source angle of some sort, otherwise I = would be breaking FOSDEM rules. If you want to make use of the offer, pleas= e get back to me and let me know >>>> a) What days you will be at FOSDEM >>>> b) What you'd demonstrate - a headline + a paragraph >>>> Regards >>>> Lars >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>=20 >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --=20 Cheers, R. [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequentl= y. ] This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not= use, copy or disclose the information contained in this message or in any = attachment. Any views or opinions expressed by the author of this email do= not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= , you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. --Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkqsVAAoJEOLF27JWwSg3YgUQAI5W+u1ivJeYsYftXH4Tos0f Ft97l1BpLFrREcTxACvjrPt1CbQELMUqAtGiyX2mfl+tyc0FKiAoitxbe2TCQe24 EOMymwvhbiv+vp4amqsRNvJN+Z8fLqcflEXSjoZKd6YUQu5TTrcPcc7Y2tbO9S8d p3RcjgGV9epv2PVGTpXFnMc2T2HZEIqQlzzL0uUuAYMvP8SjT6e0oH+jGHQkbwcT uM5pnQ/AU63VNR1hKZZYkevshow+h20jBh1GW4VXsXgwp2ZnYABlFPfF/9NdEnCs lHA++0/WdMD0BsWgBSW+tM2IWDuKo/ufTjxOXQiSPOzUOz/i1xuVcExzZvqb+wi+ s9uC5J+9mgaj2A6IoW2S+pxC6txSKjMXNvr1rQeFUP4KG1NAUeTnke2MS2s9Z2lw 7DZ6Cj+0DbG+KdnJ6eTD4aYGpPIsxOlW9ML7qVDEP4hDAow5FWk/nkEyaX7VKtKD t//mJ81BelxaoTT0jwf9H20GO5l9dQR7HVMRDNZTXmJDpfwNpu3Z0c0GoESXRlnr JDWVU0WL1LT0ay/9gw5q/2HYodzEh7DZ/bzsa8phWa4Etu8mXuZ9YCR3QI6CU/im WRkeo6gYzDGzTRO3MA35BGk93oRSsCfOerwy8FytsizcF8pnaEh52K7hP7OLhoAA gqIxtbU67EQ783V4f3dL =ygfG -----END PGP SIGNATURE----- --Apple-Mail=_CFC0656B-BABC-4505-B97A-652FEFA0F32D-- --===============0433702990083735488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0433702990083735488==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:02:16 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:02:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YqS-0006kM-5d; Thu, 18 Dec 2014 11:02:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YqQ-0006jN-Rg for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:02:11 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id C7/A5-27785-134B2945; Thu, 18 Dec 2014 11:02:09 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-16.tower-27.messagelabs.com!1418900528!10465891!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16716 invoked from network); 18 Dec 2014 11:02:08 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-16.tower-27.messagelabs.com with SMTP; 18 Dec 2014 11:02:08 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 8E5EA3C47DB_492B42FB for ; Thu, 18 Dec 2014 11:02:07 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 3C7DA3D4CD6_492B42CF for ; Thu, 18 Dec 2014 11:02:03 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1YqJ-0004bA-QZ; Thu, 18 Dec 2014 11:02:03 +0000 Message-ID: <5492B427.7020008@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:01:59 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 17 December 2014 at 18:05, Masoud Koleini wrote: >> Thanks Thomas for the great tracing tool! >> >> The following is a very simple unikernel with two interfaces, which >> redirects frames captured on the first interface to the second one: >> >> https://github.com/koleini/parallelisation >> >> The problem is that in a high packet rate (more than 80'000 pps), switch >> stops receiving. The goal is to spot the problem and enhance the throughput >> of Mirage netif. > I don't know if this is the problem, but in the code, I see you do: > > listen if1 if2 > >> (forward_thread if2) > > This ignores the result from listen, so if the listen thread later > fails then the error will be discarded. I'd try something like this: > > Lwt.choose [ > listen if1 if2; > forward_thread if2 > ] > > (and lose the "return" at the end of listen) listen calls netif listen function, which only sets receive_callback on the interface (used by poll_thread). It looks that failing poll_thread is not monitored in netif code. > I really think the >> operator should be banned... > >> Test environment consists of another vm running a traffic generator and >> sending frames of a specific pattern (UDP frames of size 100 bytes) over the >> bridge that connects to the first interface of the unikernel. Unikernel >> forwards frames by collecting a number of frames from input queue and >> running the same number of threads that write them to the output interface. >> >> Two trace files are uploaded to the repo. The first file is the output of >> this configuration. This trace shows that each netif write locks until the >> thread that writes on the front-end connection to the ring is returned >> (function write_already_locked.) >> >> For the second trace, the return of the thread is ignored (commenting out >> "lwt () = th in" in write_already_locked). This considerably increases >> switching speed, but after some running time, it looks that after garbage >> collection, similar problem happens. >> >> Thomas and Anil, any idea from given traces, and how it is possible to make >> the traces more informative? >> >> Thanks. >> >> >> On 28/11/14 16:55, Thomas Leonard wrote: >>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>> wrote: >>>>> >>>>> Thanks Anil. >>>>> >>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>> Leonard's profiling patches should help here) >>>>> Would you please point me out to the profiling patches? >>>> See: >>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>> The installation instructions here are for the previous version >>> (though they should still work). If you want to try the latest >>> version, the current Git mirage allows you to pass a ~tracing argument >>> to "register" in your config.ml, e.g. >>> >>> let tracing = mprof_trace ~size:1000000 () in >>> register "myunikernel" ~tracing [ >>> main $ ... >>> ] >>> >>> This uses a newer version of the profiling API. You should generally >>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>> >>> Note also that it doesn't currently record ring utilisation, so you'll >>> still need to do some work to get that. You could use the >>> MProf.Counter interface, in which case the GUI will display it as a >>> graph over the trace. >>> >>>>>> - try to reduce the parallelisation to see if some condition there >>>>>> alleviates the issue to track it down. >>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>> utilization, and vm was functioning for a much longer time, but the same >>>>> problem occurred at the end. >>>>> >>>>> It might be more useful looking at the code. Please have a look at the >>>>> function "f_thread" in the file uploaded on the following repo: >>>>> >>>>> https://github.com/koleini/parallelisation >>>> That's a lot of code to try and distill down a test case. Try to cut it >>>> down significantly by building a minimal Ethernet traffic generator that >>>> outputs frames with a predictable pattern in the frame, and a receiver that >>>> will check that the pattern is received as expected. >>>> >>>> Then you can try out your parallel algorithm variations on the simple >>>> Ethernet sender/receiver and narrow down the problem without all the other >>>> concerns. >>>> >>>> Once the bug is tracked down, we can add the sender/receiver into >>>> mirage-skeleton and use it as a test case to ensure that this functional >>>> never regresses in the future. Line rate Ethernet transmission has worked >>>> in the past, but we never added a test case to ensure it stays working. >>>> >>>> Anil >>>> _______________________________________________ >>>> MirageOS-devel mailing list >>>> MirageOS-devel@lists.xenproject.org >>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >>> >> >> >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please send it back to me, and immediately delete it. Please do not >> use, copy or disclose the information contained in this message or in any >> attachment. Any views or opinions expressed by the author of this email do >> not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment >> may still contain software viruses which could damage your computer system, >> you are advised to perform your own checks. Email communications with the >> University of Nottingham may be monitored as permitted by UK legislation. >> > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:02:16 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:02:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YqS-0006kM-5d; Thu, 18 Dec 2014 11:02:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1YqQ-0006jN-Rg for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:02:11 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id C7/A5-27785-134B2945; Thu, 18 Dec 2014 11:02:09 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-16.tower-27.messagelabs.com!1418900528!10465891!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16716 invoked from network); 18 Dec 2014 11:02:08 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-16.tower-27.messagelabs.com with SMTP; 18 Dec 2014 11:02:08 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 8E5EA3C47DB_492B42FB for ; Thu, 18 Dec 2014 11:02:07 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 3C7DA3D4CD6_492B42CF for ; Thu, 18 Dec 2014 11:02:03 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1YqJ-0004bA-QZ; Thu, 18 Dec 2014 11:02:03 +0000 Message-ID: <5492B427.7020008@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:01:59 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 17 December 2014 at 18:05, Masoud Koleini wrote: >> Thanks Thomas for the great tracing tool! >> >> The following is a very simple unikernel with two interfaces, which >> redirects frames captured on the first interface to the second one: >> >> https://github.com/koleini/parallelisation >> >> The problem is that in a high packet rate (more than 80'000 pps), switch >> stops receiving. The goal is to spot the problem and enhance the throughput >> of Mirage netif. > I don't know if this is the problem, but in the code, I see you do: > > listen if1 if2 > >> (forward_thread if2) > > This ignores the result from listen, so if the listen thread later > fails then the error will be discarded. I'd try something like this: > > Lwt.choose [ > listen if1 if2; > forward_thread if2 > ] > > (and lose the "return" at the end of listen) listen calls netif listen function, which only sets receive_callback on the interface (used by poll_thread). It looks that failing poll_thread is not monitored in netif code. > I really think the >> operator should be banned... > >> Test environment consists of another vm running a traffic generator and >> sending frames of a specific pattern (UDP frames of size 100 bytes) over the >> bridge that connects to the first interface of the unikernel. Unikernel >> forwards frames by collecting a number of frames from input queue and >> running the same number of threads that write them to the output interface. >> >> Two trace files are uploaded to the repo. The first file is the output of >> this configuration. This trace shows that each netif write locks until the >> thread that writes on the front-end connection to the ring is returned >> (function write_already_locked.) >> >> For the second trace, the return of the thread is ignored (commenting out >> "lwt () = th in" in write_already_locked). This considerably increases >> switching speed, but after some running time, it looks that after garbage >> collection, similar problem happens. >> >> Thomas and Anil, any idea from given traces, and how it is possible to make >> the traces more informative? >> >> Thanks. >> >> >> On 28/11/14 16:55, Thomas Leonard wrote: >>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>> wrote: >>>>> >>>>> Thanks Anil. >>>>> >>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>> Leonard's profiling patches should help here) >>>>> Would you please point me out to the profiling patches? >>>> See: >>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>> The installation instructions here are for the previous version >>> (though they should still work). If you want to try the latest >>> version, the current Git mirage allows you to pass a ~tracing argument >>> to "register" in your config.ml, e.g. >>> >>> let tracing = mprof_trace ~size:1000000 () in >>> register "myunikernel" ~tracing [ >>> main $ ... >>> ] >>> >>> This uses a newer version of the profiling API. You should generally >>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>> >>> Note also that it doesn't currently record ring utilisation, so you'll >>> still need to do some work to get that. You could use the >>> MProf.Counter interface, in which case the GUI will display it as a >>> graph over the trace. >>> >>>>>> - try to reduce the parallelisation to see if some condition there >>>>>> alleviates the issue to track it down. >>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>> utilization, and vm was functioning for a much longer time, but the same >>>>> problem occurred at the end. >>>>> >>>>> It might be more useful looking at the code. Please have a look at the >>>>> function "f_thread" in the file uploaded on the following repo: >>>>> >>>>> https://github.com/koleini/parallelisation >>>> That's a lot of code to try and distill down a test case. Try to cut it >>>> down significantly by building a minimal Ethernet traffic generator that >>>> outputs frames with a predictable pattern in the frame, and a receiver that >>>> will check that the pattern is received as expected. >>>> >>>> Then you can try out your parallel algorithm variations on the simple >>>> Ethernet sender/receiver and narrow down the problem without all the other >>>> concerns. >>>> >>>> Once the bug is tracked down, we can add the sender/receiver into >>>> mirage-skeleton and use it as a test case to ensure that this functional >>>> never regresses in the future. Line rate Ethernet transmission has worked >>>> in the past, but we never added a test case to ensure it stays working. >>>> >>>> Anil >>>> _______________________________________________ >>>> MirageOS-devel mailing list >>>> MirageOS-devel@lists.xenproject.org >>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >>> >> >> >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please send it back to me, and immediately delete it. Please do not >> use, copy or disclose the information contained in this message or in any >> attachment. Any views or opinions expressed by the author of this email do >> not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment >> may still contain software viruses which could damage your computer system, >> you are advised to perform your own checks. Email communications with the >> University of Nottingham may be monitored as permitted by UK legislation. >> > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:13:36 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:13:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Z1T-0007Oh-1W; Thu, 18 Dec 2014 11:13:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Z1R-0007OU-NC for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:13:33 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 6F/F4-25276-DD6B2945; Thu, 18 Dec 2014 11:13:33 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1418901211!13032645!1 X-Originating-IP: [209.85.217.181] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2604 invoked from network); 18 Dec 2014 11:13:31 -0000 Received: from mail-lb0-f181.google.com (HELO mail-lb0-f181.google.com) (209.85.217.181) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 11:13:31 -0000 Received: by mail-lb0-f181.google.com with SMTP id l4so735220lbv.40 for ; Thu, 18 Dec 2014 03:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=prWQh1kbB2pbsQRdFC0xHiqmvGYphil1mqCNhZvysWI=; b=g9tsz1MKoyITiWx8pHLQTUfrr8wMREgcIkp6eKZkc7kCJnOgkKcf8m+oEQuBIx2Nte YyPwUnl4gCIjlrgfoePQR261NTR0SrNoNV918La9s7FdW+fPRsG9ueoVYNUveueI5rdd DrKTp0a71Mza+k8gpCknwJaieEQRkJD36YRuGd4tDmdVXM7G7+n+ehsajyclA8sgixHa yH6nNqFNoaqQQTftL1eulT0JAvVAh6i6JqD2CcxJrx8ZvUWLH4eclofX4koYT/xro9NJ Ws8+ql1usQlpdsanu1BBrOm//29FtwIuRldEDMhNqJ/AgsbOFxHxVnccuxiHbw7NBVxd OSfg== MIME-Version: 1.0 X-Received: by 10.152.25.129 with SMTP id c1mr1659410lag.9.1418901210978; Thu, 18 Dec 2014 03:13:30 -0800 (PST) Received: by 10.25.207.3 with HTTP; Thu, 18 Dec 2014 03:13:30 -0800 (PST) In-Reply-To: <5492B427.7020008@nottingham.ac.uk> References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:13:30 +0000 Message-ID: From: Thomas Leonard To: Masoud Koleini , David Scott Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 18 December 2014 at 11:01, Masoud Koleini wrote: > >> On 17 December 2014 at 18:05, Masoud >> Koleini wrote: >>> >>> Thanks Thomas for the great tracing tool! >>> >>> The following is a very simple unikernel with two interfaces, which >>> redirects frames captured on the first interface to the second one: >>> >>> https://github.com/koleini/parallelisation >>> >>> The problem is that in a high packet rate (more than 80'000 pps), switch >>> stops receiving. The goal is to spot the problem and enhance the >>> throughput >>> of Mirage netif. >> >> I don't know if this is the problem, but in the code, I see you do: >> >> listen if1 if2 >> >> (forward_thread if2) >> >> This ignores the result from listen, so if the listen thread later >> fails then the error will be discarded. I'd try something like this: >> >> Lwt.choose [ >> listen if1 if2; >> forward_thread if2 >> ] >> >> (and lose the "return" at the end of listen) > > > listen calls netif listen function, which only sets receive_callback on the > interface (used by poll_thread). It looks that failing poll_thread is not > monitored in netif code. Hmm. You're right. Does it show anything if you catch errors there? Looks like it was changed here: https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c Perhaps listen could just return the poll thread, rather than making a fake task. Dave? >> I really think the >> operator should be banned... >> >>> Test environment consists of another vm running a traffic generator and >>> sending frames of a specific pattern (UDP frames of size 100 bytes) over >>> the >>> bridge that connects to the first interface of the unikernel. Unikernel >>> forwards frames by collecting a number of frames from input queue and >>> running the same number of threads that write them to the output >>> interface. >>> >>> Two trace files are uploaded to the repo. The first file is the output of >>> this configuration. This trace shows that each netif write locks until >>> the >>> thread that writes on the front-end connection to the ring is returned >>> (function write_already_locked.) >>> >>> For the second trace, the return of the thread is ignored (commenting out >>> "lwt () = th in" in write_already_locked). This considerably increases >>> switching speed, but after some running time, it looks that after garbage >>> collection, similar problem happens. >>> >>> Thomas and Anil, any idea from given traces, and how it is possible to >>> make >>> the traces more informative? >>> >>> Thanks. >>> >>> >>> On 28/11/14 16:55, Thomas Leonard wrote: >>>> >>>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>>> >>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>>> wrote: >>>>>> >>>>>> Thanks Anil. >>>>>> >>>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>>> Leonard's profiling patches should help here) >>>>>> >>>>>> Would you please point me out to the profiling patches? >>>>> >>>>> See: >>>>> >>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>>> >>>> The installation instructions here are for the previous version >>>> (though they should still work). If you want to try the latest >>>> version, the current Git mirage allows you to pass a ~tracing argument >>>> to "register" in your config.ml, e.g. >>>> >>>> let tracing = mprof_trace ~size:1000000 () in >>>> register "myunikernel" ~tracing [ >>>> main $ ... >>>> ] >>>> >>>> This uses a newer version of the profiling API. You should generally >>>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>>> >>>> Note also that it doesn't currently record ring utilisation, so you'll >>>> still need to do some work to get that. You could use the >>>> MProf.Counter interface, in which case the GUI will display it as a >>>> graph over the trace. >>>> >>>>>>> - try to reduce the parallelisation to see if some condition there >>>>>>> alleviates the issue to track it down. >>>>>> >>>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>>> utilization, and vm was functioning for a much longer time, but the >>>>>> same >>>>>> problem occurred at the end. >>>>>> >>>>>> It might be more useful looking at the code. Please have a look at the >>>>>> function "f_thread" in the file uploaded on the following repo: >>>>>> >>>>>> https://github.com/koleini/parallelisation >>>>> >>>>> That's a lot of code to try and distill down a test case. Try to cut >>>>> it >>>>> down significantly by building a minimal Ethernet traffic generator >>>>> that >>>>> outputs frames with a predictable pattern in the frame, and a receiver >>>>> that >>>>> will check that the pattern is received as expected. >>>>> >>>>> Then you can try out your parallel algorithm variations on the simple >>>>> Ethernet sender/receiver and narrow down the problem without all the >>>>> other >>>>> concerns. >>>>> >>>>> Once the bug is tracked down, we can add the sender/receiver into >>>>> mirage-skeleton and use it as a test case to ensure that this >>>>> functional >>>>> never regresses in the future. Line rate Ethernet transmission has >>>>> worked >>>>> in the past, but we never added a test case to ensure it stays working. >>>>> >>>>> Anil >>>>> _______________________________________________ >>>>> MirageOS-devel mailing list >>>>> MirageOS-devel@lists.xenproject.org >>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>>> >>>> >>>> >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee and >>> may contain confidential information. If you have received this message >>> in >>> error, please send it back to me, and immediately delete it. Please do >>> not >>> use, copy or disclose the information contained in this message or in any >>> attachment. Any views or opinions expressed by the author of this email >>> do >>> not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an >>> attachment >>> may still contain software viruses which could damage your computer >>> system, >>> you are advised to perform your own checks. Email communications with the >>> University of Nottingham may be monitored as permitted by UK legislation. >>> >> >> > > > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:13:36 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:13:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Z1T-0007Oh-1W; Thu, 18 Dec 2014 11:13:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1Z1R-0007OU-NC for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:13:33 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 6F/F4-25276-DD6B2945; Thu, 18 Dec 2014 11:13:33 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1418901211!13032645!1 X-Originating-IP: [209.85.217.181] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2604 invoked from network); 18 Dec 2014 11:13:31 -0000 Received: from mail-lb0-f181.google.com (HELO mail-lb0-f181.google.com) (209.85.217.181) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 11:13:31 -0000 Received: by mail-lb0-f181.google.com with SMTP id l4so735220lbv.40 for ; Thu, 18 Dec 2014 03:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=prWQh1kbB2pbsQRdFC0xHiqmvGYphil1mqCNhZvysWI=; b=g9tsz1MKoyITiWx8pHLQTUfrr8wMREgcIkp6eKZkc7kCJnOgkKcf8m+oEQuBIx2Nte YyPwUnl4gCIjlrgfoePQR261NTR0SrNoNV918La9s7FdW+fPRsG9ueoVYNUveueI5rdd DrKTp0a71Mza+k8gpCknwJaieEQRkJD36YRuGd4tDmdVXM7G7+n+ehsajyclA8sgixHa yH6nNqFNoaqQQTftL1eulT0JAvVAh6i6JqD2CcxJrx8ZvUWLH4eclofX4koYT/xro9NJ Ws8+ql1usQlpdsanu1BBrOm//29FtwIuRldEDMhNqJ/AgsbOFxHxVnccuxiHbw7NBVxd OSfg== MIME-Version: 1.0 X-Received: by 10.152.25.129 with SMTP id c1mr1659410lag.9.1418901210978; Thu, 18 Dec 2014 03:13:30 -0800 (PST) Received: by 10.25.207.3 with HTTP; Thu, 18 Dec 2014 03:13:30 -0800 (PST) In-Reply-To: <5492B427.7020008@nottingham.ac.uk> References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:13:30 +0000 Message-ID: From: Thomas Leonard To: Masoud Koleini , David Scott Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 18 December 2014 at 11:01, Masoud Koleini wrote: > >> On 17 December 2014 at 18:05, Masoud >> Koleini wrote: >>> >>> Thanks Thomas for the great tracing tool! >>> >>> The following is a very simple unikernel with two interfaces, which >>> redirects frames captured on the first interface to the second one: >>> >>> https://github.com/koleini/parallelisation >>> >>> The problem is that in a high packet rate (more than 80'000 pps), switch >>> stops receiving. The goal is to spot the problem and enhance the >>> throughput >>> of Mirage netif. >> >> I don't know if this is the problem, but in the code, I see you do: >> >> listen if1 if2 >> >> (forward_thread if2) >> >> This ignores the result from listen, so if the listen thread later >> fails then the error will be discarded. I'd try something like this: >> >> Lwt.choose [ >> listen if1 if2; >> forward_thread if2 >> ] >> >> (and lose the "return" at the end of listen) > > > listen calls netif listen function, which only sets receive_callback on the > interface (used by poll_thread). It looks that failing poll_thread is not > monitored in netif code. Hmm. You're right. Does it show anything if you catch errors there? Looks like it was changed here: https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c Perhaps listen could just return the poll thread, rather than making a fake task. Dave? >> I really think the >> operator should be banned... >> >>> Test environment consists of another vm running a traffic generator and >>> sending frames of a specific pattern (UDP frames of size 100 bytes) over >>> the >>> bridge that connects to the first interface of the unikernel. Unikernel >>> forwards frames by collecting a number of frames from input queue and >>> running the same number of threads that write them to the output >>> interface. >>> >>> Two trace files are uploaded to the repo. The first file is the output of >>> this configuration. This trace shows that each netif write locks until >>> the >>> thread that writes on the front-end connection to the ring is returned >>> (function write_already_locked.) >>> >>> For the second trace, the return of the thread is ignored (commenting out >>> "lwt () = th in" in write_already_locked). This considerably increases >>> switching speed, but after some running time, it looks that after garbage >>> collection, similar problem happens. >>> >>> Thomas and Anil, any idea from given traces, and how it is possible to >>> make >>> the traces more informative? >>> >>> Thanks. >>> >>> >>> On 28/11/14 16:55, Thomas Leonard wrote: >>>> >>>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>>> >>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>>> wrote: >>>>>> >>>>>> Thanks Anil. >>>>>> >>>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>>> Leonard's profiling patches should help here) >>>>>> >>>>>> Would you please point me out to the profiling patches? >>>>> >>>>> See: >>>>> >>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>>> >>>> The installation instructions here are for the previous version >>>> (though they should still work). If you want to try the latest >>>> version, the current Git mirage allows you to pass a ~tracing argument >>>> to "register" in your config.ml, e.g. >>>> >>>> let tracing = mprof_trace ~size:1000000 () in >>>> register "myunikernel" ~tracing [ >>>> main $ ... >>>> ] >>>> >>>> This uses a newer version of the profiling API. You should generally >>>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>>> >>>> Note also that it doesn't currently record ring utilisation, so you'll >>>> still need to do some work to get that. You could use the >>>> MProf.Counter interface, in which case the GUI will display it as a >>>> graph over the trace. >>>> >>>>>>> - try to reduce the parallelisation to see if some condition there >>>>>>> alleviates the issue to track it down. >>>>>> >>>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>>> utilization, and vm was functioning for a much longer time, but the >>>>>> same >>>>>> problem occurred at the end. >>>>>> >>>>>> It might be more useful looking at the code. Please have a look at the >>>>>> function "f_thread" in the file uploaded on the following repo: >>>>>> >>>>>> https://github.com/koleini/parallelisation >>>>> >>>>> That's a lot of code to try and distill down a test case. Try to cut >>>>> it >>>>> down significantly by building a minimal Ethernet traffic generator >>>>> that >>>>> outputs frames with a predictable pattern in the frame, and a receiver >>>>> that >>>>> will check that the pattern is received as expected. >>>>> >>>>> Then you can try out your parallel algorithm variations on the simple >>>>> Ethernet sender/receiver and narrow down the problem without all the >>>>> other >>>>> concerns. >>>>> >>>>> Once the bug is tracked down, we can add the sender/receiver into >>>>> mirage-skeleton and use it as a test case to ensure that this >>>>> functional >>>>> never regresses in the future. Line rate Ethernet transmission has >>>>> worked >>>>> in the past, but we never added a test case to ensure it stays working. >>>>> >>>>> Anil >>>>> _______________________________________________ >>>>> MirageOS-devel mailing list >>>>> MirageOS-devel@lists.xenproject.org >>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>>> >>>> >>>> >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee and >>> may contain confidential information. If you have received this message >>> in >>> error, please send it back to me, and immediately delete it. Please do >>> not >>> use, copy or disclose the information contained in this message or in any >>> attachment. Any views or opinions expressed by the author of this email >>> do >>> not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an >>> attachment >>> may still contain software viruses which could damage your computer >>> system, >>> you are advised to perform your own checks. Email communications with the >>> University of Nottingham may be monitored as permitted by UK legislation. >>> >> >> > > > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:24:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:24:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZC4-00087B-0p; Thu, 18 Dec 2014 11:24:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZC2-000876-MZ for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:24:30 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 9E/45-18267-D69B2945; Thu, 18 Dec 2014 11:24:29 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-9.tower-31.messagelabs.com!1418901868!10587048!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31121 invoked from network); 18 Dec 2014 11:24:28 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-9.tower-31.messagelabs.com with SMTP; 18 Dec 2014 11:24:28 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4D7A23C47C5_492B96CB for ; Thu, 18 Dec 2014 11:24:28 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id E05433D538B_492B96BF for ; Thu, 18 Dec 2014 11:24:27 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1ZBz-00065T-S2; Thu, 18 Dec 2014 11:24:27 +0000 Message-ID: <5492B96B.4030909@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:24:27 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard , David Scott References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 18 December 2014 at 11:01, Masoud Koleini > wrote: >>> On 17 December 2014 at 18:05, Masoud >>> Koleini wrote: >>>> Thanks Thomas for the great tracing tool! >>>> >>>> The following is a very simple unikernel with two interfaces, which >>>> redirects frames captured on the first interface to the second one: >>>> >>>> https://github.com/koleini/parallelisation >>>> >>>> The problem is that in a high packet rate (more than 80'000 pps), switch >>>> stops receiving. The goal is to spot the problem and enhance the >>>> throughput >>>> of Mirage netif. >>> I don't know if this is the problem, but in the code, I see you do: >>> >>> listen if1 if2 >>> >> (forward_thread if2) >>> >>> This ignores the result from listen, so if the listen thread later >>> fails then the error will be discarded. I'd try something like this: >>> >>> Lwt.choose [ >>> listen if1 if2; >>> forward_thread if2 >>> ] >>> >>> (and lose the "return" at the end of listen) >> >> listen calls netif listen function, which only sets receive_callback on the >> interface (used by poll_thread). It looks that failing poll_thread is not >> monitored in netif code. > Hmm. You're right. Does it show anything if you catch errors there? I just tried it, nothing shown! > > Looks like it was changed here: > > https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c > > Perhaps listen could just return the poll thread, rather than making a > fake task. Dave? > >>> I really think the >> operator should be banned... >>> >>>> Test environment consists of another vm running a traffic generator and >>>> sending frames of a specific pattern (UDP frames of size 100 bytes) over >>>> the >>>> bridge that connects to the first interface of the unikernel. Unikernel >>>> forwards frames by collecting a number of frames from input queue and >>>> running the same number of threads that write them to the output >>>> interface. >>>> >>>> Two trace files are uploaded to the repo. The first file is the output of >>>> this configuration. This trace shows that each netif write locks until >>>> the >>>> thread that writes on the front-end connection to the ring is returned >>>> (function write_already_locked.) >>>> >>>> For the second trace, the return of the thread is ignored (commenting out >>>> "lwt () = th in" in write_already_locked). This considerably increases >>>> switching speed, but after some running time, it looks that after garbage >>>> collection, similar problem happens. >>>> >>>> Thomas and Anil, any idea from given traces, and how it is possible to >>>> make >>>> the traces more informative? >>>> >>>> Thanks. >>>> >>>> >>>> On 28/11/14 16:55, Thomas Leonard wrote: >>>>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>>>> wrote: >>>>>>> >>>>>>> Thanks Anil. >>>>>>> >>>>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>>>> Leonard's profiling patches should help here) >>>>>>> Would you please point me out to the profiling patches? >>>>>> See: >>>>>> >>>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>>>> The installation instructions here are for the previous version >>>>> (though they should still work). If you want to try the latest >>>>> version, the current Git mirage allows you to pass a ~tracing argument >>>>> to "register" in your config.ml, e.g. >>>>> >>>>> let tracing = mprof_trace ~size:1000000 () in >>>>> register "myunikernel" ~tracing [ >>>>> main $ ... >>>>> ] >>>>> >>>>> This uses a newer version of the profiling API. You should generally >>>>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>>>> >>>>> Note also that it doesn't currently record ring utilisation, so you'll >>>>> still need to do some work to get that. You could use the >>>>> MProf.Counter interface, in which case the GUI will display it as a >>>>> graph over the trace. >>>>> >>>>>>>> - try to reduce the parallelisation to see if some condition there >>>>>>>> alleviates the issue to track it down. >>>>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>>>> utilization, and vm was functioning for a much longer time, but the >>>>>>> same >>>>>>> problem occurred at the end. >>>>>>> >>>>>>> It might be more useful looking at the code. Please have a look at the >>>>>>> function "f_thread" in the file uploaded on the following repo: >>>>>>> >>>>>>> https://github.com/koleini/parallelisation >>>>>> That's a lot of code to try and distill down a test case. Try to cut >>>>>> it >>>>>> down significantly by building a minimal Ethernet traffic generator >>>>>> that >>>>>> outputs frames with a predictable pattern in the frame, and a receiver >>>>>> that >>>>>> will check that the pattern is received as expected. >>>>>> >>>>>> Then you can try out your parallel algorithm variations on the simple >>>>>> Ethernet sender/receiver and narrow down the problem without all the >>>>>> other >>>>>> concerns. >>>>>> >>>>>> Once the bug is tracked down, we can add the sender/receiver into >>>>>> mirage-skeleton and use it as a test case to ensure that this >>>>>> functional >>>>>> never regresses in the future. Line rate Ethernet transmission has >>>>>> worked >>>>>> in the past, but we never added a test case to ensure it stays working. >>>>>> >>>>>> Anil >>>>>> _______________________________________________ >>>>>> MirageOS-devel mailing list >>>>>> MirageOS-devel@lists.xenproject.org >>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>>>> >>>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee and >>>> may contain confidential information. If you have received this message >>>> in >>>> error, please send it back to me, and immediately delete it. Please do >>>> not >>>> use, copy or disclose the information contained in this message or in any >>>> attachment. Any views or opinions expressed by the author of this email >>>> do >>>> not necessarily reflect the views of the University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an >>>> attachment >>>> may still contain software viruses which could damage your computer >>>> system, >>>> you are advised to perform your own checks. Email communications with the >>>> University of Nottingham may be monitored as permitted by UK legislation. >>>> >>> >> >> >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please send it back to me, and immediately delete it. Please do not >> use, copy or disclose the information contained in this message or in any >> attachment. Any views or opinions expressed by the author of this email do >> not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment >> may still contain software viruses which could damage your computer system, >> you are advised to perform your own checks. Email communications with the >> University of Nottingham may be monitored as permitted by UK legislation. >> > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:24:33 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:24:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZC4-00087B-0p; Thu, 18 Dec 2014 11:24:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZC2-000876-MZ for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:24:30 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 9E/45-18267-D69B2945; Thu, 18 Dec 2014 11:24:29 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-9.tower-31.messagelabs.com!1418901868!10587048!1 X-Originating-IP: [128.243.43.109] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31121 invoked from network); 18 Dec 2014 11:24:28 -0000 Received: from uidappmx01.nottingham.ac.uk (HELO uidappmx01.nottingham.ac.uk) (128.243.43.109) by server-9.tower-31.messagelabs.com with SMTP; 18 Dec 2014 11:24:28 -0000 Received: from uidappmx01.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4D7A23C47C5_492B96CB for ; Thu, 18 Dec 2014 11:24:28 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx01.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id E05433D538B_492B96BF for ; Thu, 18 Dec 2014 11:24:27 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1ZBz-00065T-S2; Thu, 18 Dec 2014 11:24:27 +0000 Message-ID: <5492B96B.4030909@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:24:27 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard , David Scott References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 18 December 2014 at 11:01, Masoud Koleini > wrote: >>> On 17 December 2014 at 18:05, Masoud >>> Koleini wrote: >>>> Thanks Thomas for the great tracing tool! >>>> >>>> The following is a very simple unikernel with two interfaces, which >>>> redirects frames captured on the first interface to the second one: >>>> >>>> https://github.com/koleini/parallelisation >>>> >>>> The problem is that in a high packet rate (more than 80'000 pps), switch >>>> stops receiving. The goal is to spot the problem and enhance the >>>> throughput >>>> of Mirage netif. >>> I don't know if this is the problem, but in the code, I see you do: >>> >>> listen if1 if2 >>> >> (forward_thread if2) >>> >>> This ignores the result from listen, so if the listen thread later >>> fails then the error will be discarded. I'd try something like this: >>> >>> Lwt.choose [ >>> listen if1 if2; >>> forward_thread if2 >>> ] >>> >>> (and lose the "return" at the end of listen) >> >> listen calls netif listen function, which only sets receive_callback on the >> interface (used by poll_thread). It looks that failing poll_thread is not >> monitored in netif code. > Hmm. You're right. Does it show anything if you catch errors there? I just tried it, nothing shown! > > Looks like it was changed here: > > https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c > > Perhaps listen could just return the poll thread, rather than making a > fake task. Dave? > >>> I really think the >> operator should be banned... >>> >>>> Test environment consists of another vm running a traffic generator and >>>> sending frames of a specific pattern (UDP frames of size 100 bytes) over >>>> the >>>> bridge that connects to the first interface of the unikernel. Unikernel >>>> forwards frames by collecting a number of frames from input queue and >>>> running the same number of threads that write them to the output >>>> interface. >>>> >>>> Two trace files are uploaded to the repo. The first file is the output of >>>> this configuration. This trace shows that each netif write locks until >>>> the >>>> thread that writes on the front-end connection to the ring is returned >>>> (function write_already_locked.) >>>> >>>> For the second trace, the return of the thread is ignored (commenting out >>>> "lwt () = th in" in write_already_locked). This considerably increases >>>> switching speed, but after some running time, it looks that after garbage >>>> collection, similar problem happens. >>>> >>>> Thomas and Anil, any idea from given traces, and how it is possible to >>>> make >>>> the traces more informative? >>>> >>>> Thanks. >>>> >>>> >>>> On 28/11/14 16:55, Thomas Leonard wrote: >>>>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>>>> wrote: >>>>>>> >>>>>>> Thanks Anil. >>>>>>> >>>>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>>>> Leonard's profiling patches should help here) >>>>>>> Would you please point me out to the profiling patches? >>>>>> See: >>>>>> >>>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>>>> The installation instructions here are for the previous version >>>>> (though they should still work). If you want to try the latest >>>>> version, the current Git mirage allows you to pass a ~tracing argument >>>>> to "register" in your config.ml, e.g. >>>>> >>>>> let tracing = mprof_trace ~size:1000000 () in >>>>> register "myunikernel" ~tracing [ >>>>> main $ ... >>>>> ] >>>>> >>>>> This uses a newer version of the profiling API. You should generally >>>>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>>>> >>>>> Note also that it doesn't currently record ring utilisation, so you'll >>>>> still need to do some work to get that. You could use the >>>>> MProf.Counter interface, in which case the GUI will display it as a >>>>> graph over the trace. >>>>> >>>>>>>> - try to reduce the parallelisation to see if some condition there >>>>>>>> alleviates the issue to track it down. >>>>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>>>> utilization, and vm was functioning for a much longer time, but the >>>>>>> same >>>>>>> problem occurred at the end. >>>>>>> >>>>>>> It might be more useful looking at the code. Please have a look at the >>>>>>> function "f_thread" in the file uploaded on the following repo: >>>>>>> >>>>>>> https://github.com/koleini/parallelisation >>>>>> That's a lot of code to try and distill down a test case. Try to cut >>>>>> it >>>>>> down significantly by building a minimal Ethernet traffic generator >>>>>> that >>>>>> outputs frames with a predictable pattern in the frame, and a receiver >>>>>> that >>>>>> will check that the pattern is received as expected. >>>>>> >>>>>> Then you can try out your parallel algorithm variations on the simple >>>>>> Ethernet sender/receiver and narrow down the problem without all the >>>>>> other >>>>>> concerns. >>>>>> >>>>>> Once the bug is tracked down, we can add the sender/receiver into >>>>>> mirage-skeleton and use it as a test case to ensure that this >>>>>> functional >>>>>> never regresses in the future. Line rate Ethernet transmission has >>>>>> worked >>>>>> in the past, but we never added a test case to ensure it stays working. >>>>>> >>>>>> Anil >>>>>> _______________________________________________ >>>>>> MirageOS-devel mailing list >>>>>> MirageOS-devel@lists.xenproject.org >>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>>>> >>>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee and >>>> may contain confidential information. If you have received this message >>>> in >>>> error, please send it back to me, and immediately delete it. Please do >>>> not >>>> use, copy or disclose the information contained in this message or in any >>>> attachment. Any views or opinions expressed by the author of this email >>>> do >>>> not necessarily reflect the views of the University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an >>>> attachment >>>> may still contain software viruses which could damage your computer >>>> system, >>>> you are advised to perform your own checks. Email communications with the >>>> University of Nottingham may be monitored as permitted by UK legislation. >>>> >>> >> >> >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please send it back to me, and immediately delete it. Please do not >> use, copy or disclose the information contained in this message or in any >> attachment. Any views or opinions expressed by the author of this email do >> not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment >> may still contain software viruses which could damage your computer system, >> you are advised to perform your own checks. Email communications with the >> University of Nottingham may be monitored as permitted by UK legislation. >> > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:31:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:31:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZJD-0008Hy-Tz; Thu, 18 Dec 2014 11:31:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZJC-0008Hs-9L for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:31:54 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id 77/86-26740-92BB2945; Thu, 18 Dec 2014 11:31:53 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1418902309!11867935!1 X-Originating-IP: [209.85.192.182] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12544 invoked from network); 18 Dec 2014 11:31:51 -0000 Received: from mail-pd0-f182.google.com (HELO mail-pd0-f182.google.com) (209.85.192.182) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 11:31:51 -0000 Received: by mail-pd0-f182.google.com with SMTP id p10so1248562pdj.27 for ; Thu, 18 Dec 2014 03:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pJ7GKJnknyMsin1p4AqhkAwq5WJ7j+utzUjcR8+/P6s=; b=oVCZO/IfS1ZMU64h1addSEMBuJwuonFdKPZuuj8AkO4kpjsX59E7B+prP9xCOgF/x7 rpuCWv/xYRmKt8OPJzB7B0zKd3M/v3+T9cgxH3Z8eiTqgtBAzJhMtTjFzMj9xulq3lZX MtoDWeSb4VbOKqD8o7Uja07aRJE9EXJAHjHXH+bqoMfzTI+lwFeui9KevZsP7HtuHEXF SFuZIDoRLMgbIn30rjRD5/bmAjN/lf0/+uDiI7tXHp3GrUwPaqfY223kBXq2BQZKt3Yv Md3G+mapEW9U+aZeVTZ3ycZaQe/+uCL4vnlthSOdilLivHRi/59X3x6WtSWa99LJ9Uj4 OBJg== MIME-Version: 1.0 X-Received: by 10.67.3.165 with SMTP id bx5mr2476506pad.59.1418902309360; Thu, 18 Dec 2014 03:31:49 -0800 (PST) Received: by 10.70.93.65 with HTTP; Thu, 18 Dec 2014 03:31:49 -0800 (PST) In-Reply-To: References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:31:49 +0000 Message-ID: From: David Scott To: Thomas Leonard Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6061839652950290902==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6061839652950290902== Content-Type: multipart/alternative; boundary=001a113818881eda51050a7bf0f0 --001a113818881eda51050a7bf0f0 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard wrote: > > On 18 December 2014 at 11:01, Masoud Koleini > wrote: > > > >> On 17 December 2014 at 18:05, Masoud > >> Koleini wrote: > >>> > >>> Thanks Thomas for the great tracing tool! > >>> > >>> The following is a very simple unikernel with two interfaces, which > >>> redirects frames captured on the first interface to the second one: > >>> > >>> https://github.com/koleini/parallelisation > >>> > >>> The problem is that in a high packet rate (more than 80'000 pps), > switch > >>> stops receiving. The goal is to spot the problem and enhance the > >>> throughput > >>> of Mirage netif. > >> > >> I don't know if this is the problem, but in the code, I see you do: > >> > >> listen if1 if2 > >> >> (forward_thread if2) > >> > >> This ignores the result from listen, so if the listen thread later > >> fails then the error will be discarded. I'd try something like this: > >> > >> Lwt.choose [ > >> listen if1 if2; > >> forward_thread if2 > >> ] > >> > >> (and lose the "return" at the end of listen) > > > > > > listen calls netif listen function, which only sets receive_callback on > the > > interface (used by poll_thread). It looks that failing poll_thread is not > > monitored in netif code. > > Hmm. You're right. Does it show anything if you catch errors there? > > Looks like it was changed here: > > > https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c > > Perhaps listen could just return the poll thread, rather than making a > fake task. Dave? > Ah yes, good idea. If that callback fails then we're going to fail silently. Dave > > >> I really think the >> operator should be banned... > >> > >>> Test environment consists of another vm running a traffic generator and > >>> sending frames of a specific pattern (UDP frames of size 100 bytes) > over > >>> the > >>> bridge that connects to the first interface of the unikernel. Unikernel > >>> forwards frames by collecting a number of frames from input queue and > >>> running the same number of threads that write them to the output > >>> interface. > >>> > >>> Two trace files are uploaded to the repo. The first file is the output > of > >>> this configuration. This trace shows that each netif write locks until > >>> the > >>> thread that writes on the front-end connection to the ring is returned > >>> (function write_already_locked.) > >>> > >>> For the second trace, the return of the thread is ignored (commenting > out > >>> "lwt () = th in" in write_already_locked). This considerably increases > >>> switching speed, but after some running time, it looks that after > garbage > >>> collection, similar problem happens. > >>> > >>> Thomas and Anil, any idea from given traces, and how it is possible to > >>> make > >>> the traces more informative? > >>> > >>> Thanks. > >>> > >>> > >>> On 28/11/14 16:55, Thomas Leonard wrote: > >>>> > >>>> On 28 November 2014 at 16:24, Anil Madhavapeddy > wrote: > >>>>>> > >>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini > >>>>>> wrote: > >>>>>> > >>>>>> Thanks Anil. > >>>>>> > >>>>>>> - graph the ring utilisation to see if it's always full (Thomas > >>>>>>> Leonard's profiling patches should help here) > >>>>>> > >>>>>> Would you please point me out to the profiling patches? > >>>>> > >>>>> See: > >>>>> > >>>>> > http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ > >>>> > >>>> The installation instructions here are for the previous version > >>>> (though they should still work). If you want to try the latest > >>>> version, the current Git mirage allows you to pass a ~tracing argument > >>>> to "register" in your config.ml, e.g. > >>>> > >>>> let tracing = mprof_trace ~size:1000000 () in > >>>> register "myunikernel" ~tracing [ > >>>> main $ ... > >>>> ] > >>>> > >>>> This uses a newer version of the profiling API. You should generally > >>>> "opam pin" the #tracing2 branches rather than #tracing to use it. > >>>> > >>>> Note also that it doesn't currently record ring utilisation, so you'll > >>>> still need to do some work to get that. You could use the > >>>> MProf.Counter interface, in which case the GUI will display it as a > >>>> graph over the trace. > >>>> > >>>>>>> - try to reduce the parallelisation to see if some condition there > >>>>>>> alleviates the issue to track it down. > >>>>>> > >>>>>> Reducing the maximum number of threads running in parallel reduced > CPU > >>>>>> utilization, and vm was functioning for a much longer time, but the > >>>>>> same > >>>>>> problem occurred at the end. > >>>>>> > >>>>>> It might be more useful looking at the code. Please have a look at > the > >>>>>> function "f_thread" in the file uploaded on the following repo: > >>>>>> > >>>>>> https://github.com/koleini/parallelisation > >>>>> > >>>>> That's a lot of code to try and distill down a test case. Try to cut > >>>>> it > >>>>> down significantly by building a minimal Ethernet traffic generator > >>>>> that > >>>>> outputs frames with a predictable pattern in the frame, and a > receiver > >>>>> that > >>>>> will check that the pattern is received as expected. > >>>>> > >>>>> Then you can try out your parallel algorithm variations on the simple > >>>>> Ethernet sender/receiver and narrow down the problem without all the > >>>>> other > >>>>> concerns. > >>>>> > >>>>> Once the bug is tracked down, we can add the sender/receiver into > >>>>> mirage-skeleton and use it as a test case to ensure that this > >>>>> functional > >>>>> never regresses in the future. Line rate Ethernet transmission has > >>>>> worked > >>>>> in the past, but we never added a test case to ensure it stays > working. > >>>>> > >>>>> Anil > >>>>> _______________________________________________ > >>>>> MirageOS-devel mailing list > >>>>> MirageOS-devel@lists.xenproject.org > >>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> This message and any attachment are intended solely for the addressee > and > >>> may contain confidential information. If you have received this message > >>> in > >>> error, please send it back to me, and immediately delete it. Please > do > >>> not > >>> use, copy or disclose the information contained in this message or in > any > >>> attachment. Any views or opinions expressed by the author of this > email > >>> do > >>> not necessarily reflect the views of the University of Nottingham. > >>> > >>> This message has been checked for viruses but the contents of an > >>> attachment > >>> may still contain software viruses which could damage your computer > >>> system, > >>> you are advised to perform your own checks. Email communications with > the > >>> University of Nottingham may be monitored as permitted by UK > legislation. > >>> > >> > >> > > > > > > > > > > > > This message and any attachment are intended solely for the addressee and > > may contain confidential information. If you have received this message > in > > error, please send it back to me, and immediately delete it. Please do > not > > use, copy or disclose the information contained in this message or in any > > attachment. Any views or opinions expressed by the author of this email > do > > not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > attachment > > may still contain software viruses which could damage your computer > system, > > you are advised to perform your own checks. Email communications with the > > University of Nottingham may be monitored as permitted by UK legislation. > > > > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Dave Scott --001a113818881eda51050a7bf0f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard <= talex5@gmail.com&= gt; wrote:
On 18 December 2014 at 11:0= 1, Masoud Koleini
<mas= oud.koleini@nottingham.ac.uk> wrote:
>
>> On 17 December 2014 at 18:05, Masoud
>> Koleini<maso= ud.koleini@nottingham.ac.uk> wrote:
>>>
>>> Thanks Thomas for the great tracing tool!
>>>
>>> The following is a very simple unikernel with two interfaces, = which
>>> redirects frames captured on the first interface to the second= one:
>>>
>>> https://github.com/koleini/parallelisation
>>>
>>> The problem is that in a high packet rate (more than 80'00= 0 pps), switch
>>> stops receiving. The goal is to spot the problem and enhance t= he
>>> throughput
>>> of Mirage netif.
>>
>> I don't know if this is the problem, but in the code, I see yo= u do:
>>
>>=C2=A0 =C2=A0 listen if1 if2
>>=C2=A0 =C2=A0 >> (forward_thread if2)
>>
>> This ignores the result from listen, so if the listen thread later=
>> fails then the error will be discarded. I'd try something like= this:
>>
>>=C2=A0 =C2=A0 Lwt.choose [
>>=C2=A0 =C2=A0 =C2=A0 listen if1 if2;
>>=C2=A0 =C2=A0 =C2=A0 forward_thread if2
>>=C2=A0 =C2=A0 ]
>>
>> (and lose the "return" at the end of listen)
>
>
> listen calls netif listen function, which only sets receive_callback o= n the
> interface (used by poll_thread). It looks that failing poll_thread is = not
> monitored in netif code.

Hmm. You're right. Does it show anything if you catch errors the= re?

Looks like it was changed here:

https://github.com/mirage/mirag= e-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c

Perhaps listen could just return the poll thread, rather than making a
fake task. Dave?

Ah yes, good idea. If = that callback fails then we're going to fail silently.

Dave
=C2=A0

>> I really think the >> operator should be banned...
>>
>>> Test environment consists of another vm running a traffic gene= rator and
>>> sending frames of a specific pattern (UDP frames of size 100 b= ytes) over
>>> the
>>> bridge that connects to the first interface of the unikernel. = Unikernel
>>> forwards frames by collecting a number of frames from input qu= eue and
>>> running the same number of threads that write them to the outp= ut
>>> interface.
>>>
>>> Two trace files are uploaded to the repo. The first file is th= e output of
>>> this configuration. This trace shows that each netif write loc= ks until
>>> the
>>> thread that writes on the front-end connection to the ring is = returned
>>> (function write_already_locked.)
>>>
>>> For the second trace, the return of the thread is ignored (com= menting out
>>> "lwt () =3D th in" in write_already_locked). This co= nsiderably increases
>>> switching speed, but after some running time, it looks that af= ter garbage
>>> collection, similar problem happens.
>>>
>>> Thomas and Anil, any idea from given traces, and how it is pos= sible to
>>> make
>>> the traces more informative?
>>>
>>> Thanks.
>>>
>>>
>>> On 28/11/14 16:55, Thomas Leonard wrote:
>>>>
>>>> On 28 November 2014 at 16:24, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>>>>
>>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini
>>>>>> <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>>
>>>>>> Thanks Anil.
>>>>>>
>>>>>>> - graph the ring utilisation to see if it'= s always full (Thomas
>>>>>>> Leonard's profiling patches should help he= re)
>>>>>>
>>>>>> Would you please point me out to the profiling pat= ches?
>>>>>
>>>>> See:
>>>>>
>>>>> http://roscidus.com/blo= g/blog/2014/10/27/visualising-an-asynchronous-monad/
>>>>
>>>> The installation instructions here are for the previous ve= rsion
>>>> (though they should still work). If you want to try the la= test
>>>> version, the current Git mirage allows you to pass a ~trac= ing argument
>>>> to "register" in your config.ml, e.g.
>>>>
>>>> let tracing =3D mprof_trace ~size:1000000 () in
>>>> register "myunikernel" ~tracing [
>>>>=C2=A0 =C2=A0 =C2=A0main $ ...
>>>> ]
>>>>
>>>> This uses a newer version of the profiling API. You should= generally
>>>> "opam pin" the #tracing2 branches rather than #t= racing to use it.
>>>>
>>>> Note also that it doesn't currently record ring utilis= ation, so you'll
>>>> still need to do some work to get that. You could use the<= br> >>>> MProf.Counter interface, in which case the GUI will displa= y it as a
>>>> graph over the trace.
>>>>
>>>>>>> - try to reduce the parallelisation to see if = some condition there
>>>>>>> alleviates the issue to track it down.
>>>>>>
>>>>>> Reducing the maximum number of threads running in = parallel reduced CPU
>>>>>> utilization, and vm was functioning for a much lon= ger time, but the
>>>>>> same
>>>>>> problem occurred at the end.
>>>>>>
>>>>>> It might be more useful looking at the code. Pleas= e have a look at the
>>>>>> function "f_thread" in the file uploaded= on the following repo:
>>>>>>
>>>>>> https://github.com/koleini/parallelisation
>>>>>
>>>>> That's a lot of code to try and distill down a tes= t case.=C2=A0 Try to cut
>>>>> it
>>>>> down significantly by building a minimal Ethernet traf= fic generator
>>>>> that
>>>>> outputs frames with a predictable pattern in the frame= , and a receiver
>>>>> that
>>>>> will check that the pattern is received as expected. >>>>>
>>>>> Then you can try out your parallel algorithm variation= s on the simple
>>>>> Ethernet sender/receiver and narrow down the problem w= ithout all the
>>>>> other
>>>>> concerns.
>>>>>
>>>>> Once the bug is tracked down, we can add the sender/re= ceiver into
>>>>> mirage-skeleton and use it as a test case to ensure th= at this
>>>>> functional
>>>>> never regresses in the future.=C2=A0 Line rate Etherne= t transmission has
>>>>> worked
>>>>> in the past, but we never added a test case to ensure = it stays working.
>>>>>
>>>>> Anil
>>>>> _______________________________________________
>>>>> MirageOS-devel mailing list
>>>>> MirageOS-devel@lists.xenproject.org
>>>>> http://lists.xenproject.org/cgi= -bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> This message and any attachment are intended solely for the ad= dressee and
>>> may contain confidential information. If you have received thi= s message
>>> in
>>> error, please send it back to me, and immediately delete it.= =C2=A0 =C2=A0Please do
>>> not
>>> use, copy or disclose the information contained in this messag= e or in any
>>> attachment.=C2=A0 Any views or opinions expressed by the autho= r of this email
>>> do
>>> not necessarily reflect the views of the University of Notting= ham.
>>>
>>> This message has been checked for viruses but the contents of = an
>>> attachment
>>> may still contain software viruses which could damage your com= puter
>>> system,
>>> you are advised to perform your own checks. Email communicatio= ns with the
>>> University of Nottingham may be monitored as permitted by UK l= egislation.
>>>
>>
>>
>
>
>
>
>
> This message and any attachment are intended solely for the addressee = and
> may contain confidential information. If you have received this messag= e in
> error, please send it back to me, and immediately delete it.=C2=A0 =C2= =A0Please do not
> use, copy or disclose the information contained in this message or in = any
> attachment.=C2=A0 Any views or opinions expressed by the author of thi= s email do
> not necessarily reflect the views of the University of Nottingham.
>
> This message has been checked for viruses but the contents of an attac= hment
> may still contain software viruses which could damage your computer sy= stem,
> you are advised to perform your own checks. Email communications with = the
> University of Nottingham may be monitored as permitted by UK legislati= on.
>



--
Dr Thomas Leonard=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://0install.net/
GPG: 9242 9807 C985 3C07 44A6=C2=A0 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA=C2=A0 BD8E 0713 3F96 CA74 D8BA

____________________________= ___________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Dave Scott
--001a113818881eda51050a7bf0f0-- --===============6061839652950290902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6061839652950290902==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 11:31:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 11:31:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZJD-0008Hy-Tz; Thu, 18 Dec 2014 11:31:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ZJC-0008Hs-9L for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 11:31:54 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id 77/86-26740-92BB2945; Thu, 18 Dec 2014 11:31:53 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1418902309!11867935!1 X-Originating-IP: [209.85.192.182] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12544 invoked from network); 18 Dec 2014 11:31:51 -0000 Received: from mail-pd0-f182.google.com (HELO mail-pd0-f182.google.com) (209.85.192.182) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 11:31:51 -0000 Received: by mail-pd0-f182.google.com with SMTP id p10so1248562pdj.27 for ; Thu, 18 Dec 2014 03:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pJ7GKJnknyMsin1p4AqhkAwq5WJ7j+utzUjcR8+/P6s=; b=oVCZO/IfS1ZMU64h1addSEMBuJwuonFdKPZuuj8AkO4kpjsX59E7B+prP9xCOgF/x7 rpuCWv/xYRmKt8OPJzB7B0zKd3M/v3+T9cgxH3Z8eiTqgtBAzJhMtTjFzMj9xulq3lZX MtoDWeSb4VbOKqD8o7Uja07aRJE9EXJAHjHXH+bqoMfzTI+lwFeui9KevZsP7HtuHEXF SFuZIDoRLMgbIn30rjRD5/bmAjN/lf0/+uDiI7tXHp3GrUwPaqfY223kBXq2BQZKt3Yv Md3G+mapEW9U+aZeVTZ3ycZaQe/+uCL4vnlthSOdilLivHRi/59X3x6WtSWa99LJ9Uj4 OBJg== MIME-Version: 1.0 X-Received: by 10.67.3.165 with SMTP id bx5mr2476506pad.59.1418902309360; Thu, 18 Dec 2014 03:31:49 -0800 (PST) Received: by 10.70.93.65 with HTTP; Thu, 18 Dec 2014 03:31:49 -0800 (PST) In-Reply-To: References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> Date: Thu, 18 Dec 2014 11:31:49 +0000 Message-ID: From: David Scott To: Thomas Leonard Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6061839652950290902==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6061839652950290902== Content-Type: multipart/alternative; boundary=001a113818881eda51050a7bf0f0 --001a113818881eda51050a7bf0f0 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard wrote: > > On 18 December 2014 at 11:01, Masoud Koleini > wrote: > > > >> On 17 December 2014 at 18:05, Masoud > >> Koleini wrote: > >>> > >>> Thanks Thomas for the great tracing tool! > >>> > >>> The following is a very simple unikernel with two interfaces, which > >>> redirects frames captured on the first interface to the second one: > >>> > >>> https://github.com/koleini/parallelisation > >>> > >>> The problem is that in a high packet rate (more than 80'000 pps), > switch > >>> stops receiving. The goal is to spot the problem and enhance the > >>> throughput > >>> of Mirage netif. > >> > >> I don't know if this is the problem, but in the code, I see you do: > >> > >> listen if1 if2 > >> >> (forward_thread if2) > >> > >> This ignores the result from listen, so if the listen thread later > >> fails then the error will be discarded. I'd try something like this: > >> > >> Lwt.choose [ > >> listen if1 if2; > >> forward_thread if2 > >> ] > >> > >> (and lose the "return" at the end of listen) > > > > > > listen calls netif listen function, which only sets receive_callback on > the > > interface (used by poll_thread). It looks that failing poll_thread is not > > monitored in netif code. > > Hmm. You're right. Does it show anything if you catch errors there? > > Looks like it was changed here: > > > https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c > > Perhaps listen could just return the poll thread, rather than making a > fake task. Dave? > Ah yes, good idea. If that callback fails then we're going to fail silently. Dave > > >> I really think the >> operator should be banned... > >> > >>> Test environment consists of another vm running a traffic generator and > >>> sending frames of a specific pattern (UDP frames of size 100 bytes) > over > >>> the > >>> bridge that connects to the first interface of the unikernel. Unikernel > >>> forwards frames by collecting a number of frames from input queue and > >>> running the same number of threads that write them to the output > >>> interface. > >>> > >>> Two trace files are uploaded to the repo. The first file is the output > of > >>> this configuration. This trace shows that each netif write locks until > >>> the > >>> thread that writes on the front-end connection to the ring is returned > >>> (function write_already_locked.) > >>> > >>> For the second trace, the return of the thread is ignored (commenting > out > >>> "lwt () = th in" in write_already_locked). This considerably increases > >>> switching speed, but after some running time, it looks that after > garbage > >>> collection, similar problem happens. > >>> > >>> Thomas and Anil, any idea from given traces, and how it is possible to > >>> make > >>> the traces more informative? > >>> > >>> Thanks. > >>> > >>> > >>> On 28/11/14 16:55, Thomas Leonard wrote: > >>>> > >>>> On 28 November 2014 at 16:24, Anil Madhavapeddy > wrote: > >>>>>> > >>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini > >>>>>> wrote: > >>>>>> > >>>>>> Thanks Anil. > >>>>>> > >>>>>>> - graph the ring utilisation to see if it's always full (Thomas > >>>>>>> Leonard's profiling patches should help here) > >>>>>> > >>>>>> Would you please point me out to the profiling patches? > >>>>> > >>>>> See: > >>>>> > >>>>> > http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ > >>>> > >>>> The installation instructions here are for the previous version > >>>> (though they should still work). If you want to try the latest > >>>> version, the current Git mirage allows you to pass a ~tracing argument > >>>> to "register" in your config.ml, e.g. > >>>> > >>>> let tracing = mprof_trace ~size:1000000 () in > >>>> register "myunikernel" ~tracing [ > >>>> main $ ... > >>>> ] > >>>> > >>>> This uses a newer version of the profiling API. You should generally > >>>> "opam pin" the #tracing2 branches rather than #tracing to use it. > >>>> > >>>> Note also that it doesn't currently record ring utilisation, so you'll > >>>> still need to do some work to get that. You could use the > >>>> MProf.Counter interface, in which case the GUI will display it as a > >>>> graph over the trace. > >>>> > >>>>>>> - try to reduce the parallelisation to see if some condition there > >>>>>>> alleviates the issue to track it down. > >>>>>> > >>>>>> Reducing the maximum number of threads running in parallel reduced > CPU > >>>>>> utilization, and vm was functioning for a much longer time, but the > >>>>>> same > >>>>>> problem occurred at the end. > >>>>>> > >>>>>> It might be more useful looking at the code. Please have a look at > the > >>>>>> function "f_thread" in the file uploaded on the following repo: > >>>>>> > >>>>>> https://github.com/koleini/parallelisation > >>>>> > >>>>> That's a lot of code to try and distill down a test case. Try to cut > >>>>> it > >>>>> down significantly by building a minimal Ethernet traffic generator > >>>>> that > >>>>> outputs frames with a predictable pattern in the frame, and a > receiver > >>>>> that > >>>>> will check that the pattern is received as expected. > >>>>> > >>>>> Then you can try out your parallel algorithm variations on the simple > >>>>> Ethernet sender/receiver and narrow down the problem without all the > >>>>> other > >>>>> concerns. > >>>>> > >>>>> Once the bug is tracked down, we can add the sender/receiver into > >>>>> mirage-skeleton and use it as a test case to ensure that this > >>>>> functional > >>>>> never regresses in the future. Line rate Ethernet transmission has > >>>>> worked > >>>>> in the past, but we never added a test case to ensure it stays > working. > >>>>> > >>>>> Anil > >>>>> _______________________________________________ > >>>>> MirageOS-devel mailing list > >>>>> MirageOS-devel@lists.xenproject.org > >>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> This message and any attachment are intended solely for the addressee > and > >>> may contain confidential information. If you have received this message > >>> in > >>> error, please send it back to me, and immediately delete it. Please > do > >>> not > >>> use, copy or disclose the information contained in this message or in > any > >>> attachment. Any views or opinions expressed by the author of this > email > >>> do > >>> not necessarily reflect the views of the University of Nottingham. > >>> > >>> This message has been checked for viruses but the contents of an > >>> attachment > >>> may still contain software viruses which could damage your computer > >>> system, > >>> you are advised to perform your own checks. Email communications with > the > >>> University of Nottingham may be monitored as permitted by UK > legislation. > >>> > >> > >> > > > > > > > > > > > > This message and any attachment are intended solely for the addressee and > > may contain confidential information. If you have received this message > in > > error, please send it back to me, and immediately delete it. Please do > not > > use, copy or disclose the information contained in this message or in any > > attachment. Any views or opinions expressed by the author of this email > do > > not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > attachment > > may still contain software viruses which could damage your computer > system, > > you are advised to perform your own checks. Email communications with the > > University of Nottingham may be monitored as permitted by UK legislation. > > > > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Dave Scott --001a113818881eda51050a7bf0f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard <= talex5@gmail.com&= gt; wrote:
On 18 December 2014 at 11:0= 1, Masoud Koleini
<mas= oud.koleini@nottingham.ac.uk> wrote:
>
>> On 17 December 2014 at 18:05, Masoud
>> Koleini<maso= ud.koleini@nottingham.ac.uk> wrote:
>>>
>>> Thanks Thomas for the great tracing tool!
>>>
>>> The following is a very simple unikernel with two interfaces, = which
>>> redirects frames captured on the first interface to the second= one:
>>>
>>> https://github.com/koleini/parallelisation
>>>
>>> The problem is that in a high packet rate (more than 80'00= 0 pps), switch
>>> stops receiving. The goal is to spot the problem and enhance t= he
>>> throughput
>>> of Mirage netif.
>>
>> I don't know if this is the problem, but in the code, I see yo= u do:
>>
>>=C2=A0 =C2=A0 listen if1 if2
>>=C2=A0 =C2=A0 >> (forward_thread if2)
>>
>> This ignores the result from listen, so if the listen thread later=
>> fails then the error will be discarded. I'd try something like= this:
>>
>>=C2=A0 =C2=A0 Lwt.choose [
>>=C2=A0 =C2=A0 =C2=A0 listen if1 if2;
>>=C2=A0 =C2=A0 =C2=A0 forward_thread if2
>>=C2=A0 =C2=A0 ]
>>
>> (and lose the "return" at the end of listen)
>
>
> listen calls netif listen function, which only sets receive_callback o= n the
> interface (used by poll_thread). It looks that failing poll_thread is = not
> monitored in netif code.

Hmm. You're right. Does it show anything if you catch errors the= re?

Looks like it was changed here:

https://github.com/mirage/mirag= e-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c

Perhaps listen could just return the poll thread, rather than making a
fake task. Dave?

Ah yes, good idea. If = that callback fails then we're going to fail silently.

Dave
=C2=A0

>> I really think the >> operator should be banned...
>>
>>> Test environment consists of another vm running a traffic gene= rator and
>>> sending frames of a specific pattern (UDP frames of size 100 b= ytes) over
>>> the
>>> bridge that connects to the first interface of the unikernel. = Unikernel
>>> forwards frames by collecting a number of frames from input qu= eue and
>>> running the same number of threads that write them to the outp= ut
>>> interface.
>>>
>>> Two trace files are uploaded to the repo. The first file is th= e output of
>>> this configuration. This trace shows that each netif write loc= ks until
>>> the
>>> thread that writes on the front-end connection to the ring is = returned
>>> (function write_already_locked.)
>>>
>>> For the second trace, the return of the thread is ignored (com= menting out
>>> "lwt () =3D th in" in write_already_locked). This co= nsiderably increases
>>> switching speed, but after some running time, it looks that af= ter garbage
>>> collection, similar problem happens.
>>>
>>> Thomas and Anil, any idea from given traces, and how it is pos= sible to
>>> make
>>> the traces more informative?
>>>
>>> Thanks.
>>>
>>>
>>> On 28/11/14 16:55, Thomas Leonard wrote:
>>>>
>>>> On 28 November 2014 at 16:24, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>>>>
>>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini
>>>>>> <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>>
>>>>>> Thanks Anil.
>>>>>>
>>>>>>> - graph the ring utilisation to see if it'= s always full (Thomas
>>>>>>> Leonard's profiling patches should help he= re)
>>>>>>
>>>>>> Would you please point me out to the profiling pat= ches?
>>>>>
>>>>> See:
>>>>>
>>>>> http://roscidus.com/blo= g/blog/2014/10/27/visualising-an-asynchronous-monad/
>>>>
>>>> The installation instructions here are for the previous ve= rsion
>>>> (though they should still work). If you want to try the la= test
>>>> version, the current Git mirage allows you to pass a ~trac= ing argument
>>>> to "register" in your config.ml, e.g.
>>>>
>>>> let tracing =3D mprof_trace ~size:1000000 () in
>>>> register "myunikernel" ~tracing [
>>>>=C2=A0 =C2=A0 =C2=A0main $ ...
>>>> ]
>>>>
>>>> This uses a newer version of the profiling API. You should= generally
>>>> "opam pin" the #tracing2 branches rather than #t= racing to use it.
>>>>
>>>> Note also that it doesn't currently record ring utilis= ation, so you'll
>>>> still need to do some work to get that. You could use the<= br> >>>> MProf.Counter interface, in which case the GUI will displa= y it as a
>>>> graph over the trace.
>>>>
>>>>>>> - try to reduce the parallelisation to see if = some condition there
>>>>>>> alleviates the issue to track it down.
>>>>>>
>>>>>> Reducing the maximum number of threads running in = parallel reduced CPU
>>>>>> utilization, and vm was functioning for a much lon= ger time, but the
>>>>>> same
>>>>>> problem occurred at the end.
>>>>>>
>>>>>> It might be more useful looking at the code. Pleas= e have a look at the
>>>>>> function "f_thread" in the file uploaded= on the following repo:
>>>>>>
>>>>>> https://github.com/koleini/parallelisation
>>>>>
>>>>> That's a lot of code to try and distill down a tes= t case.=C2=A0 Try to cut
>>>>> it
>>>>> down significantly by building a minimal Ethernet traf= fic generator
>>>>> that
>>>>> outputs frames with a predictable pattern in the frame= , and a receiver
>>>>> that
>>>>> will check that the pattern is received as expected. >>>>>
>>>>> Then you can try out your parallel algorithm variation= s on the simple
>>>>> Ethernet sender/receiver and narrow down the problem w= ithout all the
>>>>> other
>>>>> concerns.
>>>>>
>>>>> Once the bug is tracked down, we can add the sender/re= ceiver into
>>>>> mirage-skeleton and use it as a test case to ensure th= at this
>>>>> functional
>>>>> never regresses in the future.=C2=A0 Line rate Etherne= t transmission has
>>>>> worked
>>>>> in the past, but we never added a test case to ensure = it stays working.
>>>>>
>>>>> Anil
>>>>> _______________________________________________
>>>>> MirageOS-devel mailing list
>>>>> MirageOS-devel@lists.xenproject.org
>>>>> http://lists.xenproject.org/cgi= -bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> This message and any attachment are intended solely for the ad= dressee and
>>> may contain confidential information. If you have received thi= s message
>>> in
>>> error, please send it back to me, and immediately delete it.= =C2=A0 =C2=A0Please do
>>> not
>>> use, copy or disclose the information contained in this messag= e or in any
>>> attachment.=C2=A0 Any views or opinions expressed by the autho= r of this email
>>> do
>>> not necessarily reflect the views of the University of Notting= ham.
>>>
>>> This message has been checked for viruses but the contents of = an
>>> attachment
>>> may still contain software viruses which could damage your com= puter
>>> system,
>>> you are advised to perform your own checks. Email communicatio= ns with the
>>> University of Nottingham may be monitored as permitted by UK l= egislation.
>>>
>>
>>
>
>
>
>
>
> This message and any attachment are intended solely for the addressee = and
> may contain confidential information. If you have received this messag= e in
> error, please send it back to me, and immediately delete it.=C2=A0 =C2= =A0Please do not
> use, copy or disclose the information contained in this message or in = any
> attachment.=C2=A0 Any views or opinions expressed by the author of thi= s email do
> not necessarily reflect the views of the University of Nottingham.
>
> This message has been checked for viruses but the contents of an attac= hment
> may still contain software viruses which could damage your computer sy= stem,
> you are advised to perform your own checks. Email communications with = the
> University of Nottingham may be monitored as permitted by UK legislati= on.
>



--
Dr Thomas Leonard=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://0install.net/
GPG: 9242 9807 C985 3C07 44A6=C2=A0 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA=C2=A0 BD8E 0713 3F96 CA74 D8BA

____________________________= ___________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Dave Scott
--001a113818881eda51050a7bf0f0-- --===============6061839652950290902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6061839652950290902==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 12:41:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 12:41:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1aOC-0003Xp-3k; Thu, 18 Dec 2014 12:41:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1aOA-0003Xh-S3 for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:41:07 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id A8/46-26652-26BC2945; Thu, 18 Dec 2014 12:41:06 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-7.tower-206.messagelabs.com!1418906464!14149971!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8366 invoked from network); 18 Dec 2014 12:41:04 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-7.tower-206.messagelabs.com with SMTP; 18 Dec 2014 12:41:04 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E747330C947_492CB5FB; Thu, 18 Dec 2014 12:41:03 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 71316304BFD_492CB5FF; Thu, 18 Dec 2014 12:41:03 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1aO7-0005UC-DL; Thu, 18 Dec 2014 12:41:03 +0000 Message-ID: <5492CB5F.3060103@nottingham.ac.uk> Date: Thu, 18 Dec 2014 12:41:03 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Scott , Thomas Leonard References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2962862681788400918==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============2962862681788400918== Content-Type: multipart/alternative; boundary="------------090603000705050702050803" This is a multi-part message in MIME format. --------------090603000705050702050803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Length: 10770 Content-Transfer-Encoding: quoted-printable On 18/12/14 11:31, David Scott wrote: > > > On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard > wrote: > > On 18 December 2014 at 11:01, Masoud Koleini > > wrote: > > > >> On 17 December 2014 at 18:05, Masoud > >> Koleini > wrote: > >>> > >>> Thanks Thomas for the great tracing tool! > >>> > >>> The following is a very simple unikernel with two interfaces, > which > >>> redirects frames captured on the first interface to the second > one: > >>> > >>> https://github.com/koleini/parallelisation > >>> > >>> The problem is that in a high packet rate (more than 80'000 > pps), switch > >>> stops receiving. The goal is to spot the problem and enhance the > >>> throughput > >>> of Mirage netif. > >> > >> I don't know if this is the problem, but in the code, I see you do: > >> > >> listen if1 if2 > >> >> (forward_thread if2) > >> > >> This ignores the result from listen, so if the listen thread later > >> fails then the error will be discarded. I'd try something like > this: > >> > >> Lwt.choose [ > >> listen if1 if2; > >> forward_thread if2 > >> ] > >> > >> (and lose the "return" at the end of listen) > > > > > > listen calls netif listen function, which only sets > receive_callback on the > > interface (used by poll_thread). It looks that failing > poll_thread is not > > monitored in netif code. > > Hmm. You're right. Does it show anything if you catch errors there=3F > > Looks like it was changed here: > > https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c > > Perhaps listen could just return the poll thread, rather than making a > fake task. Dave=3F > > > Ah yes, good idea. If that callback fails then we're going to fail > silently. > > Dave I have modified listen to return poll thread. Poll threads are not failing when switch stops working. > > >> I really think the >> operator should be banned... > >> > >>> Test environment consists of another vm running a traffic > generator and > >>> sending frames of a specific pattern (UDP frames of size 100 > bytes) over > >>> the > >>> bridge that connects to the first interface of the unikernel. > Unikernel > >>> forwards frames by collecting a number of frames from input > queue and > >>> running the same number of threads that write them to the output > >>> interface. > >>> > >>> Two trace files are uploaded to the repo. The first file is > the output of > >>> this configuration. This trace shows that each netif write > locks until > >>> the > >>> thread that writes on the front-end connection to the ring is > returned > >>> (function write_already_locked.) > >>> > >>> For the second trace, the return of the thread is ignored > (commenting out > >>> "lwt () =3D th in" in write_already_locked). This considerably > increases > >>> switching speed, but after some running time, it looks that > after garbage > >>> collection, similar problem happens. > >>> > >>> Thomas and Anil, any idea from given traces, and how it is > possible to > >>> make > >>> the traces more informative=3F > >>> > >>> Thanks. > >>> > >>> > >>> On 28/11/14 16:55, Thomas Leonard wrote: > >>>> > >>>> On 28 November 2014 at 16:24, Anil Madhavapeddy > > wrote: > >>>>>> > >>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini > >>>>>> > wrote: > >>>>>> > >>>>>> Thanks Anil. > >>>>>> > >>>>>>> - graph the ring utilisation to see if it's always full > (Thomas > >>>>>>> Leonard's profiling patches should help here) > >>>>>> > >>>>>> Would you please point me out to the profiling patches=3F > >>>>> > >>>>> See: > >>>>> > >>>>> > http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ > >>>> > >>>> The installation instructions here are for the previous version > >>>> (though they should still work). If you want to try the latest > >>>> version, the current Git mirage allows you to pass a ~tracing > argument > >>>> to "register" in your config.ml , e.g. > >>>> > >>>> let tracing =3D mprof_trace ~size:1000000 () in > >>>> register "myunikernel" ~tracing [ > >>>> main $ ... > >>>> ] > >>>> > >>>> This uses a newer version of the profiling API. You should > generally > >>>> "opam pin" the #tracing2 branches rather than #tracing to use it. > >>>> > >>>> Note also that it doesn't currently record ring utilisation, > so you'll > >>>> still need to do some work to get that. You could use the > >>>> MProf.Counter interface, in which case the GUI will display > it as a > >>>> graph over the trace. > >>>> > >>>>>>> - try to reduce the parallelisation to see if some > condition there > >>>>>>> alleviates the issue to track it down. > >>>>>> > >>>>>> Reducing the maximum number of threads running in parallel > reduced CPU > >>>>>> utilization, and vm was functioning for a much longer time, > but the > >>>>>> same > >>>>>> problem occurred at the end. > >>>>>> > >>>>>> It might be more useful looking at the code. Please have a > look at the > >>>>>> function "f_thread" in the file uploaded on the following repo: > >>>>>> > >>>>>> https://github.com/koleini/parallelisation > >>>>> > >>>>> That's a lot of code to try and distill down a test case. > Try to cut > >>>>> it > >>>>> down significantly by building a minimal Ethernet traffic > generator > >>>>> that > >>>>> outputs frames with a predictable pattern in the frame, and > a receiver > >>>>> that > >>>>> will check that the pattern is received as expected. > >>>>> > >>>>> Then you can try out your parallel algorithm variations on > the simple > >>>>> Ethernet sender/receiver and narrow down the problem without > all the > >>>>> other > >>>>> concerns. > >>>>> > >>>>> Once the bug is tracked down, we can add the sender/receiver > into > >>>>> mirage-skeleton and use it as a test case to ensure that this > >>>>> functional > >>>>> never regresses in the future. Line rate Ethernet > transmission has > >>>>> worked > >>>>> in the past, but we never added a test case to ensure it > stays working. > >>>>> > >>>>> Anil > >>>>> _______________________________________________ > >>>>> MirageOS-devel mailing list > >>>>> MirageOS-devel@lists.xenproject.org > > >>>>> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> This message and any attachment are intended solely for the > addressee and > >>> may contain confidential information. If you have received > this message > >>> in > >>> error, please send it back to me, and immediately delete it. > Please do > >>> not > >>> use, copy or disclose the information contained in this > message or in any > >>> attachment. Any views or opinions expressed by the author of > this email > >>> do > >>> not necessarily reflect the views of the University of Nottingham. > >>> > >>> This message has been checked for viruses but the contents of an > >>> attachment > >>> may still contain software viruses which could damage your > computer > >>> system, > >>> you are advised to perform your own checks. Email > communications with the > >>> University of Nottingham may be monitored as permitted by UK > legislation. > >>> > >> > >> > > > > > > > > > > > > This message and any attachment are intended solely for the > addressee and > > may contain confidential information. If you have received this > message in > > error, please send it back to me, and immediately delete it. > Please do not > > use, copy or disclose the information contained in this message > or in any > > attachment. Any views or opinions expressed by the author of > this email do > > not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > attachment > > may still contain software viruses which could damage your > computer system, > > you are advised to perform your own checks. Email communications > with the > > University of Nottingham may be monitored as permitted by UK > legislation. > > > > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > -- > Dave Scott This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. --------------090603000705050702050803 Content-Type: text/html; charset=utf-8 Content-Length: 20416 Content-Transfer-Encoding: quoted-printable
On 18/12/14 11:31, David Scott wrote:


On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard <talex5@gmail.com> wrote:
On 18 December 2014 at 11:01, Masoud Koleini
<masoud.koleini@nottingham.ac.uk> wrote:
>
>> On 17 December 2014 at 18:05, Masoud
>> Koleini<masoud.koleini@nottingham.ac.uk> wrote:
>>>
>>> Thanks Thomas for the great tracing tool!
>>>
>>> The following is a very simple unikernel with two interfaces, which
>>> redirects frames captured on the first interface to the second one:
>>>
>>> https://github.com/koleini/parallelisation
>>>
>>> The problem is that in a high packet rate (more than 80'000 pps), switch
>>> stops receiving. The goal is to spot the problem and enhance the
>>> throughput
>>> of Mirage netif.
>>
>> I don't know if this is the problem, but in the code, I see you do:
>>
>>=C2=A0 =C2=A0 listen if1 if2
>>=C2=A0 =C2=A0 >> (forward_thread if2)
>>
>> This ignores the result from listen, so if the listen thread later
>> fails then the error will be discarded. I'd try something like this:
>>
>>=C2=A0 =C2=A0 Lwt.choose [
>>=C2=A0 =C2=A0 =C2=A0 listen if1 if2;
>>=C2=A0 =C2=A0 =C2=A0 forward_thread if2
>>=C2=A0 =C2=A0 ]
>>
>> (and lose the "return" at the end of listen)
>
>
> listen calls netif listen function, which only sets receive_callback on the
> interface (used by poll_thread). It looks that failing poll_thread is not
> monitored in netif code.

Hmm. You're right. Does it show anything if you catch errors there=3F

Looks like it was changed here:

https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c

Perhaps listen could just return the poll thread, rather than making a
fake task. Dave=3F

Ah yes, good idea. If that callback fails then we're going to fail silently.

Dave

I have modified listen to return poll thread. Poll threads are not failing when switch stops working.

=C2=A0

>> I really think the >> operator should be banned...
>>
>>> Test environment consists of another vm running a traffic generator and
>>> sending frames of a specific pattern (UDP frames of size 100 bytes) over
>>> the
>>> bridge that connects to the first interface of the unikernel. Unikernel
>>> forwards frames by collecting a number of frames from input queue and
>>> running the same number of threads that write them to the output
>>> interface.
>>>
>>> Two trace files are uploaded to the repo. The first file is the output of
>>> this configuration. This trace shows that each netif write locks until
>>> the
>>> thread that writes on the front-end connection to the ring is returned
>>> (function write_already_locked.)
>>>
>>> For the second trace, the return of the thread is ignored (commenting out
>>> "lwt () =3D th in" in write_already_locked). This considerably increases
>>> switching speed, but after some running time, it looks that after garbage
>>> collection, similar problem happens.
>>>
>>> Thomas and Anil, any idea from given traces, and how it is possible to
>>> make
>>> the traces more informative=3F
>>>
>>> Thanks.
>>>
>>>
>>> On 28/11/14 16:55, Thomas Leonard wrote:
>>>>
>>>> On 28 November 2014 at 16:24, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>>>>
>>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini
>>>>>> <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>>
>>>>>> Thanks Anil.
>>>>>>
>>>>>>> - graph the ring utilisation to see if it's always full (Thomas
>>>>>>> Leonard's profiling patches should help here)
>>>>>>
>>>>>> Would you please point me out to the profiling patches=3F
>>>>>
>>>>> See:
>>>>>
>>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/
>>>>
>>>> The installation instructions here are for the previous version
>>>> (though they should still work). If you want to try the latest
>>>> version, the current Git mirage allows you to pass a ~tracing argument
>>>> to "register" in your config.ml, e.g.
>>>>
>>>> let tracing =3D mprof_trace ~size:1000000 () in
>>>> register "myunikernel" ~tracing [
>>>>=C2=A0 =C2=A0 =C2=A0main $ ...
>>>> ]
>>>>
>>>> This uses a newer version of the profiling API. You should generally
>>>> "opam pin" the #tracing2 branches rather than #tracing to use it.
>>>>
>>>> Note also that it doesn't currently record ring utilisation, so you'll
>>>> still need to do some work to get that. You could use the
>>>> MProf.Counter interface, in which case the GUI will display it as a
>>>> graph over the trace.
>>>>
>>>>>>> - try to reduce the parallelisation to see if some condition there
>>>>>>> alleviates the issue to track it down.
>>>>>>
>>>>>> Reducing the maximum number of threads running in parallel reduced CPU
>>>>>> utilization, and vm was functioning for a much longer time, but the
>>>>>> same
>>>>>> problem occurred at the end.
>>>>>>
>>>>>> It might be more useful looking at the code. Please have a look at the
>>>>>> function "f_thread" in the file uploaded on the following repo:
>>>>>>
>>>>>> https://github.com/koleini/parallelisation
>>>>>
>>>>> That's a lot of code to try and distill down a test case.=C2=A0 Try to cut
>>>>> it
>>>>> down significantly by building a minimal Ethernet traffic generator
>>>>> that
>>>>> outputs frames with a predictable pattern in the frame, and a receiver
>>>>> that
>>>>> will check that the pattern is received as expected.
>>>>>
>>>>> Then you can try out your parallel algorithm variations on the simple
>>>>> Ethernet sender/receiver and narrow down the problem without all the
>>>>> other
>>>>> concerns.
>>>>>
>>>>> Once the bug is tracked down, we can add the sender/receiver into
>>>>> mirage-skeleton and use it as a test case to ensure that this
>>>>> functional
>>>>> never regresses in the future.=C2=A0 Line rate Ethernet transmission has
>>>>> worked
>>>>> in the past, but we never added a test case to ensure it stays working.
>>>>>
>>>>> Anil
>>>>> _______________________________________________
>>>>> MirageOS-devel mailing list
>>>>> MirageOS-devel@lists.xenproject.org
>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> This message and any attachment are intended solely for the addressee and
>>> may contain confidential information. If you have received this message
>>> in
>>> error, please send it back to me, and immediately delete it.=C2=A0 =C2=A0Please do
>>> not
>>> use, copy or disclose the information contained in this message or in any
>>> attachment.=C2=A0 Any views or opinions expressed by the author of this email
>>> do
>>> not necessarily reflect the views of the University of Nottingham.
>>>
>>> This message has been checked for viruses but the contents of an
>>> attachment
>>> may still contain software viruses which could damage your computer
>>> system,
>>> you are advised to perform your own checks. Email communications with the
>>> University of Nottingham may be monitored as permitted by UK legislation.
>>>
>>
>>
>
>
>
>
>
> This message and any attachment are intended solely for the addressee and
> may contain confidential information. If you have received this message in
> error, please send it back to me, and immediately delete it.=C2=A0 =C2=A0Please do not
> use, copy or disclose the information contained in this message or in any
> attachment.=C2=A0 Any views or opinions expressed by the author of this email do
> not necessarily reflect the views of the University of Nottingham.
>
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system,
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.
>



--
Dr Thomas Leonard=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://0install.net/
GPG: 9242 9807 C985 3C07 44A6=C2=A0 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA=C2=A0 BD8E 0713 3F96 CA74 D8BA
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


--
Dave Scott



This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
--------------090603000705050702050803-- --===============2962862681788400918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2962862681788400918==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 12:41:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 12:41:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1aOC-0003Xp-3k; Thu, 18 Dec 2014 12:41:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1aOA-0003Xh-S3 for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 12:41:07 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id A8/46-26652-26BC2945; Thu, 18 Dec 2014 12:41:06 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-7.tower-206.messagelabs.com!1418906464!14149971!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8366 invoked from network); 18 Dec 2014 12:41:04 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-7.tower-206.messagelabs.com with SMTP; 18 Dec 2014 12:41:04 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E747330C947_492CB5FB; Thu, 18 Dec 2014 12:41:03 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 71316304BFD_492CB5FF; Thu, 18 Dec 2014 12:41:03 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1aO7-0005UC-DL; Thu, 18 Dec 2014 12:41:03 +0000 Message-ID: <5492CB5F.3060103@nottingham.ac.uk> Date: Thu, 18 Dec 2014 12:41:03 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Scott , Thomas Leonard References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> <5492B427.7020008@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2962862681788400918==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============2962862681788400918== Content-Type: multipart/alternative; boundary="------------090603000705050702050803" This is a multi-part message in MIME format. --------------090603000705050702050803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Length: 10770 Content-Transfer-Encoding: quoted-printable On 18/12/14 11:31, David Scott wrote: > > > On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard > wrote: > > On 18 December 2014 at 11:01, Masoud Koleini > > wrote: > > > >> On 17 December 2014 at 18:05, Masoud > >> Koleini > wrote: > >>> > >>> Thanks Thomas for the great tracing tool! > >>> > >>> The following is a very simple unikernel with two interfaces, > which > >>> redirects frames captured on the first interface to the second > one: > >>> > >>> https://github.com/koleini/parallelisation > >>> > >>> The problem is that in a high packet rate (more than 80'000 > pps), switch > >>> stops receiving. The goal is to spot the problem and enhance the > >>> throughput > >>> of Mirage netif. > >> > >> I don't know if this is the problem, but in the code, I see you do: > >> > >> listen if1 if2 > >> >> (forward_thread if2) > >> > >> This ignores the result from listen, so if the listen thread later > >> fails then the error will be discarded. I'd try something like > this: > >> > >> Lwt.choose [ > >> listen if1 if2; > >> forward_thread if2 > >> ] > >> > >> (and lose the "return" at the end of listen) > > > > > > listen calls netif listen function, which only sets > receive_callback on the > > interface (used by poll_thread). It looks that failing > poll_thread is not > > monitored in netif code. > > Hmm. You're right. Does it show anything if you catch errors there=3F > > Looks like it was changed here: > > https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c > > Perhaps listen could just return the poll thread, rather than making a > fake task. Dave=3F > > > Ah yes, good idea. If that callback fails then we're going to fail > silently. > > Dave I have modified listen to return poll thread. Poll threads are not failing when switch stops working. > > >> I really think the >> operator should be banned... > >> > >>> Test environment consists of another vm running a traffic > generator and > >>> sending frames of a specific pattern (UDP frames of size 100 > bytes) over > >>> the > >>> bridge that connects to the first interface of the unikernel. > Unikernel > >>> forwards frames by collecting a number of frames from input > queue and > >>> running the same number of threads that write them to the output > >>> interface. > >>> > >>> Two trace files are uploaded to the repo. The first file is > the output of > >>> this configuration. This trace shows that each netif write > locks until > >>> the > >>> thread that writes on the front-end connection to the ring is > returned > >>> (function write_already_locked.) > >>> > >>> For the second trace, the return of the thread is ignored > (commenting out > >>> "lwt () =3D th in" in write_already_locked). This considerably > increases > >>> switching speed, but after some running time, it looks that > after garbage > >>> collection, similar problem happens. > >>> > >>> Thomas and Anil, any idea from given traces, and how it is > possible to > >>> make > >>> the traces more informative=3F > >>> > >>> Thanks. > >>> > >>> > >>> On 28/11/14 16:55, Thomas Leonard wrote: > >>>> > >>>> On 28 November 2014 at 16:24, Anil Madhavapeddy > > wrote: > >>>>>> > >>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini > >>>>>> > wrote: > >>>>>> > >>>>>> Thanks Anil. > >>>>>> > >>>>>>> - graph the ring utilisation to see if it's always full > (Thomas > >>>>>>> Leonard's profiling patches should help here) > >>>>>> > >>>>>> Would you please point me out to the profiling patches=3F > >>>>> > >>>>> See: > >>>>> > >>>>> > http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ > >>>> > >>>> The installation instructions here are for the previous version > >>>> (though they should still work). If you want to try the latest > >>>> version, the current Git mirage allows you to pass a ~tracing > argument > >>>> to "register" in your config.ml , e.g. > >>>> > >>>> let tracing =3D mprof_trace ~size:1000000 () in > >>>> register "myunikernel" ~tracing [ > >>>> main $ ... > >>>> ] > >>>> > >>>> This uses a newer version of the profiling API. You should > generally > >>>> "opam pin" the #tracing2 branches rather than #tracing to use it. > >>>> > >>>> Note also that it doesn't currently record ring utilisation, > so you'll > >>>> still need to do some work to get that. You could use the > >>>> MProf.Counter interface, in which case the GUI will display > it as a > >>>> graph over the trace. > >>>> > >>>>>>> - try to reduce the parallelisation to see if some > condition there > >>>>>>> alleviates the issue to track it down. > >>>>>> > >>>>>> Reducing the maximum number of threads running in parallel > reduced CPU > >>>>>> utilization, and vm was functioning for a much longer time, > but the > >>>>>> same > >>>>>> problem occurred at the end. > >>>>>> > >>>>>> It might be more useful looking at the code. Please have a > look at the > >>>>>> function "f_thread" in the file uploaded on the following repo: > >>>>>> > >>>>>> https://github.com/koleini/parallelisation > >>>>> > >>>>> That's a lot of code to try and distill down a test case. > Try to cut > >>>>> it > >>>>> down significantly by building a minimal Ethernet traffic > generator > >>>>> that > >>>>> outputs frames with a predictable pattern in the frame, and > a receiver > >>>>> that > >>>>> will check that the pattern is received as expected. > >>>>> > >>>>> Then you can try out your parallel algorithm variations on > the simple > >>>>> Ethernet sender/receiver and narrow down the problem without > all the > >>>>> other > >>>>> concerns. > >>>>> > >>>>> Once the bug is tracked down, we can add the sender/receiver > into > >>>>> mirage-skeleton and use it as a test case to ensure that this > >>>>> functional > >>>>> never regresses in the future. Line rate Ethernet > transmission has > >>>>> worked > >>>>> in the past, but we never added a test case to ensure it > stays working. > >>>>> > >>>>> Anil > >>>>> _______________________________________________ > >>>>> MirageOS-devel mailing list > >>>>> MirageOS-devel@lists.xenproject.org > > >>>>> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> This message and any attachment are intended solely for the > addressee and > >>> may contain confidential information. If you have received > this message > >>> in > >>> error, please send it back to me, and immediately delete it. > Please do > >>> not > >>> use, copy or disclose the information contained in this > message or in any > >>> attachment. Any views or opinions expressed by the author of > this email > >>> do > >>> not necessarily reflect the views of the University of Nottingham. > >>> > >>> This message has been checked for viruses but the contents of an > >>> attachment > >>> may still contain software viruses which could damage your > computer > >>> system, > >>> you are advised to perform your own checks. Email > communications with the > >>> University of Nottingham may be monitored as permitted by UK > legislation. > >>> > >> > >> > > > > > > > > > > > > This message and any attachment are intended solely for the > addressee and > > may contain confidential information. If you have received this > message in > > error, please send it back to me, and immediately delete it. > Please do not > > use, copy or disclose the information contained in this message > or in any > > attachment. Any views or opinions expressed by the author of > this email do > > not necessarily reflect the views of the University of Nottingham. > > > > This message has been checked for viruses but the contents of an > attachment > > may still contain software viruses which could damage your > computer system, > > you are advised to perform your own checks. Email communications > with the > > University of Nottingham may be monitored as permitted by UK > legislation. > > > > > > -- > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > -- > Dave Scott This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. --------------090603000705050702050803 Content-Type: text/html; charset=utf-8 Content-Length: 20416 Content-Transfer-Encoding: quoted-printable
On 18/12/14 11:31, David Scott wrote:


On Thu, Dec 18, 2014 at 11:13 AM, Thomas Leonard <talex5@gmail.com> wrote:
On 18 December 2014 at 11:01, Masoud Koleini
<masoud.koleini@nottingham.ac.uk> wrote:
>
>> On 17 December 2014 at 18:05, Masoud
>> Koleini<masoud.koleini@nottingham.ac.uk> wrote:
>>>
>>> Thanks Thomas for the great tracing tool!
>>>
>>> The following is a very simple unikernel with two interfaces, which
>>> redirects frames captured on the first interface to the second one:
>>>
>>> https://github.com/koleini/parallelisation
>>>
>>> The problem is that in a high packet rate (more than 80'000 pps), switch
>>> stops receiving. The goal is to spot the problem and enhance the
>>> throughput
>>> of Mirage netif.
>>
>> I don't know if this is the problem, but in the code, I see you do:
>>
>>=C2=A0 =C2=A0 listen if1 if2
>>=C2=A0 =C2=A0 >> (forward_thread if2)
>>
>> This ignores the result from listen, so if the listen thread later
>> fails then the error will be discarded. I'd try something like this:
>>
>>=C2=A0 =C2=A0 Lwt.choose [
>>=C2=A0 =C2=A0 =C2=A0 listen if1 if2;
>>=C2=A0 =C2=A0 =C2=A0 forward_thread if2
>>=C2=A0 =C2=A0 ]
>>
>> (and lose the "return" at the end of listen)
>
>
> listen calls netif listen function, which only sets receive_callback on the
> interface (used by poll_thread). It looks that failing poll_thread is not
> monitored in netif code.

Hmm. You're right. Does it show anything if you catch errors there=3F

Looks like it was changed here:

https://github.com/mirage/mirage-net-xen/commit/5d9df74fb0d8a3eecda8beac9e694f939392273c

Perhaps listen could just return the poll thread, rather than making a
fake task. Dave=3F

Ah yes, good idea. If that callback fails then we're going to fail silently.

Dave

I have modified listen to return poll thread. Poll threads are not failing when switch stops working.

=C2=A0

>> I really think the >> operator should be banned...
>>
>>> Test environment consists of another vm running a traffic generator and
>>> sending frames of a specific pattern (UDP frames of size 100 bytes) over
>>> the
>>> bridge that connects to the first interface of the unikernel. Unikernel
>>> forwards frames by collecting a number of frames from input queue and
>>> running the same number of threads that write them to the output
>>> interface.
>>>
>>> Two trace files are uploaded to the repo. The first file is the output of
>>> this configuration. This trace shows that each netif write locks until
>>> the
>>> thread that writes on the front-end connection to the ring is returned
>>> (function write_already_locked.)
>>>
>>> For the second trace, the return of the thread is ignored (commenting out
>>> "lwt () =3D th in" in write_already_locked). This considerably increases
>>> switching speed, but after some running time, it looks that after garbage
>>> collection, similar problem happens.
>>>
>>> Thomas and Anil, any idea from given traces, and how it is possible to
>>> make
>>> the traces more informative=3F
>>>
>>> Thanks.
>>>
>>>
>>> On 28/11/14 16:55, Thomas Leonard wrote:
>>>>
>>>> On 28 November 2014 at 16:24, Anil Madhavapeddy <anil@recoil.org> wrote:
>>>>>>
>>>>>> On 28 Nov 2014, at 16:03, Masoud Koleini
>>>>>> <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>>
>>>>>> Thanks Anil.
>>>>>>
>>>>>>> - graph the ring utilisation to see if it's always full (Thomas
>>>>>>> Leonard's profiling patches should help here)
>>>>>>
>>>>>> Would you please point me out to the profiling patches=3F
>>>>>
>>>>> See:
>>>>>
>>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/
>>>>
>>>> The installation instructions here are for the previous version
>>>> (though they should still work). If you want to try the latest
>>>> version, the current Git mirage allows you to pass a ~tracing argument
>>>> to "register" in your config.ml, e.g.
>>>>
>>>> let tracing =3D mprof_trace ~size:1000000 () in
>>>> register "myunikernel" ~tracing [
>>>>=C2=A0 =C2=A0 =C2=A0main $ ...
>>>> ]
>>>>
>>>> This uses a newer version of the profiling API. You should generally
>>>> "opam pin" the #tracing2 branches rather than #tracing to use it.
>>>>
>>>> Note also that it doesn't currently record ring utilisation, so you'll
>>>> still need to do some work to get that. You could use the
>>>> MProf.Counter interface, in which case the GUI will display it as a
>>>> graph over the trace.
>>>>
>>>>>>> - try to reduce the parallelisation to see if some condition there
>>>>>>> alleviates the issue to track it down.
>>>>>>
>>>>>> Reducing the maximum number of threads running in parallel reduced CPU
>>>>>> utilization, and vm was functioning for a much longer time, but the
>>>>>> same
>>>>>> problem occurred at the end.
>>>>>>
>>>>>> It might be more useful looking at the code. Please have a look at the
>>>>>> function "f_thread" in the file uploaded on the following repo:
>>>>>>
>>>>>> https://github.com/koleini/parallelisation
>>>>>
>>>>> That's a lot of code to try and distill down a test case.=C2=A0 Try to cut
>>>>> it
>>>>> down significantly by building a minimal Ethernet traffic generator
>>>>> that
>>>>> outputs frames with a predictable pattern in the frame, and a receiver
>>>>> that
>>>>> will check that the pattern is received as expected.
>>>>>
>>>>> Then you can try out your parallel algorithm variations on the simple
>>>>> Ethernet sender/receiver and narrow down the problem without all the
>>>>> other
>>>>> concerns.
>>>>>
>>>>> Once the bug is tracked down, we can add the sender/receiver into
>>>>> mirage-skeleton and use it as a test case to ensure that this
>>>>> functional
>>>>> never regresses in the future.=C2=A0 Line rate Ethernet transmission has
>>>>> worked
>>>>> in the past, but we never added a test case to ensure it stays working.
>>>>>
>>>>> Anil
>>>>> _______________________________________________
>>>>> MirageOS-devel mailing list
>>>>> MirageOS-devel@lists.xenproject.org
>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> This message and any attachment are intended solely for the addressee and
>>> may contain confidential information. If you have received this message
>>> in
>>> error, please send it back to me, and immediately delete it.=C2=A0 =C2=A0Please do
>>> not
>>> use, copy or disclose the information contained in this message or in any
>>> attachment.=C2=A0 Any views or opinions expressed by the author of this email
>>> do
>>> not necessarily reflect the views of the University of Nottingham.
>>>
>>> This message has been checked for viruses but the contents of an
>>> attachment
>>> may still contain software viruses which could damage your computer
>>> system,
>>> you are advised to perform your own checks. Email communications with the
>>> University of Nottingham may be monitored as permitted by UK legislation.
>>>
>>
>>
>
>
>
>
>
> This message and any attachment are intended solely for the addressee and
> may contain confidential information. If you have received this message in
> error, please send it back to me, and immediately delete it.=C2=A0 =C2=A0Please do not
> use, copy or disclose the information contained in this message or in any
> attachment.=C2=A0 Any views or opinions expressed by the author of this email do
> not necessarily reflect the views of the University of Nottingham.
>
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system,
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.
>



--
Dr Thomas Leonard=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://0install.net/
GPG: 9242 9807 C985 3C07 44A6=C2=A0 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA=C2=A0 BD8E 0713 3F96 CA74 D8BA
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


--
Dave Scott



This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
--------------090603000705050702050803-- --===============2962862681788400918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2962862681788400918==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 13:20:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 13:20:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1azr-0006Ao-G7; Thu, 18 Dec 2014 13:20:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1azq-0006Ab-9U for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:20:02 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id E3/A2-25547-184D2945; Thu, 18 Dec 2014 13:20:01 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1418908800!14378408!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29047 invoked from network); 18 Dec 2014 13:20:00 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 13:20:00 -0000 Received: by mail-la0-f43.google.com with SMTP id s18so985272lam.16 for ; Thu, 18 Dec 2014 05:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QDJh0osJWpxnN6XRUK4Rrk6HvlLNMMpKYzm5Ie5r5so=; b=pvneTyDySYJRfF80ssZMafsC0F0m3EgB9Y9NxyF6iOjoncqgiiv/znS150kwt1j2zD ibewu8rcvvOgYKUrv6ZiE9BVdzheWFp3tXGEc+A0Jup1ELGPDE9wbQq/jQvGVIAYtQ8b uKC2jVnZtyK8r3h9DKKfzNpogcRlB+EnPKmTIsiilfBVHIm2SasluXmMRKplWh4RSg5q uyeLX8Dco6GucVL8pivyT5guESQsyLdj/+e4YiSXVKIUiCxTY8Eh0WenkbxLbQSMCPO0 3aT0Jbn00NnmLUApAA95biOst3On6Kpt/qnBkvf7qEtTHucpxRfP/qQTBuGtA+4PNFu/ p4Jw== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr2229832lbb.1.1418908799780; Thu, 18 Dec 2014 05:19:59 -0800 (PST) Received: by 10.25.207.3 with HTTP; Thu, 18 Dec 2014 05:19:59 -0800 (PST) In-Reply-To: <5491C606.500@nottingham.ac.uk> References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> Date: Thu, 18 Dec 2014 13:19:59 +0000 Message-ID: From: Thomas Leonard To: Masoud Koleini Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 18:05, Masoud Koleini wrote: > Thanks Thomas for the great tracing tool! > > The following is a very simple unikernel with two interfaces, which > redirects frames captured on the first interface to the second one: > > https://github.com/koleini/parallelisation > > The problem is that in a high packet rate (more than 80'000 pps), switch > stops receiving. The goal is to spot the problem and enhance the throughput > of Mirage netif. > > Test environment consists of another vm running a traffic generator and > sending frames of a specific pattern (UDP frames of size 100 bytes) over the > bridge that connects to the first interface of the unikernel. Unikernel > forwards frames by collecting a number of frames from input queue and > running the same number of threads that write them to the output interface. > > Two trace files are uploaded to the repo. The first file is the output of > this configuration. This trace shows that each netif write locks until the > thread that writes on the front-end connection to the ring is returned > (function write_already_locked.) Do these traces show it after it stopped? The second has a long sleep, while the first looks like it was in the middle of a run. If it had stopped in both cases, it suggests that the whole unikernel stopped (not just the listen thread), because there are no more timer interrupts and no sleep region. Does "xl top" show the unikernel still using the CPU? Or it is waiting, or crashed? If you have a thread writing a string to the console once per second, does it continue after unikernel stops accepting frames? > For the second trace, the return of the thread is ignored (commenting out > "lwt () = th in" in write_already_locked). This considerably increases > switching speed, but after some running time, it looks that after garbage > collection, similar problem happens. > > Thomas and Anil, any idea from given traces, and how it is possible to make > the traces more informative? > > Thanks. > > > On 28/11/14 16:55, Thomas Leonard wrote: >> >> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>> >>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>> wrote: >>>> >>>> Thanks Anil. >>>> >>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>> Leonard's profiling patches should help here) >>>> >>>> Would you please point me out to the profiling patches? >>> >>> See: >>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >> >> The installation instructions here are for the previous version >> (though they should still work). If you want to try the latest >> version, the current Git mirage allows you to pass a ~tracing argument >> to "register" in your config.ml, e.g. >> >> let tracing = mprof_trace ~size:1000000 () in >> register "myunikernel" ~tracing [ >> main $ ... >> ] >> >> This uses a newer version of the profiling API. You should generally >> "opam pin" the #tracing2 branches rather than #tracing to use it. >> >> Note also that it doesn't currently record ring utilisation, so you'll >> still need to do some work to get that. You could use the >> MProf.Counter interface, in which case the GUI will display it as a >> graph over the trace. >> >>>>> - try to reduce the parallelisation to see if some condition there >>>>> alleviates the issue to track it down. >>>> >>>> Reducing the maximum number of threads running in parallel reduced CPU >>>> utilization, and vm was functioning for a much longer time, but the same >>>> problem occurred at the end. >>>> >>>> It might be more useful looking at the code. Please have a look at the >>>> function "f_thread" in the file uploaded on the following repo: >>>> >>>> https://github.com/koleini/parallelisation >>> >>> That's a lot of code to try and distill down a test case. Try to cut it >>> down significantly by building a minimal Ethernet traffic generator that >>> outputs frames with a predictable pattern in the frame, and a receiver that >>> will check that the pattern is received as expected. >>> >>> Then you can try out your parallel algorithm variations on the simple >>> Ethernet sender/receiver and narrow down the problem without all the other >>> concerns. >>> >>> Once the bug is tracked down, we can add the sender/receiver into >>> mirage-skeleton and use it as a test case to ensure that this functional >>> never regresses in the future. Line rate Ethernet transmission has worked >>> in the past, but we never added a test case to ensure it stays working. >>> >>> Anil >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> > > > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 13:20:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 13:20:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1azr-0006Ao-G7; Thu, 18 Dec 2014 13:20:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1azq-0006Ab-9U for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:20:02 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id E3/A2-25547-184D2945; Thu, 18 Dec 2014 13:20:01 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1418908800!14378408!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29047 invoked from network); 18 Dec 2014 13:20:00 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 13:20:00 -0000 Received: by mail-la0-f43.google.com with SMTP id s18so985272lam.16 for ; Thu, 18 Dec 2014 05:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QDJh0osJWpxnN6XRUK4Rrk6HvlLNMMpKYzm5Ie5r5so=; b=pvneTyDySYJRfF80ssZMafsC0F0m3EgB9Y9NxyF6iOjoncqgiiv/znS150kwt1j2zD ibewu8rcvvOgYKUrv6ZiE9BVdzheWFp3tXGEc+A0Jup1ELGPDE9wbQq/jQvGVIAYtQ8b uKC2jVnZtyK8r3h9DKKfzNpogcRlB+EnPKmTIsiilfBVHIm2SasluXmMRKplWh4RSg5q uyeLX8Dco6GucVL8pivyT5guESQsyLdj/+e4YiSXVKIUiCxTY8Eh0WenkbxLbQSMCPO0 3aT0Jbn00NnmLUApAA95biOst3On6Kpt/qnBkvf7qEtTHucpxRfP/qQTBuGtA+4PNFu/ p4Jw== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr2229832lbb.1.1418908799780; Thu, 18 Dec 2014 05:19:59 -0800 (PST) Received: by 10.25.207.3 with HTTP; Thu, 18 Dec 2014 05:19:59 -0800 (PST) In-Reply-To: <5491C606.500@nottingham.ac.uk> References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> Date: Thu, 18 Dec 2014 13:19:59 +0000 Message-ID: From: Thomas Leonard To: Masoud Koleini Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 18:05, Masoud Koleini wrote: > Thanks Thomas for the great tracing tool! > > The following is a very simple unikernel with two interfaces, which > redirects frames captured on the first interface to the second one: > > https://github.com/koleini/parallelisation > > The problem is that in a high packet rate (more than 80'000 pps), switch > stops receiving. The goal is to spot the problem and enhance the throughput > of Mirage netif. > > Test environment consists of another vm running a traffic generator and > sending frames of a specific pattern (UDP frames of size 100 bytes) over the > bridge that connects to the first interface of the unikernel. Unikernel > forwards frames by collecting a number of frames from input queue and > running the same number of threads that write them to the output interface. > > Two trace files are uploaded to the repo. The first file is the output of > this configuration. This trace shows that each netif write locks until the > thread that writes on the front-end connection to the ring is returned > (function write_already_locked.) Do these traces show it after it stopped? The second has a long sleep, while the first looks like it was in the middle of a run. If it had stopped in both cases, it suggests that the whole unikernel stopped (not just the listen thread), because there are no more timer interrupts and no sleep region. Does "xl top" show the unikernel still using the CPU? Or it is waiting, or crashed? If you have a thread writing a string to the console once per second, does it continue after unikernel stops accepting frames? > For the second trace, the return of the thread is ignored (commenting out > "lwt () = th in" in write_already_locked). This considerably increases > switching speed, but after some running time, it looks that after garbage > collection, similar problem happens. > > Thomas and Anil, any idea from given traces, and how it is possible to make > the traces more informative? > > Thanks. > > > On 28/11/14 16:55, Thomas Leonard wrote: >> >> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>> >>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>> wrote: >>>> >>>> Thanks Anil. >>>> >>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>> Leonard's profiling patches should help here) >>>> >>>> Would you please point me out to the profiling patches? >>> >>> See: >>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >> >> The installation instructions here are for the previous version >> (though they should still work). If you want to try the latest >> version, the current Git mirage allows you to pass a ~tracing argument >> to "register" in your config.ml, e.g. >> >> let tracing = mprof_trace ~size:1000000 () in >> register "myunikernel" ~tracing [ >> main $ ... >> ] >> >> This uses a newer version of the profiling API. You should generally >> "opam pin" the #tracing2 branches rather than #tracing to use it. >> >> Note also that it doesn't currently record ring utilisation, so you'll >> still need to do some work to get that. You could use the >> MProf.Counter interface, in which case the GUI will display it as a >> graph over the trace. >> >>>>> - try to reduce the parallelisation to see if some condition there >>>>> alleviates the issue to track it down. >>>> >>>> Reducing the maximum number of threads running in parallel reduced CPU >>>> utilization, and vm was functioning for a much longer time, but the same >>>> problem occurred at the end. >>>> >>>> It might be more useful looking at the code. Please have a look at the >>>> function "f_thread" in the file uploaded on the following repo: >>>> >>>> https://github.com/koleini/parallelisation >>> >>> That's a lot of code to try and distill down a test case. Try to cut it >>> down significantly by building a minimal Ethernet traffic generator that >>> outputs frames with a predictable pattern in the frame, and a receiver that >>> will check that the pattern is received as expected. >>> >>> Then you can try out your parallel algorithm variations on the simple >>> Ethernet sender/receiver and narrow down the problem without all the other >>> concerns. >>> >>> Once the bug is tracked down, we can add the sender/receiver into >>> mirage-skeleton and use it as a test case to ensure that this functional >>> never regresses in the future. Line rate Ethernet transmission has worked >>> in the past, but we never added a test case to ensure it stays working. >>> >>> Anil >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> > > > > > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do not > use, copy or disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of this email do > not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, > you are advised to perform your own checks. Email communications with the > University of Nottingham may be monitored as permitted by UK legislation. > -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 13:41:53 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 13:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bKw-0007fG-L8; Thu, 18 Dec 2014 13:41:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bKv-0007d2-D6 for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:41:49 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id B2/03-22819-C99D2945; Thu, 18 Dec 2014 13:41:48 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-206.messagelabs.com!1418910106!6539280!1 X-Originating-IP: [128.243.43.110] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19400 invoked from network); 18 Dec 2014 13:41:46 -0000 Received: from uidappmx02.nottingham.ac.uk (HELO uidappmx02.nottingham.ac.uk) (128.243.43.110) by server-3.tower-206.messagelabs.com with SMTP; 18 Dec 2014 13:41:46 -0000 Received: from uidappmx02.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F1C522EAA0A_492D999B for ; Thu, 18 Dec 2014 13:41:45 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx02.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id D281A2F0215_492D999F for ; Thu, 18 Dec 2014 13:41:45 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1bKr-000835-Qc; Thu, 18 Dec 2014 13:41:45 +0000 Message-ID: <5492D996.4020605@nottingham.ac.uk> Date: Thu, 18 Dec 2014 13:41:42 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Anil Madhavapeddy References: <5490BEED.5050509@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Is it possible to deallocate an Io_page after packet is send, not to wait for GC? On 16/12/14 23:45, Anil Madhavapeddy wrote: > On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >> I am wondering if the following issue is already addressed: >> >> https://github.com/mirage/mirage-tcpip/issues/33 >> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> > It probably still happens at 64MB of RAM -- it requires some code to adjust > the GC parameters in the OCaml runtime to trigger a collection more often. > It should be harmless however, since (as the bug report observes), a failure > to allocate an Io_page results in a GC compaction that frees up memory so > that the allocation eventually succeeds. > > Any particular reason for asking -- is the bug affecting your switch somehow? > > -anil This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 13:41:53 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 13:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bKw-0007fG-L8; Thu, 18 Dec 2014 13:41:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bKv-0007d2-D6 for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:41:49 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id B2/03-22819-C99D2945; Thu, 18 Dec 2014 13:41:48 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-3.tower-206.messagelabs.com!1418910106!6539280!1 X-Originating-IP: [128.243.43.110] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19400 invoked from network); 18 Dec 2014 13:41:46 -0000 Received: from uidappmx02.nottingham.ac.uk (HELO uidappmx02.nottingham.ac.uk) (128.243.43.110) by server-3.tower-206.messagelabs.com with SMTP; 18 Dec 2014 13:41:46 -0000 Received: from uidappmx02.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F1C522EAA0A_492D999B for ; Thu, 18 Dec 2014 13:41:45 +0000 (GMT) Received: from smtp4.nottingham.ac.uk (smtp4.nottingham.ac.uk [128.243.220.65]) by uidappmx02.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id D281A2F0215_492D999F for ; Thu, 18 Dec 2014 13:41:45 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp4.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1bKr-000835-Qc; Thu, 18 Dec 2014 13:41:45 +0000 Message-ID: <5492D996.4020605@nottingham.ac.uk> Date: Thu, 18 Dec 2014 13:41:42 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Anil Madhavapeddy References: <5490BEED.5050509@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Is it possible to deallocate an Io_page after packet is send, not to wait for GC? On 16/12/14 23:45, Anil Madhavapeddy wrote: > On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >> I am wondering if the following issue is already addressed: >> >> https://github.com/mirage/mirage-tcpip/issues/33 >> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> > It probably still happens at 64MB of RAM -- it requires some code to adjust > the GC parameters in the OCaml runtime to trigger a collection more often. > It should be harmless however, since (as the bug report observes), a failure > to allocate an Io_page results in a GC compaction that frees up memory so > that the allocation eventually succeeds. > > Any particular reason for asking -- is the bug affecting your switch somehow? > > -anil This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 13:46:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 13:46:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bPc-0008Au-Er; Thu, 18 Dec 2014 13:46:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bPb-0008Ao-8x for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:46:39 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 0C/61-17958-EBAD2945; Thu, 18 Dec 2014 13:46:38 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-31.messagelabs.com!1418910397!14373169!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24911 invoked from network); 18 Dec 2014 13:46:37 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Dec 2014 13:46:37 -0000 Received: from [192.168.1.25] (rh-la-34-156.rhythm.com [24.130.34.156]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id a0f6e591; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 18 Dec 2014 13:52:35 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5492D996.4020605@nottingham.ac.uk> Date: Thu, 18 Dec 2014 05:46:39 -0800 Message-Id: <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Not at the moment, although we could easily add an explicit deallocator into Io_page. You need to very careful that the page is not used after its lifetime, so more pool-based abstractions are preferred (where the pages are recycled into an OCaml-managed data structure and reused rather than GCed). You should be able to pump up the amount of RAM the VM gets temporarily to 4GB or so -- if the page allocator still remains low, then it's unlikely to be a GC issue and an actual leak somewhere due to holding onto references and keeping the page live. -anil > On 18 Dec 2014, at 05:41, Masoud Koleini wrote: > > Is it possible to deallocate an Io_page after packet is send, not to wait for GC? > > On 16/12/14 23:45, Anil Madhavapeddy wrote: >> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>> I am wondering if the following issue is already addressed: >>> >>> https://github.com/mirage/mirage-tcpip/issues/33 >>> >>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>> >> It probably still happens at 64MB of RAM -- it requires some code to adjust >> the GC parameters in the OCaml runtime to trigger a collection more often. >> It should be harmless however, since (as the bug report observes), a failure >> to allocate an Io_page results in a GC compaction that frees up memory so >> that the allocation eventually succeeds. >> >> Any particular reason for asking -- is the bug affecting your switch somehow? >> >> -anil > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 13:46:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 13:46:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bPc-0008Au-Er; Thu, 18 Dec 2014 13:46:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1bPb-0008Ao-8x for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 13:46:39 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 0C/61-17958-EBAD2945; Thu, 18 Dec 2014 13:46:38 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-11.tower-31.messagelabs.com!1418910397!14373169!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24911 invoked from network); 18 Dec 2014 13:46:37 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Dec 2014 13:46:37 -0000 Received: from [192.168.1.25] (rh-la-34-156.rhythm.com [24.130.34.156]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id a0f6e591; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 18 Dec 2014 13:52:35 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5492D996.4020605@nottingham.ac.uk> Date: Thu, 18 Dec 2014 05:46:39 -0800 Message-Id: <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Not at the moment, although we could easily add an explicit deallocator into Io_page. You need to very careful that the page is not used after its lifetime, so more pool-based abstractions are preferred (where the pages are recycled into an OCaml-managed data structure and reused rather than GCed). You should be able to pump up the amount of RAM the VM gets temporarily to 4GB or so -- if the page allocator still remains low, then it's unlikely to be a GC issue and an actual leak somewhere due to holding onto references and keeping the page live. -anil > On 18 Dec 2014, at 05:41, Masoud Koleini wrote: > > Is it possible to deallocate an Io_page after packet is send, not to wait for GC? > > On 16/12/14 23:45, Anil Madhavapeddy wrote: >> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>> I am wondering if the following issue is already addressed: >>> >>> https://github.com/mirage/mirage-tcpip/issues/33 >>> >>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>> >> It probably still happens at 64MB of RAM -- it requires some code to adjust >> the GC parameters in the OCaml runtime to trigger a collection more often. >> It should be harmless however, since (as the bug report observes), a failure >> to allocate an Io_page results in a GC compaction that frees up memory so >> that the allocation eventually succeeds. >> >> Any particular reason for asking -- is the bug affecting your switch somehow? >> >> -anil > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 15:17:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 15:17:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1cps-0005YB-S8; Thu, 18 Dec 2014 15:17:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1cpq-0005Y6-TP for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:17:51 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 28/AF-09284-E10F2945; Thu, 18 Dec 2014 15:17:50 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-9.tower-31.messagelabs.com!1418915868!10667928!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24261 invoked from network); 18 Dec 2014 15:17:49 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-9.tower-31.messagelabs.com with SMTP; 18 Dec 2014 15:17:49 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9ED2530C973_492F01BB for ; Thu, 18 Dec 2014 15:17:47 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 11C883060DE_492F01BF for ; Thu, 18 Dec 2014 15:17:47 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1cpm-000336-UW; Thu, 18 Dec 2014 15:17:46 +0000 Message-ID: <5492F016.80601@nottingham.ac.uk> Date: Thu, 18 Dec 2014 15:17:42 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 18/12/14 13:19, Thomas Leonard wrote: > On 17 December 2014 at 18:05, Masoud Koleini > wrote: >> Thanks Thomas for the great tracing tool! >> >> The following is a very simple unikernel with two interfaces, which >> redirects frames captured on the first interface to the second one: >> >> https://github.com/koleini/parallelisation >> >> The problem is that in a high packet rate (more than 80'000 pps), switch >> stops receiving. The goal is to spot the problem and enhance the throughput >> of Mirage netif. >> >> Test environment consists of another vm running a traffic generator and >> sending frames of a specific pattern (UDP frames of size 100 bytes) over the >> bridge that connects to the first interface of the unikernel. Unikernel >> forwards frames by collecting a number of frames from input queue and >> running the same number of threads that write them to the output interface. >> >> Two trace files are uploaded to the repo. The first file is the output of >> this configuration. This trace shows that each netif write locks until the >> thread that writes on the front-end connection to the ring is returned >> (function write_already_locked.) > Do these traces show it after it stopped? The second has a long sleep, > while the first looks like it was in the middle of a run. > > If it had stopped in both cases, it suggests that the whole unikernel > stopped (not just the listen thread), because there are no more timer > interrupts and no sleep region. > > Does "xl top" show the unikernel still using the CPU? Or it is > waiting, or crashed? > > If you have a thread writing a string to the console once per second, > does it continue after unikernel stops accepting frames? Yes, both are. It looks that I have more info on the traces with updated Mirage libraries. So, I updated the traces in the repo. The unikernel is still working, as traces that periodically write info on the console are still working too. With original configuration (netif unchanged), it looks that the reason is unikernel gets out of memory after some time, while error message is shown only in a few experiments. This is the main bottleneck for Mirage applications, which is waiting for a packet write to terminate is time consuming and doesn't allow high rate packet switching for network applications. Modifying netif by ignoring the thread that is waiting for the result of writing to the ring is also problematic. So, any idea how to do bulk packet write on a network interface? > >> For the second trace, the return of the thread is ignored (commenting out >> "lwt () = th in" in write_already_locked). This considerably increases >> switching speed, but after some running time, it looks that after garbage >> collection, similar problem happens. >> >> Thomas and Anil, any idea from given traces, and how it is possible to make >> the traces more informative? >> >> Thanks. >> >> >> On 28/11/14 16:55, Thomas Leonard wrote: >>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>> wrote: >>>>> >>>>> Thanks Anil. >>>>> >>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>> Leonard's profiling patches should help here) >>>>> Would you please point me out to the profiling patches? >>>> See: >>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>> The installation instructions here are for the previous version >>> (though they should still work). If you want to try the latest >>> version, the current Git mirage allows you to pass a ~tracing argument >>> to "register" in your config.ml, e.g. >>> >>> let tracing = mprof_trace ~size:1000000 () in >>> register "myunikernel" ~tracing [ >>> main $ ... >>> ] >>> >>> This uses a newer version of the profiling API. You should generally >>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>> >>> Note also that it doesn't currently record ring utilisation, so you'll >>> still need to do some work to get that. You could use the >>> MProf.Counter interface, in which case the GUI will display it as a >>> graph over the trace. >>> >>>>>> - try to reduce the parallelisation to see if some condition there >>>>>> alleviates the issue to track it down. >>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>> utilization, and vm was functioning for a much longer time, but the same >>>>> problem occurred at the end. >>>>> >>>>> It might be more useful looking at the code. Please have a look at the >>>>> function "f_thread" in the file uploaded on the following repo: >>>>> >>>>> https://github.com/koleini/parallelisation >>>> That's a lot of code to try and distill down a test case. Try to cut it >>>> down significantly by building a minimal Ethernet traffic generator that >>>> outputs frames with a predictable pattern in the frame, and a receiver that >>>> will check that the pattern is received as expected. >>>> >>>> Then you can try out your parallel algorithm variations on the simple >>>> Ethernet sender/receiver and narrow down the problem without all the other >>>> concerns. >>>> >>>> Once the bug is tracked down, we can add the sender/receiver into >>>> mirage-skeleton and use it as a test case to ensure that this functional >>>> never regresses in the future. Line rate Ethernet transmission has worked >>>> in the past, but we never added a test case to ensure it stays working. >>>> >>>> Anil >>>> _______________________________________________ >>>> MirageOS-devel mailing list >>>> MirageOS-devel@lists.xenproject.org >>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >>> >> >> >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please send it back to me, and immediately delete it. Please do not >> use, copy or disclose the information contained in this message or in any >> attachment. Any views or opinions expressed by the author of this email do >> not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment >> may still contain software viruses which could damage your computer system, >> you are advised to perform your own checks. Email communications with the >> University of Nottingham may be monitored as permitted by UK legislation. >> > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 15:17:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 15:17:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1cps-0005YB-S8; Thu, 18 Dec 2014 15:17:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1cpq-0005Y6-TP for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:17:51 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 28/AF-09284-E10F2945; Thu, 18 Dec 2014 15:17:50 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-9.tower-31.messagelabs.com!1418915868!10667928!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24261 invoked from network); 18 Dec 2014 15:17:49 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-9.tower-31.messagelabs.com with SMTP; 18 Dec 2014 15:17:49 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9ED2530C973_492F01BB for ; Thu, 18 Dec 2014 15:17:47 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 11C883060DE_492F01BF for ; Thu, 18 Dec 2014 15:17:47 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y1cpm-000336-UW; Thu, 18 Dec 2014 15:17:46 +0000 Message-ID: <5492F016.80601@nottingham.ac.uk> Date: Thu, 18 Dec 2014 15:17:42 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Thomas Leonard References: <547757A6.9080504@nottingham.ac.uk> <54789CDF.5050408@nottingham.ac.uk> <29F708AD-B715-4E33-979F-4B0288766935@recoil.org> <5491C606.500@nottingham.ac.uk> In-Reply-To: Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Parallelizing writing to network devices X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 18/12/14 13:19, Thomas Leonard wrote: > On 17 December 2014 at 18:05, Masoud Koleini > wrote: >> Thanks Thomas for the great tracing tool! >> >> The following is a very simple unikernel with two interfaces, which >> redirects frames captured on the first interface to the second one: >> >> https://github.com/koleini/parallelisation >> >> The problem is that in a high packet rate (more than 80'000 pps), switch >> stops receiving. The goal is to spot the problem and enhance the throughput >> of Mirage netif. >> >> Test environment consists of another vm running a traffic generator and >> sending frames of a specific pattern (UDP frames of size 100 bytes) over the >> bridge that connects to the first interface of the unikernel. Unikernel >> forwards frames by collecting a number of frames from input queue and >> running the same number of threads that write them to the output interface. >> >> Two trace files are uploaded to the repo. The first file is the output of >> this configuration. This trace shows that each netif write locks until the >> thread that writes on the front-end connection to the ring is returned >> (function write_already_locked.) > Do these traces show it after it stopped? The second has a long sleep, > while the first looks like it was in the middle of a run. > > If it had stopped in both cases, it suggests that the whole unikernel > stopped (not just the listen thread), because there are no more timer > interrupts and no sleep region. > > Does "xl top" show the unikernel still using the CPU? Or it is > waiting, or crashed? > > If you have a thread writing a string to the console once per second, > does it continue after unikernel stops accepting frames? Yes, both are. It looks that I have more info on the traces with updated Mirage libraries. So, I updated the traces in the repo. The unikernel is still working, as traces that periodically write info on the console are still working too. With original configuration (netif unchanged), it looks that the reason is unikernel gets out of memory after some time, while error message is shown only in a few experiments. This is the main bottleneck for Mirage applications, which is waiting for a packet write to terminate is time consuming and doesn't allow high rate packet switching for network applications. Modifying netif by ignoring the thread that is waiting for the result of writing to the ring is also problematic. So, any idea how to do bulk packet write on a network interface? > >> For the second trace, the return of the thread is ignored (commenting out >> "lwt () = th in" in write_already_locked). This considerably increases >> switching speed, but after some running time, it looks that after garbage >> collection, similar problem happens. >> >> Thomas and Anil, any idea from given traces, and how it is possible to make >> the traces more informative? >> >> Thanks. >> >> >> On 28/11/14 16:55, Thomas Leonard wrote: >>> On 28 November 2014 at 16:24, Anil Madhavapeddy wrote: >>>>> On 28 Nov 2014, at 16:03, Masoud Koleini >>>>> wrote: >>>>> >>>>> Thanks Anil. >>>>> >>>>>> - graph the ring utilisation to see if it's always full (Thomas >>>>>> Leonard's profiling patches should help here) >>>>> Would you please point me out to the profiling patches? >>>> See: >>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/ >>> The installation instructions here are for the previous version >>> (though they should still work). If you want to try the latest >>> version, the current Git mirage allows you to pass a ~tracing argument >>> to "register" in your config.ml, e.g. >>> >>> let tracing = mprof_trace ~size:1000000 () in >>> register "myunikernel" ~tracing [ >>> main $ ... >>> ] >>> >>> This uses a newer version of the profiling API. You should generally >>> "opam pin" the #tracing2 branches rather than #tracing to use it. >>> >>> Note also that it doesn't currently record ring utilisation, so you'll >>> still need to do some work to get that. You could use the >>> MProf.Counter interface, in which case the GUI will display it as a >>> graph over the trace. >>> >>>>>> - try to reduce the parallelisation to see if some condition there >>>>>> alleviates the issue to track it down. >>>>> Reducing the maximum number of threads running in parallel reduced CPU >>>>> utilization, and vm was functioning for a much longer time, but the same >>>>> problem occurred at the end. >>>>> >>>>> It might be more useful looking at the code. Please have a look at the >>>>> function "f_thread" in the file uploaded on the following repo: >>>>> >>>>> https://github.com/koleini/parallelisation >>>> That's a lot of code to try and distill down a test case. Try to cut it >>>> down significantly by building a minimal Ethernet traffic generator that >>>> outputs frames with a predictable pattern in the frame, and a receiver that >>>> will check that the pattern is received as expected. >>>> >>>> Then you can try out your parallel algorithm variations on the simple >>>> Ethernet sender/receiver and narrow down the problem without all the other >>>> concerns. >>>> >>>> Once the bug is tracked down, we can add the sender/receiver into >>>> mirage-skeleton and use it as a test case to ensure that this functional >>>> never regresses in the future. Line rate Ethernet transmission has worked >>>> in the past, but we never added a test case to ensure it stays working. >>>> >>>> Anil >>>> _______________________________________________ >>>> MirageOS-devel mailing list >>>> MirageOS-devel@lists.xenproject.org >>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >>> >> >> >> >> >> This message and any attachment are intended solely for the addressee and >> may contain confidential information. If you have received this message in >> error, please send it back to me, and immediately delete it. Please do not >> use, copy or disclose the information contained in this message or in any >> attachment. Any views or opinions expressed by the author of this email do >> not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment >> may still contain software viruses which could damage your computer system, >> you are advised to perform your own checks. Email communications with the >> University of Nottingham may be monitored as permitted by UK legislation. >> > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 16:23:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 16:23:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1dr6-00028F-4W; Thu, 18 Dec 2014 16:23:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1dr5-00028A-3v for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 16:23:11 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 5A/DF-09284-E6FF2945; Thu, 18 Dec 2014 16:23:10 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1418919787!14427216!1 X-Originating-IP: [209.85.192.180] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16088 invoked from network); 18 Dec 2014 16:23:08 -0000 Received: from mail-pd0-f180.google.com (HELO mail-pd0-f180.google.com) (209.85.192.180) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 16:23:08 -0000 Received: by mail-pd0-f180.google.com with SMTP id w10so1691267pde.25 for ; Thu, 18 Dec 2014 08:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+/8q1dDErvKyIdV3ku2AIWseQWYx4Vv5tN59FvbFiuw=; b=ZoM6WTYEWAnfHgcKpzPQS7l+MkhQs8zEpyxHMB1bA3Wk0WAyAb6mimZlEDkxl67Tw0 DKkx9PO2+rAJgJ00kTqf/B/qD0Rb4yrmQRdDxDLUMcNgiC+INJo39kwFbsYB7qr1/G0Q OlwTRmdUnokcExlL8GSOEgA+w9egMP26ksbkrOGo+FQ1u0PFslyyOL6hUv9+yTQjkEdj VIVvOgEOlIg+dp5BSjO/FTpXIhK/RytSJvkq1qXe+pKuNNnkM3Kbvx881SxIbm0fVnNx SOn0hFkCxPvsCjFQ7MUimb9nzLpdoxpmtxIrANxUl8KghYTiKl6h491f9LBBKh+UhC2R RMxQ== MIME-Version: 1.0 X-Received: by 10.70.90.10 with SMTP id bs10mr4579691pdb.165.1418919786470; Thu, 18 Dec 2014 08:23:06 -0800 (PST) Received: by 10.70.93.65 with HTTP; Thu, 18 Dec 2014 08:23:06 -0800 (PST) In-Reply-To: References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <4CF51750-C5B8-4A3F-886A-4BFE1FD7007B@recoil.org> Date: Thu, 18 Dec 2014 16:23:06 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641050507081587068==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0641050507081587068== Content-Type: multipart/alternative; boundary=001a11c22310d66422050a800161 --001a11c22310d66422050a800161 Content-Type: text/plain; charset=UTF-8 Sorry I forgot to cc: the list (oops!) On Wed, Dec 17, 2014 at 11:49 AM, David Scott wrote: > > Perhaps to confirm you could increment a counter in "posix_memalign" and > decrement again in the bigarray finaliser (is that "free"?) and print the > total number of outstanding allocations every couple of seconds? > > At some point I'd like to add a bunch of metrics like this and plot graphs > etc. > > > On Wed, Dec 17, 2014 at 11:32 AM, Anil Madhavapeddy > wrote: >> >> And just to confirm that we have no packet loss, I left parallel ping >> floods running for a day. The variance is due to the GC compactions: >> >> 478535022 packets transmitted, 478535022 received, 0% packet loss, time >> 42469559ms >> rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 ms >> >> -anil >> >> > On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: >> > >> > If you're running short of memory on 2GB, that indicates that there's a >> large amount of buffering going on. Are you seeing packet loss as a result? >> > >> > Please do make a note on the bug report that you're seeing this, and >> what the trigger conditions are. If you have a simple mirage-skeleton >> example of an Ethernet port flood that causes this, then that'll help fix >> it. >> > >> > -anil >> > >> >> On 16 Dec 2014, at 15:57, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >> >> >> Yes, I have faced this problem several times when flooding the input >> port (similar error on the console). The allocated memory for the switch is >> 2GB, which is much higher than 64MB, but I guess bit rate should be higher >> too. >> >> >> >> On 16/12/14 23:45, Anil Madhavapeddy wrote: >> >>> On 16 Dec 2014, at 15:23, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >>>> I am wondering if the following issue is already addressed: >> >>>> >> >>>> https://github.com/mirage/mirage-tcpip/issues/33 >> >>>> >> >>>> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> >>>> >> >>> It probably still happens at 64MB of RAM -- it requires some code to >> adjust >> >>> the GC parameters in the OCaml runtime to trigger a collection more >> often. >> >>> It should be harmless however, since (as the bug report observes), a >> failure >> >>> to allocate an Io_page results in a GC compaction that frees up >> memory so >> >>> that the allocation eventually succeeds. >> >>> >> >>> Any particular reason for asking -- is the bug affecting your switch >> somehow? >> >>> >> >>> -anil >> >> >> >> >> >> >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> and may contain confidential information. If you have received this message >> in error, please send it back to me, and immediately delete it. Please do >> not use, copy or disclose the information contained in this message or in >> any attachment. Any views or opinions expressed by the author of this >> email do not necessarily reflect the views of the University of Nottingham. >> >> >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> >> >> > >> > >> > _______________________________________________ >> > MirageOS-devel mailing list >> > MirageOS-devel@lists.xenproject.org >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > > > -- > Dave Scott > -- Dave Scott --001a11c22310d66422050a800161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry I forgot to cc: the list (oops!)

On Wed, Dec 17, 2014 at 11:49 AM, Dav= id Scott <scott.dj@gmail.com> wrote:
Perhaps to confirm you could increment a counter i= n "posix_memalign" and decrement again in the bigarray finaliser = (is that "free"?) and print the total number of outstanding alloc= ations every couple of seconds?

At some point I'd li= ke to add a bunch of metrics like this and plot graphs etc.


On Wed, Dec 17, 2014 at 11:32 AM, Anil Madhavapeddy <an= il@recoil.org> wrote:
And just= to confirm that we have no packet loss, I left parallel ping floods runnin= g for a day.=C2=A0 The variance is due to the GC compactions:

478535022 packets transmitted, 478535022 received, 0% packet loss, time 424= 69559ms
rtt min/avg/max/mdev =3D 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 m= s

-anil

> On 16 Dec 2014, at 15:59, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> If you're running short of memory on 2GB, that indicates that ther= e's a large amount of buffering going on.=C2=A0 Are you seeing packet l= oss as a result?
>
> Please do make a note on the bug report that you're seeing this, a= nd what the trigger conditions are.=C2=A0 If you have a simple mirage-skele= ton example of an Ethernet port flood that causes this, then that'll he= lp fix it.
>
> -anil
>
>> On 16 Dec 2014, at 15:57, Masoud Koleini <masoud.koleini@nottingham.a= c.uk> wrote:
>>
>> Yes, I have faced this problem several times when flooding the inp= ut port (similar error on the console). The allocated memory for the switch= is 2GB, which is much higher than 64MB, but I guess bit rate should be hig= her too.
>>
>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingh= am.ac.uk> wrote:
>>>> I am wondering if the following issue is already addressed= :
>>>>
>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>
>>>> https://lists.cam.ac.uk/pipermail= /cl-mirage/2013-August/msg00104.html
>>>>
>>> It probably still happens at 64MB of RAM -- it requires some c= ode to adjust
>>> the GC parameters in the OCaml runtime to trigger a collection= more often.
>>> It should be harmless however, since (as the bug report observ= es), a failure
>>> to allocate an Io_page results in a GC compaction that frees u= p memory so
>>> that the allocation eventually succeeds.
>>>
>>> Any particular reason for asking -- is the bug affecting your = switch somehow?
>>>
>>> -anil
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addres= see and may contain confidential information. If you have received this mes= sage in error, please send it back to me, and immediately delete it.=C2=A0 = =C2=A0Please do not use, copy or disclose the information contained in this= message or in any attachment.=C2=A0 Any views or opinions expressed by the= author of this email do not necessarily reflect the views of the Universit= y of Nottingham.
>>
>> This message has been checked for viruses but the contents of an a= ttachment may still contain software viruses which could damage your comput= er system, you are advised to perform your own checks. Email communications= with the University of Nottingham may be monitored as permitted by UK legi= slation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/lis= tinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
Mi= rageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Dave Scott


--
Dave Scott
--001a11c22310d66422050a800161-- --===============0641050507081587068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0641050507081587068==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 16:23:15 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 16:23:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1dr6-00028F-4W; Thu, 18 Dec 2014 16:23:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1dr5-00028A-3v for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 16:23:11 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 5A/DF-09284-E6FF2945; Thu, 18 Dec 2014 16:23:10 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1418919787!14427216!1 X-Originating-IP: [209.85.192.180] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16088 invoked from network); 18 Dec 2014 16:23:08 -0000 Received: from mail-pd0-f180.google.com (HELO mail-pd0-f180.google.com) (209.85.192.180) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 18 Dec 2014 16:23:08 -0000 Received: by mail-pd0-f180.google.com with SMTP id w10so1691267pde.25 for ; Thu, 18 Dec 2014 08:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+/8q1dDErvKyIdV3ku2AIWseQWYx4Vv5tN59FvbFiuw=; b=ZoM6WTYEWAnfHgcKpzPQS7l+MkhQs8zEpyxHMB1bA3Wk0WAyAb6mimZlEDkxl67Tw0 DKkx9PO2+rAJgJ00kTqf/B/qD0Rb4yrmQRdDxDLUMcNgiC+INJo39kwFbsYB7qr1/G0Q OlwTRmdUnokcExlL8GSOEgA+w9egMP26ksbkrOGo+FQ1u0PFslyyOL6hUv9+yTQjkEdj VIVvOgEOlIg+dp5BSjO/FTpXIhK/RytSJvkq1qXe+pKuNNnkM3Kbvx881SxIbm0fVnNx SOn0hFkCxPvsCjFQ7MUimb9nzLpdoxpmtxIrANxUl8KghYTiKl6h491f9LBBKh+UhC2R RMxQ== MIME-Version: 1.0 X-Received: by 10.70.90.10 with SMTP id bs10mr4579691pdb.165.1418919786470; Thu, 18 Dec 2014 08:23:06 -0800 (PST) Received: by 10.70.93.65 with HTTP; Thu, 18 Dec 2014 08:23:06 -0800 (PST) In-Reply-To: References: <5490BEED.5050509@nottingham.ac.uk> <5490C6D4.3090102@nottingham.ac.uk> <4CF51750-C5B8-4A3F-886A-4BFE1FD7007B@recoil.org> Date: Thu, 18 Dec 2014 16:23:06 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641050507081587068==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0641050507081587068== Content-Type: multipart/alternative; boundary=001a11c22310d66422050a800161 --001a11c22310d66422050a800161 Content-Type: text/plain; charset=UTF-8 Sorry I forgot to cc: the list (oops!) On Wed, Dec 17, 2014 at 11:49 AM, David Scott wrote: > > Perhaps to confirm you could increment a counter in "posix_memalign" and > decrement again in the bigarray finaliser (is that "free"?) and print the > total number of outstanding allocations every couple of seconds? > > At some point I'd like to add a bunch of metrics like this and plot graphs > etc. > > > On Wed, Dec 17, 2014 at 11:32 AM, Anil Madhavapeddy > wrote: >> >> And just to confirm that we have no packet loss, I left parallel ping >> floods running for a day. The variance is due to the GC compactions: >> >> 478535022 packets transmitted, 478535022 received, 0% packet loss, time >> 42469559ms >> rtt min/avg/max/mdev = 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 ms >> >> -anil >> >> > On 16 Dec 2014, at 15:59, Anil Madhavapeddy wrote: >> > >> > If you're running short of memory on 2GB, that indicates that there's a >> large amount of buffering going on. Are you seeing packet loss as a result? >> > >> > Please do make a note on the bug report that you're seeing this, and >> what the trigger conditions are. If you have a simple mirage-skeleton >> example of an Ethernet port flood that causes this, then that'll help fix >> it. >> > >> > -anil >> > >> >> On 16 Dec 2014, at 15:57, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >> >> >> Yes, I have faced this problem several times when flooding the input >> port (similar error on the console). The allocated memory for the switch is >> 2GB, which is much higher than 64MB, but I guess bit rate should be higher >> too. >> >> >> >> On 16/12/14 23:45, Anil Madhavapeddy wrote: >> >>> On 16 Dec 2014, at 15:23, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >>>> I am wondering if the following issue is already addressed: >> >>>> >> >>>> https://github.com/mirage/mirage-tcpip/issues/33 >> >>>> >> >>>> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> >>>> >> >>> It probably still happens at 64MB of RAM -- it requires some code to >> adjust >> >>> the GC parameters in the OCaml runtime to trigger a collection more >> often. >> >>> It should be harmless however, since (as the bug report observes), a >> failure >> >>> to allocate an Io_page results in a GC compaction that frees up >> memory so >> >>> that the allocation eventually succeeds. >> >>> >> >>> Any particular reason for asking -- is the bug affecting your switch >> somehow? >> >>> >> >>> -anil >> >> >> >> >> >> >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> and may contain confidential information. If you have received this message >> in error, please send it back to me, and immediately delete it. Please do >> not use, copy or disclose the information contained in this message or in >> any attachment. Any views or opinions expressed by the author of this >> email do not necessarily reflect the views of the University of Nottingham. >> >> >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> >> >> > >> > >> > _______________________________________________ >> > MirageOS-devel mailing list >> > MirageOS-devel@lists.xenproject.org >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > > > -- > Dave Scott > -- Dave Scott --001a11c22310d66422050a800161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry I forgot to cc: the list (oops!)

On Wed, Dec 17, 2014 at 11:49 AM, Dav= id Scott <scott.dj@gmail.com> wrote:
Perhaps to confirm you could increment a counter i= n "posix_memalign" and decrement again in the bigarray finaliser = (is that "free"?) and print the total number of outstanding alloc= ations every couple of seconds?

At some point I'd li= ke to add a bunch of metrics like this and plot graphs etc.


On Wed, Dec 17, 2014 at 11:32 AM, Anil Madhavapeddy <an= il@recoil.org> wrote:
And just= to confirm that we have no packet loss, I left parallel ping floods runnin= g for a day.=C2=A0 The variance is due to the GC compactions:

478535022 packets transmitted, 478535022 received, 0% packet loss, time 424= 69559ms
rtt min/avg/max/mdev =3D 0.025/0.051/5.549/0.073 ms, ipg/ewma 0.088/0.065 m= s

-anil

> On 16 Dec 2014, at 15:59, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> If you're running short of memory on 2GB, that indicates that ther= e's a large amount of buffering going on.=C2=A0 Are you seeing packet l= oss as a result?
>
> Please do make a note on the bug report that you're seeing this, a= nd what the trigger conditions are.=C2=A0 If you have a simple mirage-skele= ton example of an Ethernet port flood that causes this, then that'll he= lp fix it.
>
> -anil
>
>> On 16 Dec 2014, at 15:57, Masoud Koleini <masoud.koleini@nottingham.a= c.uk> wrote:
>>
>> Yes, I have faced this problem several times when flooding the inp= ut port (similar error on the console). The allocated memory for the switch= is 2GB, which is much higher than 64MB, but I guess bit rate should be hig= her too.
>>
>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingh= am.ac.uk> wrote:
>>>> I am wondering if the following issue is already addressed= :
>>>>
>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>
>>>> https://lists.cam.ac.uk/pipermail= /cl-mirage/2013-August/msg00104.html
>>>>
>>> It probably still happens at 64MB of RAM -- it requires some c= ode to adjust
>>> the GC parameters in the OCaml runtime to trigger a collection= more often.
>>> It should be harmless however, since (as the bug report observ= es), a failure
>>> to allocate an Io_page results in a GC compaction that frees u= p memory so
>>> that the allocation eventually succeeds.
>>>
>>> Any particular reason for asking -- is the bug affecting your = switch somehow?
>>>
>>> -anil
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addres= see and may contain confidential information. If you have received this mes= sage in error, please send it back to me, and immediately delete it.=C2=A0 = =C2=A0Please do not use, copy or disclose the information contained in this= message or in any attachment.=C2=A0 Any views or opinions expressed by the= author of this email do not necessarily reflect the views of the Universit= y of Nottingham.
>>
>> This message has been checked for viruses but the contents of an a= ttachment may still contain software viruses which could damage your comput= er system, you are advised to perform your own checks. Email communications= with the University of Nottingham may be monitored as permitted by UK legi= slation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/lis= tinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
Mi= rageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Dave Scott


--
Dave Scott
--001a11c22310d66422050a800161-- --===============0641050507081587068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0641050507081587068==-- From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 18:08:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 18:08:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1fUe-0007mZ-Q0; Thu, 18 Dec 2014 18:08:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1fUd-0007mQ-Jj for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:08:07 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 09/42-25276-70813945; Thu, 18 Dec 2014 18:08:07 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-15.tower-21.messagelabs.com!1418926086!16562466!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21234 invoked from network); 18 Dec 2014 18:08:06 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Dec 2014 18:08:06 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host81-149-102-120.in-addr.btopenworld.com ([81.149.102.120]:55816 helo=[10.0.0.5]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1Y1fUb-0003v2-se (Exim 4.82_3-c0e5623) (return-path ); Thu, 18 Dec 2014 18:08:06 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Amir Chaudhry In-Reply-To: <085EF669-48EA-4F19-B2EB-8C5C629D6028@nottingham.ac.uk> Date: Thu, 18 Dec 2014 18:08:06 +0000 Message-Id: <2B3625B3-E726-432B-9980-8155BEE509A8@cam.ac.uk> References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> <5491D4AD.3070804@somerandomidiot.com> <20141217203128.83B0030CA1E_491E820B@uidappmx06.nottingham.ac.uk> <085EF669-48EA-4F19-B2EB-8C5C629D6028@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1510) Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I went last year and keen to go again. On 18 Dec 2014, at 10:23, Richard Mortier wrote: > it's a saturday/sunday-- you teach on a sunday now?! :) i'll look into it... > > but i'd encourage anyone else who's interested to go if they can -- i've only been the once but fosdem was interesting, fun, and a nice atmosphere! > > On 17 Dec 2014, at 20:30, Anil Madhavapeddy wrote: > >> I'll try to attend, but need to check on teaching schedule. Mort isn't teaching next term, hint hint :-) >> >> >> >>> On 17 Dec 2014, at 11:08, Mindy wrote: >>> >>> I've been thinking about attending. I'd be especially enthusiastic about doing so if I knew I'd see some friendly faces :) >>> >>> -Mindy >>> >>>> On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: >>>> Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. >>>> >>>> -anil >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: Lars Kurth >>>>> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >>>>> Date: 17 December 2014 07:17:09 GMT-8 >>>>> To: publicity@lists.xenproject.org >>>>> >>>>> Hi all, >>>>> I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know >>>>> a) What days you will be at FOSDEM >>>>> b) What you'd demonstrate - a headline + a paragraph >>>>> Regards >>>>> Lars >>>> >>>> _______________________________________________ >>>> MirageOS-devel mailing list >>>> MirageOS-devel@lists.xenproject.org >>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >>> >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > -- > Cheers, > > R. > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ] > > > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Thu Dec 18 18:08:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 18 Dec 2014 18:08:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1fUe-0007mZ-Q0; Thu, 18 Dec 2014 18:08:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1fUd-0007mQ-Jj for mirageos-devel@lists.xenproject.org; Thu, 18 Dec 2014 18:08:07 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 09/42-25276-70813945; Thu, 18 Dec 2014 18:08:07 +0000 X-Env-Sender: amc79@cam.ac.uk X-Msg-Ref: server-15.tower-21.messagelabs.com!1418926086!16562466!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21234 invoked from network); 18 Dec 2014 18:08:06 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Dec 2014 18:08:06 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host81-149-102-120.in-addr.btopenworld.com ([81.149.102.120]:55816 helo=[10.0.0.5]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:amc79) (TLSv1:AES128-SHA:128) id 1Y1fUb-0003v2-se (Exim 4.82_3-c0e5623) (return-path ); Thu, 18 Dec 2014 18:08:06 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Amir Chaudhry In-Reply-To: <085EF669-48EA-4F19-B2EB-8C5C629D6028@nottingham.ac.uk> Date: Thu, 18 Dec 2014 18:08:06 +0000 Message-Id: <2B3625B3-E726-432B-9980-8155BEE509A8@cam.ac.uk> References: <67751EEA-64EF-4655-AEF6-EA53CF2056B1@gmail.com> <95E2316C-24E4-4E05-92C3-BF4E081CE1A0@recoil.org> <5491D4AD.3070804@somerandomidiot.com> <20141217203128.83B0030CA1E_491E820B@uidappmx06.nottingham.ac.uk> <085EF669-48EA-4F19-B2EB-8C5C629D6028@nottingham.ac.uk> To: Richard Mortier X-Mailer: Apple Mail (2.1510) Cc: "mirageos-devel@lists.xenproject.org" , Anil Madhavapeddy Subject: Re: [MirageOS-devel] Fwd: Xen Booth @ FOSDEM - call for demo's at the booth X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I went last year and keen to go again. On 18 Dec 2014, at 10:23, Richard Mortier wrote: > it's a saturday/sunday-- you teach on a sunday now?! :) i'll look into it... > > but i'd encourage anyone else who's interested to go if they can -- i've only been the once but fosdem was interesting, fun, and a nice atmosphere! > > On 17 Dec 2014, at 20:30, Anil Madhavapeddy wrote: > >> I'll try to attend, but need to check on teaching schedule. Mort isn't teaching next term, hint hint :-) >> >> >> >>> On 17 Dec 2014, at 11:08, Mindy wrote: >>> >>> I've been thinking about attending. I'd be especially enthusiastic about doing so if I knew I'd see some friendly faces :) >>> >>> -Mindy >>> >>>> On 12/17/2014 10:08 AM, Anil Madhavapeddy wrote: >>>> Would anyone like to attend FOSDEM this year? Mort and I were there last year, and there was a healthy amount of traffic/demonstrations going on about Mirage at the Xen booth. >>>> >>>> -anil >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: Lars Kurth >>>>> Subject: Xen Booth @ FOSDEM - call for demo's at the booth >>>>> Date: 17 December 2014 07:17:09 GMT-8 >>>>> To: publicity@lists.xenproject.org >>>>> >>>>> Hi all, >>>>> I was just notified that the Xen Project's booth was accepted at FOSDEM this year. As last year, I am happy for vendors and community members to give demos. There has to be an open source angle of some sort, otherwise I would be breaking FOSDEM rules. If you want to make use of the offer, please get back to me and let me know >>>>> a) What days you will be at FOSDEM >>>>> b) What you'd demonstrate - a headline + a paragraph >>>>> Regards >>>>> Lars >>>> >>>> _______________________________________________ >>>> MirageOS-devel mailing list >>>> MirageOS-devel@lists.xenproject.org >>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >>> >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >>> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > -- > Cheers, > > R. > > [ This address fails on Dec31. Use richard.mortier@cl.cam.ac.uk subsequently. ] > > > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 10:26:05 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 10:26:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1uky-0000sa-1w; Fri, 19 Dec 2014 10:26:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ukw-0000sP-SB for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 10:25:58 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id FD/45-15461-63DF3945; Fri, 19 Dec 2014 10:25:58 +0000 X-Env-Sender: ania.skorupa@yahoo.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1418984756!16683892!1 X-Originating-IP: [67.195.87.215] X-SpamReason: No, hits=0.9 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31659 invoked from network); 19 Dec 2014 10:25:57 -0000 Received: from nm44-vm10.bullet.mail.gq1.yahoo.com (HELO nm44-vm10.bullet.mail.gq1.yahoo.com) (67.195.87.215) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 10:25:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418984755; bh=CWkqCwj72PTPJ8JghGkv4Qv2hHpklfqSFVpbkJbtx4s=; h=Date:From:Reply-To:To:Subject:From:Subject; b=UUf8bgpqL0Q/sw3MtWg8BxqmS8aqyUTjoljfqI9d0HB9p56kT3kBYOqW/PxnQX2HKA9Ebl4PCy8H04XsX5LeSBwhPbLEC/wHXz1uvl4zTbm+vaKawwjQDrTGzLW3BPhYpjjJ/9NgkMQw7pHiQBk5zDM9/nrBima7hy8h+3ehWBpMeI41rT16DPOMN9doCIXKKEqwD1Ww9Pd1ctm+CMjh28+W8qqCPnpLCCvGKzLm0lA0hgdKOHylcx+BqUD1Ewuz66Trc18pDOW/mopZWeaPxDVLplm/qqpm9yp5HhSzm2/66EcjHQFV/KbeG0nP7/KXoSQ6mCFe++PiEFKFamBvnA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=RQCiVPszeNS9n3aqR5aHm6TcjCeT2+fCdpMe7exH1K/n9imNBMD1O1/oFTXMJ4FcY34LpI5PHpavAdBq26DuPLwfioXoHkmtzpCTcpxb4I1IzoGGEKqjhZ0Ngo6rRhSaM7q+58DZUNBMgZKxDojRErrc5HLrdf8piAEmZVIaGBVxkSiMvSh38lAWWxU7TD8e49S06N2kNqirRZeKW76t44wSeecRgE9rqtjNsd2MSItx+RWniyH0t3U1uJ6Dx76mcsolSMqE6XJk2z3KV7i2Z6246tvi0HKMyUeg0ZQa/SdL/du7I1yAoxG8MWkpOEGRglpuZ+kN8t+ireyHSW3UnQ==; Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 19 Dec 2014 10:25:55 -0000 Received: from [98.137.12.60] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 19 Dec 2014 10:23:14 -0000 Received: from [98.139.214.32] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 19 Dec 2014 10:23:14 -0000 Received: from [98.139.212.237] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 10:23:13 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 10:23:13 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 803989.605.bm@omp1046.mail.bf1.yahoo.com X-YMail-OSG: 3vONGNUVM1lzQ78Je6Vx0Lt_OUyEVsKIBhapFGw693FYZgDrxcX2lQPx9S5PcGO x8KIb0iDbmVOD37uLkQRI2vGiI6Y13sxGgZ4fRezPEk9AmmMaTtc5b.MlB2ZLyqE6ubZhubTXnh_ PMJsxZktGiztPxYKuRfmJKqZwcxzHIdtgCRXeDwPpTEkzwA.ZUwEIZsqa_NtRE9pn.eUjHep49hN gKAVXR751chQ0qr50Tfwe4EH_Qmf6kIKI7awVMPokKZGmhUShJB6WabPmVm7njI7VjliMjeaq.xU Yl1IRI5xwatsKlmhbxGY3b1chp3KfoIDmSogYR7V0S4R9smq.8ffda_aTYFd_.YGZgkTYCZgZI0k 9CM7vy.rq.OEhSjI1RA9lIL03cIyjIXEZn0QaCJKchmLPC9CbjsjWZKz43MF76qRBMen55Hr_kz9 Gdnfflk2I2xc2R6PPHh4P18n0RMUtUNuR2dzddsaiP1AyArh.kPwqEV.Fxovi8Dh95KyvFJEcr1E Z4Ud07wCwKQ-- Received: by 66.196.80.121; Fri, 19 Dec 2014 10:23:13 +0000 Date: Fri, 19 Dec 2014 10:23:13 +0000 (UTC) From: Ania Skorupa To: "mirageos-devel@lists.xenproject.org" Message-ID: <533175116.1203435.1418984593096.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Length:1404 Subject: [MirageOS-devel] modifying mirage types X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ania Skorupa List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3203267347826564457==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3203267347826564457== Content-Type: multipart/alternative; boundary="----=_Part_1203434_1102882588.1418984593094" Content-Length: 862 ------=_Part_1203434_1102882588.1418984593094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit hi, can someone kindly help how I can modify and apply mirage types in V1 and explain the difference with V1_LWT? ------=_Part_1203434_1102882588.1418984593094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
hi,

can someone kindly help how I can modify and apply mirage types in V1 and explain the difference with V1_LWT?

------=_Part_1203434_1102882588.1418984593094-- --===============3203267347826564457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3203267347826564457==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 10:26:05 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 10:26:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1uky-0000sa-1w; Fri, 19 Dec 2014 10:26:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1ukw-0000sP-SB for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 10:25:58 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id FD/45-15461-63DF3945; Fri, 19 Dec 2014 10:25:58 +0000 X-Env-Sender: ania.skorupa@yahoo.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1418984756!16683892!1 X-Originating-IP: [67.195.87.215] X-SpamReason: No, hits=0.9 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31659 invoked from network); 19 Dec 2014 10:25:57 -0000 Received: from nm44-vm10.bullet.mail.gq1.yahoo.com (HELO nm44-vm10.bullet.mail.gq1.yahoo.com) (67.195.87.215) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 10:25:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418984755; bh=CWkqCwj72PTPJ8JghGkv4Qv2hHpklfqSFVpbkJbtx4s=; h=Date:From:Reply-To:To:Subject:From:Subject; b=UUf8bgpqL0Q/sw3MtWg8BxqmS8aqyUTjoljfqI9d0HB9p56kT3kBYOqW/PxnQX2HKA9Ebl4PCy8H04XsX5LeSBwhPbLEC/wHXz1uvl4zTbm+vaKawwjQDrTGzLW3BPhYpjjJ/9NgkMQw7pHiQBk5zDM9/nrBima7hy8h+3ehWBpMeI41rT16DPOMN9doCIXKKEqwD1Ww9Pd1ctm+CMjh28+W8qqCPnpLCCvGKzLm0lA0hgdKOHylcx+BqUD1Ewuz66Trc18pDOW/mopZWeaPxDVLplm/qqpm9yp5HhSzm2/66EcjHQFV/KbeG0nP7/KXoSQ6mCFe++PiEFKFamBvnA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=RQCiVPszeNS9n3aqR5aHm6TcjCeT2+fCdpMe7exH1K/n9imNBMD1O1/oFTXMJ4FcY34LpI5PHpavAdBq26DuPLwfioXoHkmtzpCTcpxb4I1IzoGGEKqjhZ0Ngo6rRhSaM7q+58DZUNBMgZKxDojRErrc5HLrdf8piAEmZVIaGBVxkSiMvSh38lAWWxU7TD8e49S06N2kNqirRZeKW76t44wSeecRgE9rqtjNsd2MSItx+RWniyH0t3U1uJ6Dx76mcsolSMqE6XJk2z3KV7i2Z6246tvi0HKMyUeg0ZQa/SdL/du7I1yAoxG8MWkpOEGRglpuZ+kN8t+ireyHSW3UnQ==; Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 19 Dec 2014 10:25:55 -0000 Received: from [98.137.12.60] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 19 Dec 2014 10:23:14 -0000 Received: from [98.139.214.32] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 19 Dec 2014 10:23:14 -0000 Received: from [98.139.212.237] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 10:23:13 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 19 Dec 2014 10:23:13 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 803989.605.bm@omp1046.mail.bf1.yahoo.com X-YMail-OSG: 3vONGNUVM1lzQ78Je6Vx0Lt_OUyEVsKIBhapFGw693FYZgDrxcX2lQPx9S5PcGO x8KIb0iDbmVOD37uLkQRI2vGiI6Y13sxGgZ4fRezPEk9AmmMaTtc5b.MlB2ZLyqE6ubZhubTXnh_ PMJsxZktGiztPxYKuRfmJKqZwcxzHIdtgCRXeDwPpTEkzwA.ZUwEIZsqa_NtRE9pn.eUjHep49hN gKAVXR751chQ0qr50Tfwe4EH_Qmf6kIKI7awVMPokKZGmhUShJB6WabPmVm7njI7VjliMjeaq.xU Yl1IRI5xwatsKlmhbxGY3b1chp3KfoIDmSogYR7V0S4R9smq.8ffda_aTYFd_.YGZgkTYCZgZI0k 9CM7vy.rq.OEhSjI1RA9lIL03cIyjIXEZn0QaCJKchmLPC9CbjsjWZKz43MF76qRBMen55Hr_kz9 Gdnfflk2I2xc2R6PPHh4P18n0RMUtUNuR2dzddsaiP1AyArh.kPwqEV.Fxovi8Dh95KyvFJEcr1E Z4Ud07wCwKQ-- Received: by 66.196.80.121; Fri, 19 Dec 2014 10:23:13 +0000 Date: Fri, 19 Dec 2014 10:23:13 +0000 (UTC) From: Ania Skorupa To: "mirageos-devel@lists.xenproject.org" Message-ID: <533175116.1203435.1418984593096.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Length:1404 Subject: [MirageOS-devel] modifying mirage types X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ania Skorupa List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3203267347826564457==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============3203267347826564457== Content-Type: multipart/alternative; boundary="----=_Part_1203434_1102882588.1418984593094" Content-Length: 862 ------=_Part_1203434_1102882588.1418984593094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit hi, can someone kindly help how I can modify and apply mirage types in V1 and explain the difference with V1_LWT? ------=_Part_1203434_1102882588.1418984593094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
hi,

can someone kindly help how I can modify and apply mirage types in V1 and explain the difference with V1_LWT?

------=_Part_1203434_1102882588.1418984593094-- --===============3203267347826564457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============3203267347826564457==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 14:49:32 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 14:49:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1yrs-0004tf-Fj; Fri, 19 Dec 2014 14:49:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1yrq-0004ta-E7 for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 14:49:22 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id BE/81-25547-1FA34945; Fri, 19 Dec 2014 14:49:21 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1419000559!12216297!1 X-Originating-IP: [209.85.215.54] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25886 invoked from network); 19 Dec 2014 14:49:20 -0000 Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 14:49:20 -0000 Received: by mail-la0-f54.google.com with SMTP id pv20so953094lab.27 for ; Fri, 19 Dec 2014 06:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eK0pM536TIAC4/cjRkSzRq8QJZUf+ulbVe1WdqctjfU=; b=fmY+MJ+SA024ap52p0D+EN+gukI/1lV5LsqR26ztX11XYaTgraUgM7jbrkWPvgqwIW CUxwabbS3Icrw6JvG2usSYF/cOxmssmUuJ8gFuizZL0/xqQN97RzXoVIt8LpnECprS/0 BvL0WQCW46R4s5dRwUwS0Giwx+rhSz+fj4HivvFhehGy5DoOgrEAhMzeiiRaClph8NZA jeluCyhtMlHdD8VK8Bb28cp6lu7o11IjWKSM91RUmAhs+qniAur/kDVvFK3UUq2BLTSv uATDRK6EcafwuzaBIekuQPUf3TRe8Ga/rBCH2Qsu+cI9dXlehKgvPHvt1RWFscdkf7el xRhQ== MIME-Version: 1.0 X-Received: by 10.152.21.9 with SMTP id r9mr8235120lae.76.1419000559005; Fri, 19 Dec 2014 06:49:19 -0800 (PST) Received: by 10.112.48.65 with HTTP; Fri, 19 Dec 2014 06:49:18 -0800 (PST) Date: Fri, 19 Dec 2014 08:49:18 -0600 Message-ID: From: Brian Brietzke To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7267367130519781023==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7267367130519781023== Content-Type: multipart/alternative; boundary=089e013d20244177bc050a92d02f --089e013d20244177bc050a92d02f Content-Type: text/plain; charset=UTF-8 I got a chance to see the video from CodeMesh London ( https://www.youtube.com/watch?v=hAZhm66pwhc&feature=youtube_gdata ) and it help make some of the things in the Mirage code base makes sense. It also helped put me on the right path for building a configurable framework that could be used along and inside of Mirage. Make everything modules and use functors to provide the implementation! Which sounds easy, but I'm struggling along. What I would like to start off with is a new implementation of the KV_RO module but using Redis instead of crunch or the file system. I think I need three things: one is the actual implementation module that implements the KV_RO interface / module, one module that provides the packages and libraries you need ( the Impl module? ) and then another for tie those together. I think I'm struggling with the part of tying things together and making them work. I started with the crunch kv_ro example since it was close enough to what I want to do. I have a module named Kv that provides the libraries/packages/configure roughed out and had ( and will add it back ) a module for the redis kv_ro. I've had functors and just normal functions that try to create the modules based on the what is done for crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try to use Kv or KvRoRedis directly, i receive an unbound constructor error. Code can be found at: https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml Any help or guidance would be appreciated. --089e013d20244177bc050a92d02f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I got a chance to see the video from CodeMesh London (=C2= =A0https://www.youtube.com/watch?v=3DhAZhm66pwhc&feature=3Dy= outube_gdata ) and it help make some of the things in the Mirage code b= ase makes sense.=C2=A0 It also helped put me on the right path for building= a configurable framework that could be used along and inside of Mirage.=C2= =A0 Make everything modules and use functors to provide the implementation!=

Which sounds easy, but I'm struggling along.
<= div>
What I would like to start off with is a new implementat= ion of the KV_RO module but using Redis instead of crunch or the file syste= m. =C2=A0

I think I need three things: =C2=A0one i= s the actual implementation module that implements the KV_RO interface / mo= dule, one module that provides the packages and libraries you need ( the Im= pl module? ) and then another for tie those together.

<= div>I think I'm struggling with the part of tying things together and m= aking them work. =C2=A0

I started with the crunch = kv_ro example since it was close enough to what I want to do.=C2=A0 I have = a module named Kv that provides the libraries/packages/configure roughed ou= t and had ( and will add it back ) a module for the redis kv_ro.
=
I've had functors and just normal functions that try to = create the modules based on the what is done for crunch ( impl kv_ro host (= module Kv/KvRoRedis/etc )) and I'm told that impl cannot be found.=C2= =A0 When i try to use Kv or KvRoRedis directly, i receive an unbound constr= uctor error.

Code can be found at:

Any help or guidance would be appreciated.
--089e013d20244177bc050a92d02f-- --===============7267367130519781023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7267367130519781023==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 14:49:32 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 14:49:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1yrs-0004tf-Fj; Fri, 19 Dec 2014 14:49:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1yrq-0004ta-E7 for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 14:49:22 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id BE/81-25547-1FA34945; Fri, 19 Dec 2014 14:49:21 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1419000559!12216297!1 X-Originating-IP: [209.85.215.54] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25886 invoked from network); 19 Dec 2014 14:49:20 -0000 Received: from mail-la0-f54.google.com (HELO mail-la0-f54.google.com) (209.85.215.54) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 14:49:20 -0000 Received: by mail-la0-f54.google.com with SMTP id pv20so953094lab.27 for ; Fri, 19 Dec 2014 06:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eK0pM536TIAC4/cjRkSzRq8QJZUf+ulbVe1WdqctjfU=; b=fmY+MJ+SA024ap52p0D+EN+gukI/1lV5LsqR26ztX11XYaTgraUgM7jbrkWPvgqwIW CUxwabbS3Icrw6JvG2usSYF/cOxmssmUuJ8gFuizZL0/xqQN97RzXoVIt8LpnECprS/0 BvL0WQCW46R4s5dRwUwS0Giwx+rhSz+fj4HivvFhehGy5DoOgrEAhMzeiiRaClph8NZA jeluCyhtMlHdD8VK8Bb28cp6lu7o11IjWKSM91RUmAhs+qniAur/kDVvFK3UUq2BLTSv uATDRK6EcafwuzaBIekuQPUf3TRe8Ga/rBCH2Qsu+cI9dXlehKgvPHvt1RWFscdkf7el xRhQ== MIME-Version: 1.0 X-Received: by 10.152.21.9 with SMTP id r9mr8235120lae.76.1419000559005; Fri, 19 Dec 2014 06:49:19 -0800 (PST) Received: by 10.112.48.65 with HTTP; Fri, 19 Dec 2014 06:49:18 -0800 (PST) Date: Fri, 19 Dec 2014 08:49:18 -0600 Message-ID: From: Brian Brietzke To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7267367130519781023==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7267367130519781023== Content-Type: multipart/alternative; boundary=089e013d20244177bc050a92d02f --089e013d20244177bc050a92d02f Content-Type: text/plain; charset=UTF-8 I got a chance to see the video from CodeMesh London ( https://www.youtube.com/watch?v=hAZhm66pwhc&feature=youtube_gdata ) and it help make some of the things in the Mirage code base makes sense. It also helped put me on the right path for building a configurable framework that could be used along and inside of Mirage. Make everything modules and use functors to provide the implementation! Which sounds easy, but I'm struggling along. What I would like to start off with is a new implementation of the KV_RO module but using Redis instead of crunch or the file system. I think I need three things: one is the actual implementation module that implements the KV_RO interface / module, one module that provides the packages and libraries you need ( the Impl module? ) and then another for tie those together. I think I'm struggling with the part of tying things together and making them work. I started with the crunch kv_ro example since it was close enough to what I want to do. I have a module named Kv that provides the libraries/packages/configure roughed out and had ( and will add it back ) a module for the redis kv_ro. I've had functors and just normal functions that try to create the modules based on the what is done for crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try to use Kv or KvRoRedis directly, i receive an unbound constructor error. Code can be found at: https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml Any help or guidance would be appreciated. --089e013d20244177bc050a92d02f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I got a chance to see the video from CodeMesh London (=C2= =A0https://www.youtube.com/watch?v=3DhAZhm66pwhc&feature=3Dy= outube_gdata ) and it help make some of the things in the Mirage code b= ase makes sense.=C2=A0 It also helped put me on the right path for building= a configurable framework that could be used along and inside of Mirage.=C2= =A0 Make everything modules and use functors to provide the implementation!=

Which sounds easy, but I'm struggling along.
<= div>
What I would like to start off with is a new implementat= ion of the KV_RO module but using Redis instead of crunch or the file syste= m. =C2=A0

I think I need three things: =C2=A0one i= s the actual implementation module that implements the KV_RO interface / mo= dule, one module that provides the packages and libraries you need ( the Im= pl module? ) and then another for tie those together.

<= div>I think I'm struggling with the part of tying things together and m= aking them work. =C2=A0

I started with the crunch = kv_ro example since it was close enough to what I want to do.=C2=A0 I have = a module named Kv that provides the libraries/packages/configure roughed ou= t and had ( and will add it back ) a module for the redis kv_ro.
=
I've had functors and just normal functions that try to = create the modules based on the what is done for crunch ( impl kv_ro host (= module Kv/KvRoRedis/etc )) and I'm told that impl cannot be found.=C2= =A0 When i try to use Kv or KvRoRedis directly, i receive an unbound constr= uctor error.

Code can be found at:

Any help or guidance would be appreciated.
--089e013d20244177bc050a92d02f-- --===============7267367130519781023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7267367130519781023==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 16:27:03 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 16:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20OH-00029d-KH; Fri, 19 Dec 2014 16:26:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20OG-00029Y-3D for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:26:56 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id 26/55-14727-FC154945; Fri, 19 Dec 2014 16:26:55 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1419006413!11028420!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23810 invoked from network); 19 Dec 2014 16:26:53 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 16:26:53 -0000 Received: by mail-la0-f46.google.com with SMTP id q1so1120479lam.5 for ; Fri, 19 Dec 2014 08:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TIVhHRCM1hgGxaufxhatnm0C8888YJHIWjZjDsUGqsU=; b=wNgcSZVn7/9UmxLUeEdaJbOf7QK8InmbrsH008kfRGAjKnkjEfPbZkT7AAuv0x4om2 UXLvfiaIBSZVmlsQ7zfDR+fyPZvd9knSR2s8Bh19FonHysKg7D7iCI2BO9JliAVO4+Wg Wf5RwwvyTLpi4FsHXMYu4e+JeBBpkqxgGorEc3hYCdVneJaAuCbw4u2qfpOC7FQVS1zl Qu9SMiITDRb94b/FOFIIWcn8oPCYUroZW/s2zuYq0Eh0Tiw4WC186p7WBbGZIuzrF+ZK RS4AtQ8+m7SCTS9NjUTUvAoud9/gDMEgwbiMq4wb5PoLMO0yCSU8dosdFtrn3fpWaUyO 3jvw== MIME-Version: 1.0 X-Received: by 10.152.27.8 with SMTP id p8mr8736177lag.69.1419006412776; Fri, 19 Dec 2014 08:26:52 -0800 (PST) Received: by 10.112.202.197 with HTTP; Fri, 19 Dec 2014 08:26:52 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Dec 2014 00:26:52 +0800 Message-ID: From: Luke Dunstan To: Brian Brietzke Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7584209108390482341==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7584209108390482341== Content-Type: multipart/alternative; boundary=089e0160bdb22aeb9e050a942d25 --089e0160bdb22aeb9e050a942d25 Content-Type: text/plain; charset=UTF-8 I am new to Mirage too, so I could be quite wrong... I don't see anywhere in your code where you are calling "impl". But anyway, "impl" is private because it's not exposed (as a val) in mirage.mli: https://github.com/mirage/mirage/blob/master/lib/mirage.mli However, the function "implementation" is public and does basically the same thing. So you want: Also, your Kv module probably shouldn't take another KV_RO module as a parameter, unless you need it for something (. The Crunch module doesn't take any such parameter. Luke On 19 December 2014 at 22:49, Brian Brietzke wrote: > > I got a chance to see the video from CodeMesh London ( > https://www.youtube.com/watch?v=hAZhm66pwhc&feature=youtube_gdata ) and > it help make some of the things in the Mirage code base makes sense. It > also helped put me on the right path for building a configurable framework > that could be used along and inside of Mirage. Make everything modules and > use functors to provide the implementation! > > Which sounds easy, but I'm struggling along. > > What I would like to start off with is a new implementation of the KV_RO > module but using Redis instead of crunch or the file system. > > I think I need three things: one is the actual implementation module that > implements the KV_RO interface / module, one module that provides the > packages and libraries you need ( the Impl module? ) and then another for > tie those together. > > I think I'm struggling with the part of tying things together and making > them work. > > I started with the crunch kv_ro example since it was close enough to what > I want to do. I have a module named Kv that provides the > libraries/packages/configure roughed out and had ( and will add it back ) a > module for the redis kv_ro. > > I've had functors and just normal functions that try to create the modules > based on the what is done for crunch ( impl kv_ro host (module > Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try to > use Kv or KvRoRedis directly, i receive an unbound constructor error. > > Code can be found at: > https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml > > Any help or guidance would be appreciated. > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --089e0160bdb22aeb9e050a942d25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am new to Mirage too, so I could be quite wrong...
<= br>
I don't see anywhere in your code where you are calling &= quot;impl". But anyway, "impl" is private because it's n= ot exposed (as a val) in mirage.mli:

=

However, the function "implementation" is pub= lic and does basically the same thing. So you want:


Also, your Kv module probably shouldn't take another K= V_RO module as a parameter, unless you need it for something (. The Crunch = module doesn't take any such parameter.

Luke



On 19 December 2014 at 22:49, Brian Brietzke <bbr= ietzke@gmail.com> wrote:
I got a chance to see the video from CodeMesh London (=C2=A0https://www.youtube.com/watch?v=3DhAZhm66pwhc&= feature=3Dyoutube_gdata ) and it help make some of the things in the Mi= rage code base makes sense.=C2=A0 It also helped put me on the right path f= or building a configurable framework that could be used along and inside of= Mirage.=C2=A0 Make everything modules and use functors to provide the impl= ementation!

Which sounds easy, but I'm struggling al= ong.

What I would like to start off with is a new = implementation of the KV_RO module but using Redis instead of crunch or the= file system. =C2=A0

I think I need three things: = =C2=A0one is the actual implementation module that implements the KV_RO int= erface / module, one module that provides the packages and libraries you ne= ed ( the Impl module? ) and then another for tie those together.
=
I think I'm struggling with the part of tying things tog= ether and making them work. =C2=A0

I started with = the crunch kv_ro example since it was close enough to what I want to do.=C2= =A0 I have a module named Kv that provides the libraries/packages/configure= roughed out and had ( and will add it back ) a module for the redis kv_ro.=

I've had functors and just normal functions t= hat try to create the modules based on the what is done for crunch ( impl k= v_ro host (module Kv/KvRoRedis/etc )) and I'm told that impl cannot be = found.=C2=A0 When i try to use Kv or KvRoRedis directly, i receive an unbou= nd constructor error.

Code can be found at:
<= div>https://github.com/bbrietzke/sad_butter/blob/re= dis_kv/src/rediskv.ml

Any help or guidance= would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--089e0160bdb22aeb9e050a942d25-- --===============7584209108390482341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7584209108390482341==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 16:27:03 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 16:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20OH-00029d-KH; Fri, 19 Dec 2014 16:26:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20OG-00029Y-3D for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:26:56 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id 26/55-14727-FC154945; Fri, 19 Dec 2014 16:26:55 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1419006413!11028420!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23810 invoked from network); 19 Dec 2014 16:26:53 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 16:26:53 -0000 Received: by mail-la0-f46.google.com with SMTP id q1so1120479lam.5 for ; Fri, 19 Dec 2014 08:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TIVhHRCM1hgGxaufxhatnm0C8888YJHIWjZjDsUGqsU=; b=wNgcSZVn7/9UmxLUeEdaJbOf7QK8InmbrsH008kfRGAjKnkjEfPbZkT7AAuv0x4om2 UXLvfiaIBSZVmlsQ7zfDR+fyPZvd9knSR2s8Bh19FonHysKg7D7iCI2BO9JliAVO4+Wg Wf5RwwvyTLpi4FsHXMYu4e+JeBBpkqxgGorEc3hYCdVneJaAuCbw4u2qfpOC7FQVS1zl Qu9SMiITDRb94b/FOFIIWcn8oPCYUroZW/s2zuYq0Eh0Tiw4WC186p7WBbGZIuzrF+ZK RS4AtQ8+m7SCTS9NjUTUvAoud9/gDMEgwbiMq4wb5PoLMO0yCSU8dosdFtrn3fpWaUyO 3jvw== MIME-Version: 1.0 X-Received: by 10.152.27.8 with SMTP id p8mr8736177lag.69.1419006412776; Fri, 19 Dec 2014 08:26:52 -0800 (PST) Received: by 10.112.202.197 with HTTP; Fri, 19 Dec 2014 08:26:52 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Dec 2014 00:26:52 +0800 Message-ID: From: Luke Dunstan To: Brian Brietzke Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7584209108390482341==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7584209108390482341== Content-Type: multipart/alternative; boundary=089e0160bdb22aeb9e050a942d25 --089e0160bdb22aeb9e050a942d25 Content-Type: text/plain; charset=UTF-8 I am new to Mirage too, so I could be quite wrong... I don't see anywhere in your code where you are calling "impl". But anyway, "impl" is private because it's not exposed (as a val) in mirage.mli: https://github.com/mirage/mirage/blob/master/lib/mirage.mli However, the function "implementation" is public and does basically the same thing. So you want: Also, your Kv module probably shouldn't take another KV_RO module as a parameter, unless you need it for something (. The Crunch module doesn't take any such parameter. Luke On 19 December 2014 at 22:49, Brian Brietzke wrote: > > I got a chance to see the video from CodeMesh London ( > https://www.youtube.com/watch?v=hAZhm66pwhc&feature=youtube_gdata ) and > it help make some of the things in the Mirage code base makes sense. It > also helped put me on the right path for building a configurable framework > that could be used along and inside of Mirage. Make everything modules and > use functors to provide the implementation! > > Which sounds easy, but I'm struggling along. > > What I would like to start off with is a new implementation of the KV_RO > module but using Redis instead of crunch or the file system. > > I think I need three things: one is the actual implementation module that > implements the KV_RO interface / module, one module that provides the > packages and libraries you need ( the Impl module? ) and then another for > tie those together. > > I think I'm struggling with the part of tying things together and making > them work. > > I started with the crunch kv_ro example since it was close enough to what > I want to do. I have a module named Kv that provides the > libraries/packages/configure roughed out and had ( and will add it back ) a > module for the redis kv_ro. > > I've had functors and just normal functions that try to create the modules > based on the what is done for crunch ( impl kv_ro host (module > Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try to > use Kv or KvRoRedis directly, i receive an unbound constructor error. > > Code can be found at: > https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml > > Any help or guidance would be appreciated. > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --089e0160bdb22aeb9e050a942d25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am new to Mirage too, so I could be quite wrong...
<= br>
I don't see anywhere in your code where you are calling &= quot;impl". But anyway, "impl" is private because it's n= ot exposed (as a val) in mirage.mli:

=

However, the function "implementation" is pub= lic and does basically the same thing. So you want:


Also, your Kv module probably shouldn't take another K= V_RO module as a parameter, unless you need it for something (. The Crunch = module doesn't take any such parameter.

Luke



On 19 December 2014 at 22:49, Brian Brietzke <bbr= ietzke@gmail.com> wrote:
I got a chance to see the video from CodeMesh London (=C2=A0https://www.youtube.com/watch?v=3DhAZhm66pwhc&= feature=3Dyoutube_gdata ) and it help make some of the things in the Mi= rage code base makes sense.=C2=A0 It also helped put me on the right path f= or building a configurable framework that could be used along and inside of= Mirage.=C2=A0 Make everything modules and use functors to provide the impl= ementation!

Which sounds easy, but I'm struggling al= ong.

What I would like to start off with is a new = implementation of the KV_RO module but using Redis instead of crunch or the= file system. =C2=A0

I think I need three things: = =C2=A0one is the actual implementation module that implements the KV_RO int= erface / module, one module that provides the packages and libraries you ne= ed ( the Impl module? ) and then another for tie those together.
=
I think I'm struggling with the part of tying things tog= ether and making them work. =C2=A0

I started with = the crunch kv_ro example since it was close enough to what I want to do.=C2= =A0 I have a module named Kv that provides the libraries/packages/configure= roughed out and had ( and will add it back ) a module for the redis kv_ro.=

I've had functors and just normal functions t= hat try to create the modules based on the what is done for crunch ( impl k= v_ro host (module Kv/KvRoRedis/etc )) and I'm told that impl cannot be = found.=C2=A0 When i try to use Kv or KvRoRedis directly, i receive an unbou= nd constructor error.

Code can be found at:
<= div>https://github.com/bbrietzke/sad_butter/blob/re= dis_kv/src/rediskv.ml

Any help or guidance= would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--089e0160bdb22aeb9e050a942d25-- --===============7584209108390482341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7584209108390482341==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 16:33:49 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 16:33:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20Uv-0002Ul-73; Fri, 19 Dec 2014 16:33:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20Ut-0002Ug-G0 for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:33:47 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id BA/73-14727-A6354945; Fri, 19 Dec 2014 16:33:46 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1419006825!14363390!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17042 invoked from network); 19 Dec 2014 16:33:45 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 16:33:45 -0000 Received: by mail-la0-f43.google.com with SMTP id s18so1145475lam.2 for ; Fri, 19 Dec 2014 08:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6xSjjRO0hKz4f6VOqruF7FmksPkwz36HT64vujxFYHo=; b=BNNbmD+JdQ29RhUr8ZYEovNzau5l6fE4d/95VoYAPIHmuo+DVh+rZySA5heh1Q1b1R qLuR+aIH/xzvqsP4y9b0B8265IUv7REAHTZRFQvUL3J1XhQGqEjZ3/ntFZlPqMjObYUr yBS4t8lb2amtdj2Lxd1RAW/20a1Lox+ipTB6TKomed8/rFrovbW0gAzIIRaLbpx/eFe8 JCUa3lvfYHIY4xUEgnR6wx0q3B7H5M8bsJ0T6i6PGwxy5vcC/oGubkQFkp1Dw9B9jEG4 fNAdEVEAGcZST6vfxsO8J7UXJa3Yq7WgTrr3T2zgbDQmARxGV8OlJN27ex4S9UcuOdiu 0MwA== MIME-Version: 1.0 X-Received: by 10.112.219.98 with SMTP id pn2mr6763420lbc.74.1419006824542; Fri, 19 Dec 2014 08:33:44 -0800 (PST) Received: by 10.112.202.197 with HTTP; Fri, 19 Dec 2014 08:33:44 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Dec 2014 00:33:44 +0800 Message-ID: From: Luke Dunstan To: Brian Brietzke Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8078822698224716727==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8078822698224716727== Content-Type: multipart/alternative; boundary=001a11c31306b5f902050a9445ae --001a11c31306b5f902050a9445ae Content-Type: text/plain; charset=UTF-8 Sorry, sent too soon. I meant to say: let r1 = implementation kv_ro () (module Rediskv.Kv) (but that's assuming Kv isn't parameterised). Then you have to fix the compile error in Rediskv.Make. But after that: Error loading config: error loading shared library: /home/luked/mirage/sad_butter/src/_build/config.cmxs: undefined symbol: camlRediskv So I don't know if "mirage configure" actually supports your case of referring to another module from within config.ml Luke On 20 December 2014 at 00:26, Luke Dunstan wrote: > > I am new to Mirage too, so I could be quite wrong... > > I don't see anywhere in your code where you are calling "impl". But > anyway, "impl" is private because it's not exposed (as a val) in mirage.mli: > > https://github.com/mirage/mirage/blob/master/lib/mirage.mli > > However, the function "implementation" is public and does basically the > same thing. So you want: > > > Also, your Kv module probably shouldn't take another KV_RO module as a > parameter, unless you need it for something (. The Crunch module doesn't > take any such parameter. > > Luke > > > > On 19 December 2014 at 22:49, Brian Brietzke wrote: > >> I got a chance to see the video from CodeMesh London ( >> https://www.youtube.com/watch?v=hAZhm66pwhc&feature=youtube_gdata ) and >> it help make some of the things in the Mirage code base makes sense. It >> also helped put me on the right path for building a configurable framework >> that could be used along and inside of Mirage. Make everything modules and >> use functors to provide the implementation! >> >> Which sounds easy, but I'm struggling along. >> >> What I would like to start off with is a new implementation of the KV_RO >> module but using Redis instead of crunch or the file system. >> >> I think I need three things: one is the actual implementation module >> that implements the KV_RO interface / module, one module that provides the >> packages and libraries you need ( the Impl module? ) and then another for >> tie those together. >> >> I think I'm struggling with the part of tying things together and making >> them work. >> >> I started with the crunch kv_ro example since it was close enough to what >> I want to do. I have a module named Kv that provides the >> libraries/packages/configure roughed out and had ( and will add it back ) a >> module for the redis kv_ro. >> >> I've had functors and just normal functions that try to create the >> modules based on the what is done for crunch ( impl kv_ro host (module >> Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try to >> use Kv or KvRoRedis directly, i receive an unbound constructor error. >> >> Code can be found at: >> https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml >> >> Any help or guidance would be appreciated. >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> --001a11c31306b5f902050a9445ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, sent too soon. I meant to say:

<= div>let r1 =3D implementation kv_ro () (module Rediskv.Kv)
=
(but that's assuming Kv isn't parameterised). Then y= ou have to fix the compile error in Rediskv.Make. But after that:

Error loading config: error loading shared library: /home/l= uked/mirage/sad_butter/src/_build/config.cmxs: undefined symbol: camlRedisk= v

So I don't know if "mirage configur= e" actually supports your case of referring to another module from wit= hin config.ml

Luk= e


On 20 December 2014 at 00:26, Luke Dunstan <= ;lukedunstan81= @gmail.com> wrote:
I am new to Mirage too, so I could be quite wrong...

I don't see anywhere in your code where you are calling "impl&qu= ot;. But anyway, "impl" is private because it's not exposed (= as a val) in mirage.mli:


However, the function "implementation" is public and does= basically the same thing. So you want:


=
Also, your Kv module probably shouldn't take another KV_RO module = as a parameter, unless you need it for something (. The Crunch module doesn= 't take any such parameter.

Luke


On 19 December 2014 at 22:49, Brian Briet= zke <bbrietzke@gmail.com> wrote:
I got a chance to = see the video from CodeMesh London (=C2=A0http= s://www.youtube.com/watch?v=3DhAZhm66pwhc&feature=3Dyoutube_gdata )= and it help make some of the things in the Mirage code base makes sense.= =C2=A0 It also helped put me on the right path for building a configurable = framework that could be used along and inside of Mirage.=C2=A0 Make everyth= ing modules and use functors to provide the implementation!

<= div>Which sounds easy, but I'm struggling along.

What I would like to start off with is a new implementation of the KV_RO= module but using Redis instead of crunch or the file system. =C2=A0
<= div>
I think I need three things: =C2=A0one is the actual imp= lementation module that implements the KV_RO interface / module, one module= that provides the packages and libraries you need ( the Impl module? ) and= then another for tie those together.

I think I= 9;m struggling with the part of tying things together and making them work.= =C2=A0

I started with the crunch kv_ro example si= nce it was close enough to what I want to do.=C2=A0 I have a module named K= v that provides the libraries/packages/configure roughed out and had ( and = will add it back ) a module for the redis kv_ro.

I= 've had functors and just normal functions that try to create the modul= es based on the what is done for crunch ( impl kv_ro host (module Kv/KvRoRe= dis/etc )) and I'm told that impl cannot be found.=C2=A0 When i try to = use Kv or KvRoRedis directly, i receive an unbound constructor error.
=

Code can be found at:

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
Mi= rageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a11c31306b5f902050a9445ae-- --===============8078822698224716727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8078822698224716727==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 16:33:49 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 16:33:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20Uv-0002Ul-73; Fri, 19 Dec 2014 16:33:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20Ut-0002Ug-G0 for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:33:47 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id BA/73-14727-A6354945; Fri, 19 Dec 2014 16:33:46 +0000 X-Env-Sender: lukedunstan81@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1419006825!14363390!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17042 invoked from network); 19 Dec 2014 16:33:45 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 16:33:45 -0000 Received: by mail-la0-f43.google.com with SMTP id s18so1145475lam.2 for ; Fri, 19 Dec 2014 08:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6xSjjRO0hKz4f6VOqruF7FmksPkwz36HT64vujxFYHo=; b=BNNbmD+JdQ29RhUr8ZYEovNzau5l6fE4d/95VoYAPIHmuo+DVh+rZySA5heh1Q1b1R qLuR+aIH/xzvqsP4y9b0B8265IUv7REAHTZRFQvUL3J1XhQGqEjZ3/ntFZlPqMjObYUr yBS4t8lb2amtdj2Lxd1RAW/20a1Lox+ipTB6TKomed8/rFrovbW0gAzIIRaLbpx/eFe8 JCUa3lvfYHIY4xUEgnR6wx0q3B7H5M8bsJ0T6i6PGwxy5vcC/oGubkQFkp1Dw9B9jEG4 fNAdEVEAGcZST6vfxsO8J7UXJa3Yq7WgTrr3T2zgbDQmARxGV8OlJN27ex4S9UcuOdiu 0MwA== MIME-Version: 1.0 X-Received: by 10.112.219.98 with SMTP id pn2mr6763420lbc.74.1419006824542; Fri, 19 Dec 2014 08:33:44 -0800 (PST) Received: by 10.112.202.197 with HTTP; Fri, 19 Dec 2014 08:33:44 -0800 (PST) In-Reply-To: References: Date: Sat, 20 Dec 2014 00:33:44 +0800 Message-ID: From: Luke Dunstan To: Brian Brietzke Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8078822698224716727==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8078822698224716727== Content-Type: multipart/alternative; boundary=001a11c31306b5f902050a9445ae --001a11c31306b5f902050a9445ae Content-Type: text/plain; charset=UTF-8 Sorry, sent too soon. I meant to say: let r1 = implementation kv_ro () (module Rediskv.Kv) (but that's assuming Kv isn't parameterised). Then you have to fix the compile error in Rediskv.Make. But after that: Error loading config: error loading shared library: /home/luked/mirage/sad_butter/src/_build/config.cmxs: undefined symbol: camlRediskv So I don't know if "mirage configure" actually supports your case of referring to another module from within config.ml Luke On 20 December 2014 at 00:26, Luke Dunstan wrote: > > I am new to Mirage too, so I could be quite wrong... > > I don't see anywhere in your code where you are calling "impl". But > anyway, "impl" is private because it's not exposed (as a val) in mirage.mli: > > https://github.com/mirage/mirage/blob/master/lib/mirage.mli > > However, the function "implementation" is public and does basically the > same thing. So you want: > > > Also, your Kv module probably shouldn't take another KV_RO module as a > parameter, unless you need it for something (. The Crunch module doesn't > take any such parameter. > > Luke > > > > On 19 December 2014 at 22:49, Brian Brietzke wrote: > >> I got a chance to see the video from CodeMesh London ( >> https://www.youtube.com/watch?v=hAZhm66pwhc&feature=youtube_gdata ) and >> it help make some of the things in the Mirage code base makes sense. It >> also helped put me on the right path for building a configurable framework >> that could be used along and inside of Mirage. Make everything modules and >> use functors to provide the implementation! >> >> Which sounds easy, but I'm struggling along. >> >> What I would like to start off with is a new implementation of the KV_RO >> module but using Redis instead of crunch or the file system. >> >> I think I need three things: one is the actual implementation module >> that implements the KV_RO interface / module, one module that provides the >> packages and libraries you need ( the Impl module? ) and then another for >> tie those together. >> >> I think I'm struggling with the part of tying things together and making >> them work. >> >> I started with the crunch kv_ro example since it was close enough to what >> I want to do. I have a module named Kv that provides the >> libraries/packages/configure roughed out and had ( and will add it back ) a >> module for the redis kv_ro. >> >> I've had functors and just normal functions that try to create the >> modules based on the what is done for crunch ( impl kv_ro host (module >> Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try to >> use Kv or KvRoRedis directly, i receive an unbound constructor error. >> >> Code can be found at: >> https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml >> >> Any help or guidance would be appreciated. >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> --001a11c31306b5f902050a9445ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, sent too soon. I meant to say:

<= div>let r1 =3D implementation kv_ro () (module Rediskv.Kv)
=
(but that's assuming Kv isn't parameterised). Then y= ou have to fix the compile error in Rediskv.Make. But after that:

Error loading config: error loading shared library: /home/l= uked/mirage/sad_butter/src/_build/config.cmxs: undefined symbol: camlRedisk= v

So I don't know if "mirage configur= e" actually supports your case of referring to another module from wit= hin config.ml

Luk= e


On 20 December 2014 at 00:26, Luke Dunstan <= ;lukedunstan81= @gmail.com> wrote:
I am new to Mirage too, so I could be quite wrong...

I don't see anywhere in your code where you are calling "impl&qu= ot;. But anyway, "impl" is private because it's not exposed (= as a val) in mirage.mli:


However, the function "implementation" is public and does= basically the same thing. So you want:


=
Also, your Kv module probably shouldn't take another KV_RO module = as a parameter, unless you need it for something (. The Crunch module doesn= 't take any such parameter.

Luke


On 19 December 2014 at 22:49, Brian Briet= zke <bbrietzke@gmail.com> wrote:
I got a chance to = see the video from CodeMesh London (=C2=A0http= s://www.youtube.com/watch?v=3DhAZhm66pwhc&feature=3Dyoutube_gdata )= and it help make some of the things in the Mirage code base makes sense.= =C2=A0 It also helped put me on the right path for building a configurable = framework that could be used along and inside of Mirage.=C2=A0 Make everyth= ing modules and use functors to provide the implementation!

<= div>Which sounds easy, but I'm struggling along.

What I would like to start off with is a new implementation of the KV_RO= module but using Redis instead of crunch or the file system. =C2=A0
<= div>
I think I need three things: =C2=A0one is the actual imp= lementation module that implements the KV_RO interface / module, one module= that provides the packages and libraries you need ( the Impl module? ) and= then another for tie those together.

I think I= 9;m struggling with the part of tying things together and making them work.= =C2=A0

I started with the crunch kv_ro example si= nce it was close enough to what I want to do.=C2=A0 I have a module named K= v that provides the libraries/packages/configure roughed out and had ( and = will add it back ) a module for the redis kv_ro.

I= 've had functors and just normal functions that try to create the modul= es based on the what is done for crunch ( impl kv_ro host (module Kv/KvRoRe= dis/etc )) and I'm told that impl cannot be found.=C2=A0 When i try to = use Kv or KvRoRedis directly, i receive an unbound constructor error.
=

Code can be found at:

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
Mi= rageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel

--001a11c31306b5f902050a9445ae-- --===============8078822698224716727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8078822698224716727==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 16:58:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 16:58:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20su-0003Hp-Hq; Fri, 19 Dec 2014 16:58:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20st-0003Hk-BB for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:58:35 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 81/06-19763-A3954945; Fri, 19 Dec 2014 16:58:34 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1419008312!6804346!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32190 invoked from network); 19 Dec 2014 16:58:32 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 16:58:32 -0000 Received: by mail-wi0-f182.google.com with SMTP id h11so2436620wiw.3 for ; Fri, 19 Dec 2014 08:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lfCnMQHjWMYCzFQKEGNqXEQsUPDzAbJM/wDje/laH6I=; b=zlLolvoJlVquMbYsjQtA376n+lTOF3XV4Z/AIkoCB0hsVq941Kj2R5kiQ5q+o/CBVI a8BlypAOeehYHNyA8PSy2hvS+RmqL6xbitNscib1x4SyrBoeereNLduuYwnFOlcH6AV5 d9MvIpxy5Yr34StVWmSTr86zcAOsDhbsgOWSp2LR4nzzE4Fd8YrQiiyPg2A9G1YtQBNW HlxECMm7WrUhSZRWr6Xw8U+XO8sUEuRcDZCHdLH9q1BhEEYCFDAGUUoVdehdlOVLnago 78H4uTi7Ukp2zGDF6vGn9b3SLsPEzSZFIomuRpNBNjjLiUxkFo91M4ipMccPFFss41tk koqQ== X-Received: by 10.194.109.6 with SMTP id ho6mr16667448wjb.93.1419008311012; Fri, 19 Dec 2014 08:58:31 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id ry19sm13374664wjb.3.2014.12.19.08.58.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 08:58:30 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Fri, 19 Dec 2014 16:58:28 +0000 Message-Id: References: To: Luke Dunstan X-Mailer: Apple Mail (2.1993) Cc: Brian Brietzke , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7610548546077041593==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7610548546077041593== Content-Type: multipart/alternative; boundary="Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63" --Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, First, thanks for your effort! > So I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml No it doen't (yet), but we had some ideas to make it work (see = http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00078.= html = ) > What I would like to start off with is a new implementation of the = KV_RO module but using Redis instead of crunch or the file system. =20 >=20 > I think I need three things: one is the actual implementation module = that implements the KV_RO interface / module, one module that provides = the packages and libraries you need ( the Impl module? ) and then = another for tie those together. This is indeed what is needed to have a fully supported backend. Before = that, I think the first step (the harder one) is to get your = implementation working on Linux. Just write complete = https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = = to make it work locally for you (compile it as a normal OCaml project, = using ocamlbuild for instance), but everytime you want to do a syscall = (network or disk access) call a function from a parameter of your = functor instead of the one provided by the Unix module. Once this is working fine locally for you, test it manually be applying = different implementations for the functor arguments. Then extend = unikernel.ml to use your functor. And finally we can discuss on how to = integrate it properly in the mirage tool :p Best, Thomas >=20 > I think I'm struggling with the part of tying things together and = making them work. =20 >=20 > I started with the crunch kv_ro example since it was close enough to = what I want to do. I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro. >=20 > I've had functors and just normal functions that try to create the = modules based on the what is done for crunch ( impl kv_ro host (module = Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try = to use Kv or KvRoRedis directly, i receive an unbound constructor error. >=20 > Code can be found at: > https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = >=20 > Any help or guidance would be appreciated. >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org = > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

First, thanks = for your effort!

So = I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml

No it doen't (yet), but we had some ideas to make = it work (see http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 1/msg00078.html)

What I would like to start off with is a new = implementation of the KV_RO module but using Redis instead of crunch or = the file system.  

I think I need three things:  one is the actual = implementation module that implements the KV_RO interface / module, one = module that provides the packages and libraries you need ( the Impl = module? ) and then another for tie those = together.

This is indeed = what is needed to have a fully supported backend. Before that, I think = the first step (the harder one) is to get your implementation working on = Linux. Just write complete https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml to make it work locally for you (compile it as a normal = OCaml project, using ocamlbuild for instance), but everytime you want to = do a syscall (network or disk access) call a function from a parameter = of your functor instead of the one provided by the Unix = module.

Once this is working fine = locally for you, test it manually be applying different implementations = for the functor arguments. Then extend unikernel.ml to use your functor. = And finally we can discuss on how to integrate it properly in the mirage = tool :p

Best,
Thomas



I think = I'm struggling with the part of tying things together and making them = work.  

I = started with the crunch kv_ro example since it was close enough to what = I want to do.  I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro.

I've had functors and just normal = functions that try to create the modules based on the what is done for = crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that = impl cannot be found.  When i try to use Kv or KvRoRedis directly, = i receive an unbound constructor error.

Code can be found at:
https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63-- --===============7610548546077041593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7610548546077041593==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 16:58:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 16:58:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20su-0003Hp-Hq; Fri, 19 Dec 2014 16:58:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y20st-0003Hk-BB for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 16:58:35 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 81/06-19763-A3954945; Fri, 19 Dec 2014 16:58:34 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1419008312!6804346!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32190 invoked from network); 19 Dec 2014 16:58:32 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 16:58:32 -0000 Received: by mail-wi0-f182.google.com with SMTP id h11so2436620wiw.3 for ; Fri, 19 Dec 2014 08:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lfCnMQHjWMYCzFQKEGNqXEQsUPDzAbJM/wDje/laH6I=; b=zlLolvoJlVquMbYsjQtA376n+lTOF3XV4Z/AIkoCB0hsVq941Kj2R5kiQ5q+o/CBVI a8BlypAOeehYHNyA8PSy2hvS+RmqL6xbitNscib1x4SyrBoeereNLduuYwnFOlcH6AV5 d9MvIpxy5Yr34StVWmSTr86zcAOsDhbsgOWSp2LR4nzzE4Fd8YrQiiyPg2A9G1YtQBNW HlxECMm7WrUhSZRWr6Xw8U+XO8sUEuRcDZCHdLH9q1BhEEYCFDAGUUoVdehdlOVLnago 78H4uTi7Ukp2zGDF6vGn9b3SLsPEzSZFIomuRpNBNjjLiUxkFo91M4ipMccPFFss41tk koqQ== X-Received: by 10.194.109.6 with SMTP id ho6mr16667448wjb.93.1419008311012; Fri, 19 Dec 2014 08:58:31 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id ry19sm13374664wjb.3.2014.12.19.08.58.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 08:58:30 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Fri, 19 Dec 2014 16:58:28 +0000 Message-Id: References: To: Luke Dunstan X-Mailer: Apple Mail (2.1993) Cc: Brian Brietzke , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7610548546077041593==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============7610548546077041593== Content-Type: multipart/alternative; boundary="Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63" --Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, First, thanks for your effort! > So I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml No it doen't (yet), but we had some ideas to make it work (see = http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00078.= html = ) > What I would like to start off with is a new implementation of the = KV_RO module but using Redis instead of crunch or the file system. =20 >=20 > I think I need three things: one is the actual implementation module = that implements the KV_RO interface / module, one module that provides = the packages and libraries you need ( the Impl module? ) and then = another for tie those together. This is indeed what is needed to have a fully supported backend. Before = that, I think the first step (the harder one) is to get your = implementation working on Linux. Just write complete = https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = = to make it work locally for you (compile it as a normal OCaml project, = using ocamlbuild for instance), but everytime you want to do a syscall = (network or disk access) call a function from a parameter of your = functor instead of the one provided by the Unix module. Once this is working fine locally for you, test it manually be applying = different implementations for the functor arguments. Then extend = unikernel.ml to use your functor. And finally we can discuss on how to = integrate it properly in the mirage tool :p Best, Thomas >=20 > I think I'm struggling with the part of tying things together and = making them work. =20 >=20 > I started with the crunch kv_ro example since it was close enough to = what I want to do. I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro. >=20 > I've had functors and just normal functions that try to create the = modules based on the what is done for crunch ( impl kv_ro host (module = Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try = to use Kv or KvRoRedis directly, i receive an unbound constructor error. >=20 > Code can be found at: > https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = >=20 > Any help or guidance would be appreciated. >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org = > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

First, thanks = for your effort!

So = I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml

No it doen't (yet), but we had some ideas to make = it work (see http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 1/msg00078.html)

What I would like to start off with is a new = implementation of the KV_RO module but using Redis instead of crunch or = the file system.  

I think I need three things:  one is the actual = implementation module that implements the KV_RO interface / module, one = module that provides the packages and libraries you need ( the Impl = module? ) and then another for tie those = together.

This is indeed = what is needed to have a fully supported backend. Before that, I think = the first step (the harder one) is to get your implementation working on = Linux. Just write complete https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml to make it work locally for you (compile it as a normal = OCaml project, using ocamlbuild for instance), but everytime you want to = do a syscall (network or disk access) call a function from a parameter = of your functor instead of the one provided by the Unix = module.

Once this is working fine = locally for you, test it manually be applying different implementations = for the functor arguments. Then extend unikernel.ml to use your functor. = And finally we can discuss on how to integrate it properly in the mirage = tool :p

Best,
Thomas



I think = I'm struggling with the part of tying things together and making them = work.  

I = started with the crunch kv_ro example since it was close enough to what = I want to do.  I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro.

I've had functors and just normal = functions that try to create the modules based on the what is done for = crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that = impl cannot be found.  When i try to use Kv or KvRoRedis directly, = i receive an unbound constructor error.

Code can be found at:
https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_F0A144CF-2F3B-4188-A624-998143198A63-- --===============7610548546077041593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============7610548546077041593==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:25:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:25:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21It-0004YX-LU; Fri, 19 Dec 2014 17:25:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21Ir-0004YQ-Lq for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:25:26 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id 7B/96-25547-48F54945; Fri, 19 Dec 2014 17:25:24 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-31.messagelabs.com!1419009923!14722294!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23271 invoked from network); 19 Dec 2014 17:25:23 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 17:25:23 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 4bdd4953; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 17:31:25 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <54945722.4010703@nottingham.ac.uk> Date: Fri, 19 Dec 2014 09:25:18 -0800 Message-Id: <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org CCing the list. > On 19 Dec 2014, at 08:49, Masoud Koleini wrote: > > I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error: > > undefined reference to `caml_dealloc_page' > > how do you think I can fix it? > > Thanks. > > On 18/12/14 13:46, Anil Madhavapeddy wrote: >> Not at the moment, although we could easily add an explicit deallocator into >> Io_page. You need to very careful that the page is not used after its lifetime, >> so more pool-based abstractions are preferred (where the pages are recycled into >> an OCaml-managed data structure and reused rather than GCed). >> >> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB >> or so -- if the page allocator still remains low, then it's unlikely to be a GC >> issue and an actual leak somewhere due to holding onto references and keeping >> the page live. >> >> -anil >> >>> On 18 Dec 2014, at 05:41, Masoud Koleini wrote: >>> >>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC? >>> >>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>> I am wondering if the following issue is already addressed: >>>>> >>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>> >>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>> >>>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>>> the GC parameters in the OCaml runtime to trigger a collection more often. >>>> It should be harmless however, since (as the bug report observes), a failure >>>> to allocate an Io_page results in a GC compaction that frees up memory so >>>> that the allocation eventually succeeds. >>>> >>>> Any particular reason for asking -- is the bug affecting your switch somehow? >>>> >>>> -anil >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>> > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:25:28 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:25:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21It-0004YX-LU; Fri, 19 Dec 2014 17:25:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21Ir-0004YQ-Lq for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:25:26 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id 7B/96-25547-48F54945; Fri, 19 Dec 2014 17:25:24 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-31.messagelabs.com!1419009923!14722294!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23271 invoked from network); 19 Dec 2014 17:25:23 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 17:25:23 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 4bdd4953; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 17:31:25 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <54945722.4010703@nottingham.ac.uk> Date: Fri, 19 Dec 2014 09:25:18 -0800 Message-Id: <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org CCing the list. > On 19 Dec 2014, at 08:49, Masoud Koleini wrote: > > I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error: > > undefined reference to `caml_dealloc_page' > > how do you think I can fix it? > > Thanks. > > On 18/12/14 13:46, Anil Madhavapeddy wrote: >> Not at the moment, although we could easily add an explicit deallocator into >> Io_page. You need to very careful that the page is not used after its lifetime, >> so more pool-based abstractions are preferred (where the pages are recycled into >> an OCaml-managed data structure and reused rather than GCed). >> >> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB >> or so -- if the page allocator still remains low, then it's unlikely to be a GC >> issue and an actual leak somewhere due to holding onto references and keeping >> the page live. >> >> -anil >> >>> On 18 Dec 2014, at 05:41, Masoud Koleini wrote: >>> >>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC? >>> >>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>> I am wondering if the following issue is already addressed: >>>>> >>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>> >>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>> >>>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>>> the GC parameters in the OCaml runtime to trigger a collection more often. >>>> It should be harmless however, since (as the bug report observes), a failure >>>> to allocate an Io_page results in a GC compaction that frees up memory so >>>> that the allocation eventually succeeds. >>>> >>>> Any particular reason for asking -- is the bug affecting your switch somehow? >>>> >>>> -anil >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>> > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:33:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:33:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21QM-0004vE-9v; Fri, 19 Dec 2014 17:33:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21QL-0004v9-V6 for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:33:10 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 0D/B4-03145-55164945; Fri, 19 Dec 2014 17:33:09 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1419010388!16251953!1 X-Originating-IP: [209.85.215.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28095 invoked from network); 19 Dec 2014 17:33:08 -0000 Received: from mail-la0-f51.google.com (HELO mail-la0-f51.google.com) (209.85.215.51) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 17:33:08 -0000 Received: by mail-la0-f51.google.com with SMTP id ms9so1229562lab.24 for ; Fri, 19 Dec 2014 09:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Bx44rNtyQMdKSzttjanLOJHf+JNQDTcL8k3CQr4k0e4=; b=UaqEYL4TDcoT8QDjO5dPwyFopQ5ISXAPgsFxFtYyFaRdHOadWbeoSeJ1BA3ntgqFE8 4CPQUVDGAK50YJKUjbm5i1u7wNGh0i1VtYsad0E4AhFEoA9ugpNcNPB9jiVSPD6ow1BW kChjKZnQZKy2Q9kYMlC0foOT+6BoTJFYWUY2KwdZrtXefTvQ5T5ecuy3cqZXDUVXfLCh j34d9hsYGyD2jz2pCE1kBEcF9CmIm5qcj7Fwl9+mHQ9D+0klcyYUJlcmsbzxu68ykiSN L3nEGTFou+crTomvwbjbSmGUcM3IPBmIC1500i3lYPLC/ROw5QFqhSGM880EDlMHEPUv M2pg== MIME-Version: 1.0 X-Received: by 10.112.27.133 with SMTP id t5mr8972879lbg.45.1419010387602; Fri, 19 Dec 2014 09:33:07 -0800 (PST) Received: by 10.25.207.3 with HTTP; Fri, 19 Dec 2014 09:33:07 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Dec 2014 17:33:07 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 14:29, Thomas Leonard wrote: > The TLS work requires ctypes and zarith to run on Xen. I now have > ctypes building with Xen support, but zarith is more difficult. Update gmp and zarith are now working (compiling against only the Mini-OS headers) and can be used from Xen unikernels. You will need: New versions of Mini-OS and Openlibm, adding some previously-missing headers: https://github.com/mirage/mirage-xen-minios/pull/11 mirage-xen, with old (conflicting) headers removed: https://github.com/talex5/mirage-platform/tree/headers (not ready for merge as I need to check if there are more we can lose) mirage-dev repository with the new zarith and gmp packages (we might want to rename zarith to mirage-zarith or similar): opam remote add devel https://github.com/talex5/mirage-dev.git#zarith https://github.com/mirage/mirage-dev/pull/49 Updated mirage tool to fix the link order: opam pin add mirage 'https://github.com/talex5/mirage.git#xen_linkopts' https://github.com/mirage/mirage/pull/341 Now we just need to get Xen support in nocrypto, but that should be fairly straight-forward. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:33:13 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:33:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21QM-0004vE-9v; Fri, 19 Dec 2014 17:33:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21QL-0004v9-V6 for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:33:10 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 0D/B4-03145-55164945; Fri, 19 Dec 2014 17:33:09 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1419010388!16251953!1 X-Originating-IP: [209.85.215.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28095 invoked from network); 19 Dec 2014 17:33:08 -0000 Received: from mail-la0-f51.google.com (HELO mail-la0-f51.google.com) (209.85.215.51) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 17:33:08 -0000 Received: by mail-la0-f51.google.com with SMTP id ms9so1229562lab.24 for ; Fri, 19 Dec 2014 09:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Bx44rNtyQMdKSzttjanLOJHf+JNQDTcL8k3CQr4k0e4=; b=UaqEYL4TDcoT8QDjO5dPwyFopQ5ISXAPgsFxFtYyFaRdHOadWbeoSeJ1BA3ntgqFE8 4CPQUVDGAK50YJKUjbm5i1u7wNGh0i1VtYsad0E4AhFEoA9ugpNcNPB9jiVSPD6ow1BW kChjKZnQZKy2Q9kYMlC0foOT+6BoTJFYWUY2KwdZrtXefTvQ5T5ecuy3cqZXDUVXfLCh j34d9hsYGyD2jz2pCE1kBEcF9CmIm5qcj7Fwl9+mHQ9D+0klcyYUJlcmsbzxu68ykiSN L3nEGTFou+crTomvwbjbSmGUcM3IPBmIC1500i3lYPLC/ROw5QFqhSGM880EDlMHEPUv M2pg== MIME-Version: 1.0 X-Received: by 10.112.27.133 with SMTP id t5mr8972879lbg.45.1419010387602; Fri, 19 Dec 2014 09:33:07 -0800 (PST) Received: by 10.25.207.3 with HTTP; Fri, 19 Dec 2014 09:33:07 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Dec 2014 17:33:07 +0000 Message-ID: From: Thomas Leonard To: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 17 December 2014 at 14:29, Thomas Leonard wrote: > The TLS work requires ctypes and zarith to run on Xen. I now have > ctypes building with Xen support, but zarith is more difficult. Update gmp and zarith are now working (compiling against only the Mini-OS headers) and can be used from Xen unikernels. You will need: New versions of Mini-OS and Openlibm, adding some previously-missing headers: https://github.com/mirage/mirage-xen-minios/pull/11 mirage-xen, with old (conflicting) headers removed: https://github.com/talex5/mirage-platform/tree/headers (not ready for merge as I need to check if there are more we can lose) mirage-dev repository with the new zarith and gmp packages (we might want to rename zarith to mirage-zarith or similar): opam remote add devel https://github.com/talex5/mirage-dev.git#zarith https://github.com/mirage/mirage-dev/pull/49 Updated mirage tool to fix the link order: opam pin add mirage 'https://github.com/talex5/mirage.git#xen_linkopts' https://github.com/mirage/mirage/pull/341 Now we just need to get Xen support in nocrypto, but that should be fairly straight-forward. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:34:01 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:34:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21RB-0004x1-HR; Fri, 19 Dec 2014 17:34:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21RA-0004wv-DM for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:34:00 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 0B/BA-09284-78164945; Fri, 19 Dec 2014 17:33:59 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-31.messagelabs.com!1419010438!14660108!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2914 invoked from network); 19 Dec 2014 17:33:58 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 17:33:58 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 27c16f42; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 17:39:59 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <533175116.1203435.1418984593096.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Date: Fri, 19 Dec 2014 09:33:54 -0800 Message-Id: References: <533175116.1203435.1418984593096.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> To: Ania Skorupa X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] modifying mirage types X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 19 Dec 2014, at 02:23, Ania Skorupa wrote: > > hi, > > can someone kindly help how I can modify and apply mirage types in V1 Hi Ania, You can use the OPAM pinning workflow [1] to modify mirage-types. In a nutshell: git clone git://github.com/mirage/mirage opam pin add mirage-types mirage/ opam pin add mirage mirage/ # make your changes in mirage/types/ opam update -u [1] https://opam.ocaml.org/blog/opam-1-2-pin/ Note that there are actually two OPAM packages for one repository here, which is a little unusual. The `mirage-types` package provides just the type definitions, and the `mirage` provides the command-line tool and code generator which has many more library dependencies. > and explain the difference with V1_LWT? The idea is that the core definitions in V1.ml do not introduce any library dependencies. They instead have abstract type definitions for 'buffer' or 'ipaddr'. We then refine these types in `V1_LWT` into versions that are more concrete, for instance by assigned `Cstruct.t` to `buffer`. This might seem pointless since we don't have any non-Lwt implementations, but there is ongoing work to provide an Async-based threading library. In the long term, we would therefore have a common V1.ml that is shared among V1_LWT.ml and V1_ASYNC.ml (with completely different implementations of the abstract buffer, ipaddr or other types from V1.ml). If you're thinking of adding types into V1.ml, note that they don't have to live in there at all until they are stable. For instance, we provide the HTTP type definitions in Cohttp_mirage.Server.S rather than shove them into V1.ml. Hope that's a little clearer! Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:34:01 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:34:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21RB-0004x1-HR; Fri, 19 Dec 2014 17:34:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21RA-0004wv-DM for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:34:00 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 0B/BA-09284-78164945; Fri, 19 Dec 2014 17:33:59 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-31.messagelabs.com!1419010438!14660108!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2914 invoked from network); 19 Dec 2014 17:33:58 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 17:33:58 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 27c16f42; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 17:39:59 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <533175116.1203435.1418984593096.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> Date: Fri, 19 Dec 2014 09:33:54 -0800 Message-Id: References: <533175116.1203435.1418984593096.JavaMail.yahoo@jws10646.mail.bf1.yahoo.com> To: Ania Skorupa X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] modifying mirage types X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > On 19 Dec 2014, at 02:23, Ania Skorupa wrote: > > hi, > > can someone kindly help how I can modify and apply mirage types in V1 Hi Ania, You can use the OPAM pinning workflow [1] to modify mirage-types. In a nutshell: git clone git://github.com/mirage/mirage opam pin add mirage-types mirage/ opam pin add mirage mirage/ # make your changes in mirage/types/ opam update -u [1] https://opam.ocaml.org/blog/opam-1-2-pin/ Note that there are actually two OPAM packages for one repository here, which is a little unusual. The `mirage-types` package provides just the type definitions, and the `mirage` provides the command-line tool and code generator which has many more library dependencies. > and explain the difference with V1_LWT? The idea is that the core definitions in V1.ml do not introduce any library dependencies. They instead have abstract type definitions for 'buffer' or 'ipaddr'. We then refine these types in `V1_LWT` into versions that are more concrete, for instance by assigned `Cstruct.t` to `buffer`. This might seem pointless since we don't have any non-Lwt implementations, but there is ongoing work to provide an Async-based threading library. In the long term, we would therefore have a common V1.ml that is shared among V1_LWT.ml and V1_ASYNC.ml (with completely different implementations of the abstract buffer, ipaddr or other types from V1.ml). If you're thinking of adding types into V1.ml, note that they don't have to live in there at all until they are stable. For instance, we provide the HTTP type definitions in Cohttp_mirage.Server.S rather than shove them into V1.ml. Hope that's a little clearer! Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:41:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:41:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21YC-0004zJ-50; Fri, 19 Dec 2014 17:41:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21YB-0004zE-1r for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:41:15 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 88/53-27785-A3364945; Fri, 19 Dec 2014 17:41:14 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-27.messagelabs.com!1419010873!16277348!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27537 invoked from network); 19 Dec 2014 17:41:13 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 17:41:13 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 983ed9d6; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Fri, 19 Dec 2014 17:47:15 +0000 (GMT) From: Anil Madhavapeddy Message-Id: Date: Fri, 19 Dec 2014 09:41:10 -0800 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] ocaml 4.02 support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org We need to start thinking about the best way to add OCaml 4.02.1 support. I'd particularly like OCaml 4.03 support at the same time, since there are some very cool optimisation patches being proposed: https://github.com/ocaml/ocaml/pull/132 A few options: - Just continue to copy the runtime into mirage-platform and have selection logic as we used to have for 4.01 and 4.00. This lets us apply local patches easily. - Use Thomas' new CFLAGS infrastructure to compile libasmrun from OCaml as a library just as we do everything else. I'd prefer the latter as it gets yet more code out of mirage-platform, and we can still do custom patches via a fork (as we do with openlibm). Thoughts? -anil (on the road atm, so email replies may be out of order and arbitrarily delayed :) _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 17:41:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 17:41:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21YC-0004zJ-50; Fri, 19 Dec 2014 17:41:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y21YB-0004zE-1r for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 17:41:15 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 88/53-27785-A3364945; Fri, 19 Dec 2014 17:41:14 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-27.messagelabs.com!1419010873!16277348!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27537 invoked from network); 19 Dec 2014 17:41:13 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 17:41:13 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 983ed9d6; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Fri, 19 Dec 2014 17:47:15 +0000 (GMT) From: Anil Madhavapeddy Message-Id: Date: Fri, 19 Dec 2014 09:41:10 -0800 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] ocaml 4.02 support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org We need to start thinking about the best way to add OCaml 4.02.1 support. I'd particularly like OCaml 4.03 support at the same time, since there are some very cool optimisation patches being proposed: https://github.com/ocaml/ocaml/pull/132 A few options: - Just continue to copy the runtime into mirage-platform and have selection logic as we used to have for 4.01 and 4.00. This lets us apply local patches easily. - Use Thomas' new CFLAGS infrastructure to compile libasmrun from OCaml as a library just as we do everything else. I'd prefer the latter as it gets yet more code out of mirage-platform, and we can still do custom patches via a fork (as we do with openlibm). Thoughts? -anil (on the road atm, so email replies may be out of order and arbitrarily delayed :) _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 18:49:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 18:49:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22cJ-0007R9-LJ; Fri, 19 Dec 2014 18:49:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22cH-0007R4-Rz for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 18:49:33 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id 64/AD-11608-C3374945; Fri, 19 Dec 2014 18:49:32 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1419014971!14631993!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14132 invoked from network); 19 Dec 2014 18:49:31 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 18:49:31 -0000 Received: by mail-wg0-f51.google.com with SMTP id x12so2092756wgg.10 for ; Fri, 19 Dec 2014 10:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EOW3iVTL12sMViMsC6RsUCh8cbrbt/Y4xRpYD5h2sLE=; b=yCUEGp5knAJNoeuSpiRyRRldQ6XFD7hHmvb3qA/U3W0LGkY8HpM6BRU10kpJ93tZLj R/+60N0VTaTRKa25yaXv2f/yB3yZOsLJZURsH4APx+Z9gcMSyvWL+1ORLi2IPZRDkF4i fOb1ePKfzQ0U7W+guIjB7n/RMZqPqG+jXV3mBbH1zXSe/yfiheiB87nmWV+ghUUvWm4S VRypPT8sbiSD+8U3aXT+RkWf4YSnBUfySATd0qKjdFs0w6qBep9PjLjShbPpetDqKKLZ PYw/Y7bQUf2XOEFeQSA/ZBTT9DQvhpKkoTy4O5uFuKJYui4Dn2asoo+VLFZiurUkBZy0 ThFg== X-Received: by 10.194.81.38 with SMTP id w6mr17348150wjx.17.1419014971459; Fri, 19 Dec 2014 10:49:31 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id d2sm13672275wjs.32.2014.12.19.10.49.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 10:49:30 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <0D7FB5B8-DE15-4551-B335-264452E14F07@cam.ac.uk> Date: Fri, 19 Dec 2014 18:49:28 +0000 Message-Id: <9B169147-78F9-4A1C-B6B3-A6E25AE1BF65@gazagnaire.org> References: <0D7FB5B8-DE15-4551-B335-264452E14F07@cam.ac.uk> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: Anil Madhavapeddy , mirageos-devel Subject: Re: [MirageOS-devel] Irmrn - dedup on sync X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org L2NjIG1pcmFnZW9zLWRldmVsIGFzIGl0IGNhbiBiZSBvZiBpbnRlcmVzdGVkIHRvIG90aGVycwoK SGkgR3JlZ29yeSwKCj4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgSXJtaW4gc3luY2hpbmcgYXJj aGl0ZWN0dXJlLiBTdXBwb3NlIEkgaGF2ZSB0aGUgZW1haWwgc3RydWN0dXJlIHdoZXJlIGVhY2gg bWVzc2FnZSBpcyBicm9rZW4gaW50byBNSU1FIHBhcnRzIHNvIGhlYWRlcnMsIGF0dGFjaG1lbnRz LCBib2R5LCBldGMuIHN0b3JlZCBzZXBhcmF0ZWx5LiBJIGhhdmUgdHdvIElybWluIHNlcnZlcnMg LSBwcmltYXJ5IGFuZCBiYWNrdXAuIEJvdGggcHJpbWFyeSBhbmQgYmFja3VwIGFyZSBpbiBzeW5j IGFuZCBoYXZlIGEgbWVzc2FnZSBNIHdpdGggYXR0YWNobWVudCBBLiBBIG5ldyBtZXNzYWdlIE3i gJkgd2l0aCB0aGUgc2FtZSBhdHRhY2htZW50IEEgYXJyaXZlcyB0byB0aGUgcHJpbWFyeS4gQXQg c29tZSBwb2ludCB0aGUgcHJpbWFyeSBzZXJ2ZXIgYXR0ZW1wdHMgdG8gc3luYyBpdHMgY29udGVu dCB3aXRoIHRoZSBiYWNrdXAgc2VydmVyLiBXaWxsIElybWluIGZpZ3VyZSBvdXQgdGhhdCB0aGUg YXR0YWNobWVudCBBIGRvZXNu4oCZdCBoYXZlIHRvIGJlIHNlbnQgdG8gdGhlIGJhY2t1cCBiZWNh dXNlIGl0IGFscmVhZHkgZXhpc3RzPyBDbGVhcmx5IG5vdCBzZW5kaW5nIEEgaXMgcHJlZmVycmVk IGFuZCBpbiBjYXNlIG9mIG1vYmlsZSBjbGllbnQgdHJhbnNsYXRlcyBpbnRvIHRoZSBlbmVyZ3kg c2F2aW5ncy4KCkluIEdpdCwgdGhlIHB1bGxlciBmaXJzdCBzZW5kcyB0aGUgbGlzdCBvZiBpdHMg cmVmZXJlbmNlcyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcga2V5cy4gVGhlIHJlY2VpdmVyIHRyaWVz IHRvIGNvbXB1dGUgdGhlIGV4YWN0IGRpZmYgdG8gc2VuZCBiYWNrIHRvIHRoZSBwdWxsZXI6IGl0 IHVzZXMgc29tZSBoZXVyaXN0aWMgb24gdGhlIGdyYXBoIG9mIGtleXMgdG8gZG8gc28sIGFuZCB0 aGVuIGNvbXByZXNzIHRoZSBjb3JyZXNwb25kaW5nIGNvbnRlbnRzIChpLmUuLCBmb3IgZWFjaCBt aXNzaW5nIGtleSwgaXQgZ2V0cyB0aGUgY29udGVudHMsIGFuZCB0aGVuIGNvbXByZXNzIGFsbCB0 aGUgbmV3IGNvbnRlbnRzIHRvZ2V0aGVyKS4gSXQgdGhlbiBzZW5kcyB0aGUgcGFjayBvZiBjb250 ZW50cyB0byB0aGUgcHVsbGVyLiBOb3RlIHRoYXQgdGhleSBrZXlzIGhlcmUgYXJlIHRoZSBjb250 ZW50cycgZGlnZXN0LCBzbyBzaW1pbGFyIGNvbnRlbnRzIGFyZSBzZW50IG9ubHkgb25jZSBhbmQg b25seSBpZiBuZWNlc3NhcnksIGFsdGhvdWdoIHRoZSBoZXVyaXN0aWMgY2FuIHNvbWV0aW1lcyBn byB3cm9uZy4gSW4gSXJtaW4sIHlvdSBjYW4gdXNlIHRoYXQgbW9kZSBvZiBzeW5jaHJvbmlzYXRp b24gdXNpbmcgYElybWluLnJlbW90ZV91cmlgWzFdLgoKSXJtaW4gaGFzIGFsc28gYSBjdXN0b20g c3luY2hyb25pc2F0aW9uIHByb3RvY29sIHdoaWNoIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgR2l0 IG9uZSBidXQgZG9lc24ndCBkbyBjb250ZW50cyBjb21wcmVzc2lvbiAoc28gbGVzcyBlZmZpY2ll bnQgYnV0IG1vcmUgcG9ydGFibGUgYWNyb3NzIHZhcmlvdXMgYmFja2VuZHMpLiBUaGlzIGlzIGBJ cm1pbi5yZW1vdGVfc3RvcmVgWzJdCgo+IElzIHRoZXJlIGEgdHV0b3JpYWwgYnkgYW55IGNoYW5j ZSB0aGF0IGRlc2NyaWJlcyBob3cgdG8gc2V0IHVwIHR3byBzZXJ2ZXJzIHRoYXQgc3luYyB0byBl YWNoIG90aGVyPwoKSSd2ZSBwdXNoZWQgYSBzaW1wbGUgZXhhbXBsZSB0byB0aGUgcmVwb1szXS4g VW5mb3J0dW5hdGVseSB3aGlsZSBkb2luZyBzbyBJIGRpc2NvdmVyZWQgdHdvIG5ldyBidWdzIGlu IG15IGltcGxlbWVudGF0aW9uIG9mIHRoZSBHaXQgcHJvdG9jb2wgLi4uCgpIb3BlIGl0IGhlbHBz LApUaG9tYXMKClsxXSBodHRwOi8vc2Ftb2h0LmdpdGh1Yi5pby9pcm1pbi9Jcm1pbi5odG1sI1ZB THJlbW90ZV91cmkgZm9yICgxKQpbMl0gaHR0cDovL3NhbW9odC5naXRodWIuaW8vaXJtaW4vSXJt aW4uaHRtbCNWQUxyZW1vdGVfc3RvcmUKWzNdIGh0dHBzOi8vZ2l0aHViLmNvbS9zYW1vaHQvaXJt aW4vYmxvYi9tYXN0ZXIvZXhhbXBsZXMvc3luYy5tbApbNF0gaHR0cHM6Ly9naXRodWIuY29tL21p cmFnZS9vY2FtbC1naXQvaXNzdWVzLzM4Cls1XSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL29j YW1sLWdpdC9pc3N1ZXMvMzkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlz dHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFp bG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 18:49:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 18:49:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22cJ-0007R9-LJ; Fri, 19 Dec 2014 18:49:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22cH-0007R4-Rz for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 18:49:33 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id 64/AD-11608-C3374945; Fri, 19 Dec 2014 18:49:32 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1419014971!14631993!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14132 invoked from network); 19 Dec 2014 18:49:31 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 18:49:31 -0000 Received: by mail-wg0-f51.google.com with SMTP id x12so2092756wgg.10 for ; Fri, 19 Dec 2014 10:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EOW3iVTL12sMViMsC6RsUCh8cbrbt/Y4xRpYD5h2sLE=; b=yCUEGp5knAJNoeuSpiRyRRldQ6XFD7hHmvb3qA/U3W0LGkY8HpM6BRU10kpJ93tZLj R/+60N0VTaTRKa25yaXv2f/yB3yZOsLJZURsH4APx+Z9gcMSyvWL+1ORLi2IPZRDkF4i fOb1ePKfzQ0U7W+guIjB7n/RMZqPqG+jXV3mBbH1zXSe/yfiheiB87nmWV+ghUUvWm4S VRypPT8sbiSD+8U3aXT+RkWf4YSnBUfySATd0qKjdFs0w6qBep9PjLjShbPpetDqKKLZ PYw/Y7bQUf2XOEFeQSA/ZBTT9DQvhpKkoTy4O5uFuKJYui4Dn2asoo+VLFZiurUkBZy0 ThFg== X-Received: by 10.194.81.38 with SMTP id w6mr17348150wjx.17.1419014971459; Fri, 19 Dec 2014 10:49:31 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id d2sm13672275wjs.32.2014.12.19.10.49.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 10:49:30 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <0D7FB5B8-DE15-4551-B335-264452E14F07@cam.ac.uk> Date: Fri, 19 Dec 2014 18:49:28 +0000 Message-Id: <9B169147-78F9-4A1C-B6B3-A6E25AE1BF65@gazagnaire.org> References: <0D7FB5B8-DE15-4551-B335-264452E14F07@cam.ac.uk> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: Anil Madhavapeddy , mirageos-devel Subject: Re: [MirageOS-devel] Irmrn - dedup on sync X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org L2NjIG1pcmFnZW9zLWRldmVsIGFzIGl0IGNhbiBiZSBvZiBpbnRlcmVzdGVkIHRvIG90aGVycwoK SGkgR3JlZ29yeSwKCj4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgSXJtaW4gc3luY2hpbmcgYXJj aGl0ZWN0dXJlLiBTdXBwb3NlIEkgaGF2ZSB0aGUgZW1haWwgc3RydWN0dXJlIHdoZXJlIGVhY2gg bWVzc2FnZSBpcyBicm9rZW4gaW50byBNSU1FIHBhcnRzIHNvIGhlYWRlcnMsIGF0dGFjaG1lbnRz LCBib2R5LCBldGMuIHN0b3JlZCBzZXBhcmF0ZWx5LiBJIGhhdmUgdHdvIElybWluIHNlcnZlcnMg LSBwcmltYXJ5IGFuZCBiYWNrdXAuIEJvdGggcHJpbWFyeSBhbmQgYmFja3VwIGFyZSBpbiBzeW5j IGFuZCBoYXZlIGEgbWVzc2FnZSBNIHdpdGggYXR0YWNobWVudCBBLiBBIG5ldyBtZXNzYWdlIE3i gJkgd2l0aCB0aGUgc2FtZSBhdHRhY2htZW50IEEgYXJyaXZlcyB0byB0aGUgcHJpbWFyeS4gQXQg c29tZSBwb2ludCB0aGUgcHJpbWFyeSBzZXJ2ZXIgYXR0ZW1wdHMgdG8gc3luYyBpdHMgY29udGVu dCB3aXRoIHRoZSBiYWNrdXAgc2VydmVyLiBXaWxsIElybWluIGZpZ3VyZSBvdXQgdGhhdCB0aGUg YXR0YWNobWVudCBBIGRvZXNu4oCZdCBoYXZlIHRvIGJlIHNlbnQgdG8gdGhlIGJhY2t1cCBiZWNh dXNlIGl0IGFscmVhZHkgZXhpc3RzPyBDbGVhcmx5IG5vdCBzZW5kaW5nIEEgaXMgcHJlZmVycmVk IGFuZCBpbiBjYXNlIG9mIG1vYmlsZSBjbGllbnQgdHJhbnNsYXRlcyBpbnRvIHRoZSBlbmVyZ3kg c2F2aW5ncy4KCkluIEdpdCwgdGhlIHB1bGxlciBmaXJzdCBzZW5kcyB0aGUgbGlzdCBvZiBpdHMg cmVmZXJlbmNlcyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcga2V5cy4gVGhlIHJlY2VpdmVyIHRyaWVz IHRvIGNvbXB1dGUgdGhlIGV4YWN0IGRpZmYgdG8gc2VuZCBiYWNrIHRvIHRoZSBwdWxsZXI6IGl0 IHVzZXMgc29tZSBoZXVyaXN0aWMgb24gdGhlIGdyYXBoIG9mIGtleXMgdG8gZG8gc28sIGFuZCB0 aGVuIGNvbXByZXNzIHRoZSBjb3JyZXNwb25kaW5nIGNvbnRlbnRzIChpLmUuLCBmb3IgZWFjaCBt aXNzaW5nIGtleSwgaXQgZ2V0cyB0aGUgY29udGVudHMsIGFuZCB0aGVuIGNvbXByZXNzIGFsbCB0 aGUgbmV3IGNvbnRlbnRzIHRvZ2V0aGVyKS4gSXQgdGhlbiBzZW5kcyB0aGUgcGFjayBvZiBjb250 ZW50cyB0byB0aGUgcHVsbGVyLiBOb3RlIHRoYXQgdGhleSBrZXlzIGhlcmUgYXJlIHRoZSBjb250 ZW50cycgZGlnZXN0LCBzbyBzaW1pbGFyIGNvbnRlbnRzIGFyZSBzZW50IG9ubHkgb25jZSBhbmQg b25seSBpZiBuZWNlc3NhcnksIGFsdGhvdWdoIHRoZSBoZXVyaXN0aWMgY2FuIHNvbWV0aW1lcyBn byB3cm9uZy4gSW4gSXJtaW4sIHlvdSBjYW4gdXNlIHRoYXQgbW9kZSBvZiBzeW5jaHJvbmlzYXRp b24gdXNpbmcgYElybWluLnJlbW90ZV91cmlgWzFdLgoKSXJtaW4gaGFzIGFsc28gYSBjdXN0b20g c3luY2hyb25pc2F0aW9uIHByb3RvY29sIHdoaWNoIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgR2l0 IG9uZSBidXQgZG9lc24ndCBkbyBjb250ZW50cyBjb21wcmVzc2lvbiAoc28gbGVzcyBlZmZpY2ll bnQgYnV0IG1vcmUgcG9ydGFibGUgYWNyb3NzIHZhcmlvdXMgYmFja2VuZHMpLiBUaGlzIGlzIGBJ cm1pbi5yZW1vdGVfc3RvcmVgWzJdCgo+IElzIHRoZXJlIGEgdHV0b3JpYWwgYnkgYW55IGNoYW5j ZSB0aGF0IGRlc2NyaWJlcyBob3cgdG8gc2V0IHVwIHR3byBzZXJ2ZXJzIHRoYXQgc3luYyB0byBl YWNoIG90aGVyPwoKSSd2ZSBwdXNoZWQgYSBzaW1wbGUgZXhhbXBsZSB0byB0aGUgcmVwb1szXS4g VW5mb3J0dW5hdGVseSB3aGlsZSBkb2luZyBzbyBJIGRpc2NvdmVyZWQgdHdvIG5ldyBidWdzIGlu IG15IGltcGxlbWVudGF0aW9uIG9mIHRoZSBHaXQgcHJvdG9jb2wgLi4uCgpIb3BlIGl0IGhlbHBz LApUaG9tYXMKClsxXSBodHRwOi8vc2Ftb2h0LmdpdGh1Yi5pby9pcm1pbi9Jcm1pbi5odG1sI1ZB THJlbW90ZV91cmkgZm9yICgxKQpbMl0gaHR0cDovL3NhbW9odC5naXRodWIuaW8vaXJtaW4vSXJt aW4uaHRtbCNWQUxyZW1vdGVfc3RvcmUKWzNdIGh0dHBzOi8vZ2l0aHViLmNvbS9zYW1vaHQvaXJt aW4vYmxvYi9tYXN0ZXIvZXhhbXBsZXMvc3luYy5tbApbNF0gaHR0cHM6Ly9naXRodWIuY29tL21p cmFnZS9vY2FtbC1naXQvaXNzdWVzLzM4Cls1XSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL29j YW1sLWdpdC9pc3N1ZXMvMzkKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2ZWxAbGlz dHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFp bG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 18:57:08 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 18:57:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22jc-0007lu-9W; Fri, 19 Dec 2014 18:57:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22ja-0007lm-SH for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 18:57:06 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 22/84-22737-20574945; Fri, 19 Dec 2014 18:57:06 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-6.tower-206.messagelabs.com!1419015425!14399726!1 X-Originating-IP: [131.111.8.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27576 invoked from network); 19 Dec 2014 18:57:05 -0000 Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk) (131.111.8.152) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 18:57:05 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:65021 helo=[192.168.0.7]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y22jY-0003Nt-FX (Exim 4.82_3-c0e5623) (return-path ); Fri, 19 Dec 2014 18:57:04 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <9B169147-78F9-4A1C-B6B3-A6E25AE1BF65@gazagnaire.org> Date: Fri, 19 Dec 2014 13:57:03 -0500 Message-Id: <5F8A011A-B167-4A40-9789-74BBC2EDF891@cam.ac.uk> References: <0D7FB5B8-DE15-4551-B335-264452E14F07@cam.ac.uk> <9B169147-78F9-4A1C-B6B3-A6E25AE1BF65@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: Anil Madhavapeddy , mirageos-devel Subject: Re: [MirageOS-devel] Irmrn - dedup on sync X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgVGhvbWFzLAoKVGhhbmtzLiBUaGlzIGhlbHBzIGluZGVlZCEKCkdyZWdvcnkKCj4gT24gRGVj IDE5LCAyMDE0LCBhdCAxOjQ5IFBNLCBUaG9tYXMgR2F6YWduYWlyZSA8dGhvbWFzQGdhemFnbmFp cmUub3JnPiB3cm90ZToKPiAKPiAvY2MgbWlyYWdlb3MtZGV2ZWwgYXMgaXQgY2FuIGJlIG9mIGlu dGVyZXN0ZWQgdG8gb3RoZXJzCj4gCj4gSGkgR3JlZ29yeSwKPiAKPj4gSSBoYXZlIGEgcXVlc3Rp b24gYWJvdXQgSXJtaW4gc3luY2hpbmcgYXJjaGl0ZWN0dXJlLiBTdXBwb3NlIEkgaGF2ZSB0aGUg ZW1haWwgc3RydWN0dXJlIHdoZXJlIGVhY2ggbWVzc2FnZSBpcyBicm9rZW4gaW50byBNSU1FIHBh cnRzIHNvIGhlYWRlcnMsIGF0dGFjaG1lbnRzLCBib2R5LCBldGMuIHN0b3JlZCBzZXBhcmF0ZWx5 LiBJIGhhdmUgdHdvIElybWluIHNlcnZlcnMgLSBwcmltYXJ5IGFuZCBiYWNrdXAuIEJvdGggcHJp bWFyeSBhbmQgYmFja3VwIGFyZSBpbiBzeW5jIGFuZCBoYXZlIGEgbWVzc2FnZSBNIHdpdGggYXR0 YWNobWVudCBBLiBBIG5ldyBtZXNzYWdlIE3igJkgd2l0aCB0aGUgc2FtZSBhdHRhY2htZW50IEEg YXJyaXZlcyB0byB0aGUgcHJpbWFyeS4gQXQgc29tZSBwb2ludCB0aGUgcHJpbWFyeSBzZXJ2ZXIg YXR0ZW1wdHMgdG8gc3luYyBpdHMgY29udGVudCB3aXRoIHRoZSBiYWNrdXAgc2VydmVyLiBXaWxs IElybWluIGZpZ3VyZSBvdXQgdGhhdCB0aGUgYXR0YWNobWVudCBBIGRvZXNu4oCZdCBoYXZlIHRv IGJlIHNlbnQgdG8gdGhlIGJhY2t1cCBiZWNhdXNlIGl0IGFscmVhZHkgZXhpc3RzPyBDbGVhcmx5 IG5vdCBzZW5kaW5nIEEgaXMgcHJlZmVycmVkIGFuZCBpbiBjYXNlIG9mIG1vYmlsZSBjbGllbnQg dHJhbnNsYXRlcyBpbnRvIHRoZSBlbmVyZ3kgc2F2aW5ncy4KPiAKPiBJbiBHaXQsIHRoZSBwdWxs ZXIgZmlyc3Qgc2VuZHMgdGhlIGxpc3Qgb2YgaXRzIHJlZmVyZW5jZXMgYW5kIHRoZSBjb3JyZXNw b25kaW5nIGtleXMuIFRoZSByZWNlaXZlciB0cmllcyB0byBjb21wdXRlIHRoZSBleGFjdCBkaWZm IHRvIHNlbmQgYmFjayB0byB0aGUgcHVsbGVyOiBpdCB1c2VzIHNvbWUgaGV1cmlzdGljIG9uIHRo ZSBncmFwaCBvZiBrZXlzIHRvIGRvIHNvLCBhbmQgdGhlbiBjb21wcmVzcyB0aGUgY29ycmVzcG9u ZGluZyBjb250ZW50cyAoaS5lLiwgZm9yIGVhY2ggbWlzc2luZyBrZXksIGl0IGdldHMgdGhlIGNv bnRlbnRzLCBhbmQgdGhlbiBjb21wcmVzcyBhbGwgdGhlIG5ldyBjb250ZW50cyB0b2dldGhlciku IEl0IHRoZW4gc2VuZHMgdGhlIHBhY2sgb2YgY29udGVudHMgdG8gdGhlIHB1bGxlci4gTm90ZSB0 aGF0IHRoZXkga2V5cyBoZXJlIGFyZSB0aGUgY29udGVudHMnIGRpZ2VzdCwgc28gc2ltaWxhciBj b250ZW50cyBhcmUgc2VudCBvbmx5IG9uY2UgYW5kIG9ubHkgaWYgbmVjZXNzYXJ5LCBhbHRob3Vn aCB0aGUgaGV1cmlzdGljIGNhbiBzb21ldGltZXMgZ28gd3JvbmcuIEluIElybWluLCB5b3UgY2Fu IHVzZSB0aGF0IG1vZGUgb2Ygc3luY2hyb25pc2F0aW9uIHVzaW5nIGBJcm1pbi5yZW1vdGVfdXJp YFsxXS4KPiAKPiBJcm1pbiBoYXMgYWxzbyBhIGN1c3RvbSBzeW5jaHJvbmlzYXRpb24gcHJvdG9j b2wgd2hpY2ggaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBHaXQgb25lIGJ1dCBkb2Vzbid0IGRvIGNv bnRlbnRzIGNvbXByZXNzaW9uIChzbyBsZXNzIGVmZmljaWVudCBidXQgbW9yZSBwb3J0YWJsZSBh Y3Jvc3MgdmFyaW91cyBiYWNrZW5kcykuIFRoaXMgaXMgYElybWluLnJlbW90ZV9zdG9yZWBbMl0K PiAKPj4gSXMgdGhlcmUgYSB0dXRvcmlhbCBieSBhbnkgY2hhbmNlIHRoYXQgZGVzY3JpYmVzIGhv dyB0byBzZXQgdXAgdHdvIHNlcnZlcnMgdGhhdCBzeW5jIHRvIGVhY2ggb3RoZXI/Cj4gCj4gSSd2 ZSBwdXNoZWQgYSBzaW1wbGUgZXhhbXBsZSB0byB0aGUgcmVwb1szXS4gVW5mb3J0dW5hdGVseSB3 aGlsZSBkb2luZyBzbyBJIGRpc2NvdmVyZWQgdHdvIG5ldyBidWdzIGluIG15IGltcGxlbWVudGF0 aW9uIG9mIHRoZSBHaXQgcHJvdG9jb2wgLi4uCj4gCj4gSG9wZSBpdCBoZWxwcywKPiBUaG9tYXMK PiAKPiBbMV0gaHR0cDovL3NhbW9odC5naXRodWIuaW8vaXJtaW4vSXJtaW4uaHRtbCNWQUxyZW1v dGVfdXJpIGZvciAoMSkKPiBbMl0gaHR0cDovL3NhbW9odC5naXRodWIuaW8vaXJtaW4vSXJtaW4u aHRtbCNWQUxyZW1vdGVfc3RvcmUKPiBbM10gaHR0cHM6Ly9naXRodWIuY29tL3NhbW9odC9pcm1p bi9ibG9iL21hc3Rlci9leGFtcGxlcy9zeW5jLm1sCj4gWzRdIGh0dHBzOi8vZ2l0aHViLmNvbS9t aXJhZ2Uvb2NhbWwtZ2l0L2lzc3Vlcy8zOAo+IFs1XSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdl L29jYW1sLWdpdC9pc3N1ZXMvMzkKPiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2 ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1i aW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 18:57:08 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 18:57:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22jc-0007lu-9W; Fri, 19 Dec 2014 18:57:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y22ja-0007lm-SH for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 18:57:06 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 22/84-22737-20574945; Fri, 19 Dec 2014 18:57:06 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-6.tower-206.messagelabs.com!1419015425!14399726!1 X-Originating-IP: [131.111.8.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27576 invoked from network); 19 Dec 2014 18:57:05 -0000 Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk) (131.111.8.152) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 18:57:05 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:65021 helo=[192.168.0.7]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y22jY-0003Nt-FX (Exim 4.82_3-c0e5623) (return-path ); Fri, 19 Dec 2014 18:57:04 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <9B169147-78F9-4A1C-B6B3-A6E25AE1BF65@gazagnaire.org> Date: Fri, 19 Dec 2014 13:57:03 -0500 Message-Id: <5F8A011A-B167-4A40-9789-74BBC2EDF891@cam.ac.uk> References: <0D7FB5B8-DE15-4551-B335-264452E14F07@cam.ac.uk> <9B169147-78F9-4A1C-B6B3-A6E25AE1BF65@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: Anil Madhavapeddy , mirageos-devel Subject: Re: [MirageOS-devel] Irmrn - dedup on sync X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgVGhvbWFzLAoKVGhhbmtzLiBUaGlzIGhlbHBzIGluZGVlZCEKCkdyZWdvcnkKCj4gT24gRGVj IDE5LCAyMDE0LCBhdCAxOjQ5IFBNLCBUaG9tYXMgR2F6YWduYWlyZSA8dGhvbWFzQGdhemFnbmFp cmUub3JnPiB3cm90ZToKPiAKPiAvY2MgbWlyYWdlb3MtZGV2ZWwgYXMgaXQgY2FuIGJlIG9mIGlu dGVyZXN0ZWQgdG8gb3RoZXJzCj4gCj4gSGkgR3JlZ29yeSwKPiAKPj4gSSBoYXZlIGEgcXVlc3Rp b24gYWJvdXQgSXJtaW4gc3luY2hpbmcgYXJjaGl0ZWN0dXJlLiBTdXBwb3NlIEkgaGF2ZSB0aGUg ZW1haWwgc3RydWN0dXJlIHdoZXJlIGVhY2ggbWVzc2FnZSBpcyBicm9rZW4gaW50byBNSU1FIHBh cnRzIHNvIGhlYWRlcnMsIGF0dGFjaG1lbnRzLCBib2R5LCBldGMuIHN0b3JlZCBzZXBhcmF0ZWx5 LiBJIGhhdmUgdHdvIElybWluIHNlcnZlcnMgLSBwcmltYXJ5IGFuZCBiYWNrdXAuIEJvdGggcHJp bWFyeSBhbmQgYmFja3VwIGFyZSBpbiBzeW5jIGFuZCBoYXZlIGEgbWVzc2FnZSBNIHdpdGggYXR0 YWNobWVudCBBLiBBIG5ldyBtZXNzYWdlIE3igJkgd2l0aCB0aGUgc2FtZSBhdHRhY2htZW50IEEg YXJyaXZlcyB0byB0aGUgcHJpbWFyeS4gQXQgc29tZSBwb2ludCB0aGUgcHJpbWFyeSBzZXJ2ZXIg YXR0ZW1wdHMgdG8gc3luYyBpdHMgY29udGVudCB3aXRoIHRoZSBiYWNrdXAgc2VydmVyLiBXaWxs IElybWluIGZpZ3VyZSBvdXQgdGhhdCB0aGUgYXR0YWNobWVudCBBIGRvZXNu4oCZdCBoYXZlIHRv IGJlIHNlbnQgdG8gdGhlIGJhY2t1cCBiZWNhdXNlIGl0IGFscmVhZHkgZXhpc3RzPyBDbGVhcmx5 IG5vdCBzZW5kaW5nIEEgaXMgcHJlZmVycmVkIGFuZCBpbiBjYXNlIG9mIG1vYmlsZSBjbGllbnQg dHJhbnNsYXRlcyBpbnRvIHRoZSBlbmVyZ3kgc2F2aW5ncy4KPiAKPiBJbiBHaXQsIHRoZSBwdWxs ZXIgZmlyc3Qgc2VuZHMgdGhlIGxpc3Qgb2YgaXRzIHJlZmVyZW5jZXMgYW5kIHRoZSBjb3JyZXNw b25kaW5nIGtleXMuIFRoZSByZWNlaXZlciB0cmllcyB0byBjb21wdXRlIHRoZSBleGFjdCBkaWZm IHRvIHNlbmQgYmFjayB0byB0aGUgcHVsbGVyOiBpdCB1c2VzIHNvbWUgaGV1cmlzdGljIG9uIHRo ZSBncmFwaCBvZiBrZXlzIHRvIGRvIHNvLCBhbmQgdGhlbiBjb21wcmVzcyB0aGUgY29ycmVzcG9u ZGluZyBjb250ZW50cyAoaS5lLiwgZm9yIGVhY2ggbWlzc2luZyBrZXksIGl0IGdldHMgdGhlIGNv bnRlbnRzLCBhbmQgdGhlbiBjb21wcmVzcyBhbGwgdGhlIG5ldyBjb250ZW50cyB0b2dldGhlciku IEl0IHRoZW4gc2VuZHMgdGhlIHBhY2sgb2YgY29udGVudHMgdG8gdGhlIHB1bGxlci4gTm90ZSB0 aGF0IHRoZXkga2V5cyBoZXJlIGFyZSB0aGUgY29udGVudHMnIGRpZ2VzdCwgc28gc2ltaWxhciBj b250ZW50cyBhcmUgc2VudCBvbmx5IG9uY2UgYW5kIG9ubHkgaWYgbmVjZXNzYXJ5LCBhbHRob3Vn aCB0aGUgaGV1cmlzdGljIGNhbiBzb21ldGltZXMgZ28gd3JvbmcuIEluIElybWluLCB5b3UgY2Fu IHVzZSB0aGF0IG1vZGUgb2Ygc3luY2hyb25pc2F0aW9uIHVzaW5nIGBJcm1pbi5yZW1vdGVfdXJp YFsxXS4KPiAKPiBJcm1pbiBoYXMgYWxzbyBhIGN1c3RvbSBzeW5jaHJvbmlzYXRpb24gcHJvdG9j b2wgd2hpY2ggaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBHaXQgb25lIGJ1dCBkb2Vzbid0IGRvIGNv bnRlbnRzIGNvbXByZXNzaW9uIChzbyBsZXNzIGVmZmljaWVudCBidXQgbW9yZSBwb3J0YWJsZSBh Y3Jvc3MgdmFyaW91cyBiYWNrZW5kcykuIFRoaXMgaXMgYElybWluLnJlbW90ZV9zdG9yZWBbMl0K PiAKPj4gSXMgdGhlcmUgYSB0dXRvcmlhbCBieSBhbnkgY2hhbmNlIHRoYXQgZGVzY3JpYmVzIGhv dyB0byBzZXQgdXAgdHdvIHNlcnZlcnMgdGhhdCBzeW5jIHRvIGVhY2ggb3RoZXI/Cj4gCj4gSSd2 ZSBwdXNoZWQgYSBzaW1wbGUgZXhhbXBsZSB0byB0aGUgcmVwb1szXS4gVW5mb3J0dW5hdGVseSB3 aGlsZSBkb2luZyBzbyBJIGRpc2NvdmVyZWQgdHdvIG5ldyBidWdzIGluIG15IGltcGxlbWVudGF0 aW9uIG9mIHRoZSBHaXQgcHJvdG9jb2wgLi4uCj4gCj4gSG9wZSBpdCBoZWxwcywKPiBUaG9tYXMK PiAKPiBbMV0gaHR0cDovL3NhbW9odC5naXRodWIuaW8vaXJtaW4vSXJtaW4uaHRtbCNWQUxyZW1v dGVfdXJpIGZvciAoMSkKPiBbMl0gaHR0cDovL3NhbW9odC5naXRodWIuaW8vaXJtaW4vSXJtaW4u aHRtbCNWQUxyZW1vdGVfc3RvcmUKPiBbM10gaHR0cHM6Ly9naXRodWIuY29tL3NhbW9odC9pcm1p bi9ibG9iL21hc3Rlci9leGFtcGxlcy9zeW5jLm1sCj4gWzRdIGh0dHBzOi8vZ2l0aHViLmNvbS9t aXJhZ2Uvb2NhbWwtZ2l0L2lzc3Vlcy8zOAo+IFs1XSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdl L29jYW1sLWdpdC9pc3N1ZXMvMzkKPiAKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWlyYWdlT1MtZGV2 ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1i aW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 19:41:10 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 19:41:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y23QC-0001Kt-56; Fri, 19 Dec 2014 19:41:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y23QA-0001Kl-Vf for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:41:07 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 77/89-14214-25F74945; Fri, 19 Dec 2014 19:41:06 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1419018065!14391585!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21895 invoked from network); 19 Dec 2014 19:41:05 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 19:41:05 -0000 Received: by mail-wi0-f178.google.com with SMTP id em10so2856322wid.5 for ; Fri, 19 Dec 2014 11:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=V1KS0JDp5sJ4wndjxQvEump8yVjQqeVBfU0Ai23lXPA=; b=yjbmpgohsMvXP3EUzcck6iFoTEOmXS1CdNgOVmSoF+4RWdjQlBg6UhPXgPVKipSM1y TUsn9eAg60S+kx5zjjZy+cXziySFmjGBY7xL+hMR1Uee78qnf4icgblzMJvVu9k9Qo8d 2+Iq9NCO8ign4Co8cHgm47NFxkhIyEzCsqv8pxX0OBeCglFjns1UMPkZP1tW9s8Gfiet nSI9KhVy2zkiUoApMXaKTIE6YQkAOEGnKFJPE9NReR15RzLemrlP342AOo1l4d9E6kqc jFpUzKh6+jPXO39ubQphhOOxJRzeFTcTkqke3LltdD7Z98P6OwpDV/mvzypvFIv5FN3R 8zIQ== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr8878975wic.57.1419018065164; Fri, 19 Dec 2014 11:41:05 -0800 (PST) Received: by 10.27.45.205 with HTTP; Fri, 19 Dec 2014 11:41:05 -0800 (PST) Date: Fri, 19 Dec 2014 16:41:05 -0300 X-Google-Sender-Auth: AYqb1eRrpqB34f7ttSzTz1xUoFI Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi list, I have a unikernel that uses the `uint` package (which is implemented in C). I can compile and run fine on Unix, but when compiling for Xen I get linking errors because the uint C stubs are not getting linked to the unikernel... It would be great if someone could explain what is involved in getting C stubs linked to Xen unikernels, whether it is a reasonable thing to do, the standard way to do it, etc... Thanks! Best wishes, Nicolas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 19:41:10 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 19:41:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y23QC-0001Kt-56; Fri, 19 Dec 2014 19:41:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y23QA-0001Kl-Vf for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 19:41:07 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 77/89-14214-25F74945; Fri, 19 Dec 2014 19:41:06 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1419018065!14391585!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21895 invoked from network); 19 Dec 2014 19:41:05 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 19:41:05 -0000 Received: by mail-wi0-f178.google.com with SMTP id em10so2856322wid.5 for ; Fri, 19 Dec 2014 11:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=V1KS0JDp5sJ4wndjxQvEump8yVjQqeVBfU0Ai23lXPA=; b=yjbmpgohsMvXP3EUzcck6iFoTEOmXS1CdNgOVmSoF+4RWdjQlBg6UhPXgPVKipSM1y TUsn9eAg60S+kx5zjjZy+cXziySFmjGBY7xL+hMR1Uee78qnf4icgblzMJvVu9k9Qo8d 2+Iq9NCO8ign4Co8cHgm47NFxkhIyEzCsqv8pxX0OBeCglFjns1UMPkZP1tW9s8Gfiet nSI9KhVy2zkiUoApMXaKTIE6YQkAOEGnKFJPE9NReR15RzLemrlP342AOo1l4d9E6kqc jFpUzKh6+jPXO39ubQphhOOxJRzeFTcTkqke3LltdD7Z98P6OwpDV/mvzypvFIv5FN3R 8zIQ== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr8878975wic.57.1419018065164; Fri, 19 Dec 2014 11:41:05 -0800 (PST) Received: by 10.27.45.205 with HTTP; Fri, 19 Dec 2014 11:41:05 -0800 (PST) Date: Fri, 19 Dec 2014 16:41:05 -0300 X-Google-Sender-Auth: AYqb1eRrpqB34f7ttSzTz1xUoFI Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi list, I have a unikernel that uses the `uint` package (which is implemented in C). I can compile and run fine on Unix, but when compiling for Xen I get linking errors because the uint C stubs are not getting linked to the unikernel... It would be great if someone could explain what is involved in getting C stubs linked to Xen unikernels, whether it is a reasonable thing to do, the standard way to do it, etc... Thanks! Best wishes, Nicolas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 20:36:30 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 20:36:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24Hf-000440-Dr; Fri, 19 Dec 2014 20:36:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24Hd-00043v-Ve for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 20:36:22 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id BF/64-02957-54C84945; Fri, 19 Dec 2014 20:36:21 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1419021378!10839445!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15137 invoked from network); 19 Dec 2014 20:36:18 -0000 Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 20:36:18 -0000 Received: by mail-wg0-f44.google.com with SMTP id b13so2293637wgh.3 for ; Fri, 19 Dec 2014 12:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TmokJcsw3fqx4iBBL3oNdvIRGwwVoBnmtdRmUZ5CFm0=; b=Wdn4Gi26q6bsBYFAX68kHNg5vwzOc2jGYURP9RJ9AoNzoKC42vVEhurxs7TqBdR8hb 1Ov7CyTvM1p/2VAPHI0LWAn+ziBUVO07wuGif5dVQhy7hsFK33ttZ2zdLL8P+J3rkWGy yUlWZK1kP90/uYqaoFTY3IJJp43x+6jnC+zK3PF2AXBoRgTgmCXUWem9yn/7etKcHQ4y aTSe4cKVYRzZemvOwffuBjOMGhG8dDSwB/OCxzoXNRT2mWwdmvDmY49/T4tnT3LsKMKy Bp+wTGnvGtdMh41WhJsaCRgiuIbU22rM57rU6SYBf1LsTBXiPeWtbM1MYFas3R5ItFKI dAgA== X-Received: by 10.194.71.45 with SMTP id r13mr17680409wju.128.1419021378328; Fri, 19 Dec 2014 12:36:18 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id pl1sm3588803wic.16.2014.12.19.12.36.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 12:36:17 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Fri, 19 Dec 2014 20:36:15 +0000 Message-Id: <548B6002-539D-4BEB-B2EF-7DB28EBDD3E7@gazagnaire.org> References: To: Brian Brietzke X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2934931030278134187==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2934931030278134187== Content-Type: multipart/alternative; boundary="Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE" --Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I really think you are doing things in the wrong order. The way I see = the process: 1. Write some normal OCaml code on Unix, we test and debug it with the = normal Unix tools. 2. Abstract the system dependencies as parameters of the functor. = Usually everything related to input/output. It's better to keep that in = mind while doing 1. though, otherwise it can causes some pain. Now you = know what module type you need to depend on. 3. Take an existing example in mirage-skeleton and modify the body of = unikernel.ml to call your code. Now you know what shape the generated = will have. 4. create the new impl in mirage.ml to make it more easily configurable. = Use knowledge you gathered from 2. and 3. to do so. Doing things in reverse order won't work very well :-) Thomas Once again I would advise=20 > On 19 Dec 2014, at 20:23, Brian Brietzke wrote: >=20 > Thanks Luke. I kept looking at impl as most of the other code in = mirage.ml seemed to be using that. I switched it = over to implementation and solved at least part of the problem. On the = other hand, the KV_RO constructor was done out of frustration and = experimentation. There will be constructor options ( host, port, etc ) = but it shouldn't be another KV_RO. >=20 > Thomas, I have a basic working ( well compilable ) implementation up = now. The size and read functions just return errors based on the name = parameter, but that is enough to get some basics. I'll expand it out = further as things progress. >=20 > I'm assuming the 'Symbol not found: _camlRediskv error' is part of the = referring module issue listed above? Can I create a different folder, = use oasis to create a new library project and just 'opam pin' to = handling the non-module referring? >=20 > On Fri, Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire = > wrote: > Hi, >=20 > First, thanks for your effort! >=20 >> So I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml > No it doen't (yet), but we had some ideas to make it work (see = http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00078.= html = ) >=20 >> What I would like to start off with is a new implementation of the = KV_RO module but using Redis instead of crunch or the file system. =20 >>=20 >> I think I need three things: one is the actual implementation module = that implements the KV_RO interface / module, one module that provides = the packages and libraries you need ( the Impl module? ) and then = another for tie those together. >=20 > This is indeed what is needed to have a fully supported backend. = Before that, I think the first step (the harder one) is to get your = implementation working on Linux. Just write complete = https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = = to make it work locally for you (compile it as a normal OCaml project, = using ocamlbuild for instance), but everytime you want to do a syscall = (network or disk access) call a function from a parameter of your = functor instead of the one provided by the Unix module. >=20 > Once this is working fine locally for you, test it manually be = applying different implementations for the functor arguments. Then = extend unikernel.ml to use your functor. And = finally we can discuss on how to integrate it properly in the mirage = tool :p >=20 > Best, > Thomas >=20 >=20 >>=20 >> I think I'm struggling with the part of tying things together and = making them work. =20 >>=20 >> I started with the crunch kv_ro example since it was close enough to = what I want to do. I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro. >>=20 >> I've had functors and just normal functions that try to create the = modules based on the what is done for crunch ( impl kv_ro host (module = Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try = to use Kv or KvRoRedis directly, i receive an unbound constructor error. >>=20 >> Code can be found at: >> https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = >>=20 >> Any help or guidance would be appreciated. >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org = >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org = >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >=20 --Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I really think you are doing things in the wrong order. The = way I see the process:

1. Write some normal OCaml code on Unix, we test and debug it = with the normal Unix tools.
2. Abstract the system = dependencies as parameters of the functor. Usually everything related to = input/output. It's better to keep that in mind while doing 1. though, = otherwise it can causes some pain. Now you know what module type you = need to depend on.
3. Take an existing example in = mirage-skeleton and modify the body of unikernel.ml to call your code. = Now you know what shape the generated will have.
4. = create the new impl in mirage.ml to make it more easily configurable. = Use knowledge you gathered from 2. and 3. to do so.

Doing things in reverse = order won't work very well :-)

Thomas

Once again I would = advise 
On 19 Dec 2014, at 20:23, Brian Brietzke <bbrietzke@gmail.com>= wrote:

Thanks Luke.  I kept looking at impl as most = of the other code in mirage.ml seemed to be using that.  I switched it = over to implementation and solved at least part of the problem.  On = the other hand, the KV_RO constructor was done out of frustration and = experimentation.  There will be constructor options ( host, port, = etc ) but it shouldn't be another KV_RO.

Thomas, I have a basic working ( well = compilable ) implementation up now.  The size and read functions = just return errors based on the name parameter, but that is enough to = get some basics.  I'll expand it out further as things = progress.

I'm = assuming the 'Symbol not found: _camlRediskv error' is part of the = referring module issue listed above?  Can I create a different = folder, use oasis to create a new library project and just 'opam pin' to = handling the non-module referring?

On Fri, = Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:
Hi,

First, thanks for your = effort!

So I don't know if "mirage configure" actually supports your = case of referring to another module from within config.ml
No it doen't (yet), but we had = some ideas to make it work (see http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 1/msg00078.html)

What I would = like to start off with is a new implementation of the KV_RO module but = using Redis instead of crunch or the file system.  

I think I need three = things:  one is the actual implementation module that implements = the KV_RO interface / module, one module that provides the packages and = libraries you need ( the Impl module? ) and then another for tie those = together.

This is indeed what is needed to have a fully = supported backend. Before that, I think the first step (the harder one) = is to get your implementation working on Linux. Just write = complete https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml to make it work locally for you (compile it as a normal = OCaml project, using ocamlbuild for instance), but everytime you want to = do a syscall (network or disk access) call a function from a parameter = of your functor instead of the one provided by the Unix = module.

Once = this is working fine locally for you, test it manually be applying = different implementations for the functor arguments. Then extend unikernel.ml to use your functor. And finally we can = discuss on how to integrate it properly in the mirage tool :p

Best,
Thomas



I think = I'm struggling with the part of tying things together and making them = work.  

I = started with the crunch kv_ro example since it was close enough to what = I want to do.  I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro.

I've had functors and just normal = functions that try to create the modules based on the what is done for = crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that = impl cannot be found.  When i try to use Kv or KvRoRedis directly, = i receive an unbound constructor error.

Code can be found at:
https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


= --Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE-- --===============2934931030278134187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2934931030278134187==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 20:36:30 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 20:36:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24Hf-000440-Dr; Fri, 19 Dec 2014 20:36:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24Hd-00043v-Ve for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 20:36:22 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id BF/64-02957-54C84945; Fri, 19 Dec 2014 20:36:21 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1419021378!10839445!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15137 invoked from network); 19 Dec 2014 20:36:18 -0000 Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 20:36:18 -0000 Received: by mail-wg0-f44.google.com with SMTP id b13so2293637wgh.3 for ; Fri, 19 Dec 2014 12:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TmokJcsw3fqx4iBBL3oNdvIRGwwVoBnmtdRmUZ5CFm0=; b=Wdn4Gi26q6bsBYFAX68kHNg5vwzOc2jGYURP9RJ9AoNzoKC42vVEhurxs7TqBdR8hb 1Ov7CyTvM1p/2VAPHI0LWAn+ziBUVO07wuGif5dVQhy7hsFK33ttZ2zdLL8P+J3rkWGy yUlWZK1kP90/uYqaoFTY3IJJp43x+6jnC+zK3PF2AXBoRgTgmCXUWem9yn/7etKcHQ4y aTSe4cKVYRzZemvOwffuBjOMGhG8dDSwB/OCxzoXNRT2mWwdmvDmY49/T4tnT3LsKMKy Bp+wTGnvGtdMh41WhJsaCRgiuIbU22rM57rU6SYBf1LsTBXiPeWtbM1MYFas3R5ItFKI dAgA== X-Received: by 10.194.71.45 with SMTP id r13mr17680409wju.128.1419021378328; Fri, 19 Dec 2014 12:36:18 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id pl1sm3588803wic.16.2014.12.19.12.36.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 12:36:17 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Fri, 19 Dec 2014 20:36:15 +0000 Message-Id: <548B6002-539D-4BEB-B2EF-7DB28EBDD3E7@gazagnaire.org> References: To: Brian Brietzke X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2934931030278134187==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2934931030278134187== Content-Type: multipart/alternative; boundary="Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE" --Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I really think you are doing things in the wrong order. The way I see = the process: 1. Write some normal OCaml code on Unix, we test and debug it with the = normal Unix tools. 2. Abstract the system dependencies as parameters of the functor. = Usually everything related to input/output. It's better to keep that in = mind while doing 1. though, otherwise it can causes some pain. Now you = know what module type you need to depend on. 3. Take an existing example in mirage-skeleton and modify the body of = unikernel.ml to call your code. Now you know what shape the generated = will have. 4. create the new impl in mirage.ml to make it more easily configurable. = Use knowledge you gathered from 2. and 3. to do so. Doing things in reverse order won't work very well :-) Thomas Once again I would advise=20 > On 19 Dec 2014, at 20:23, Brian Brietzke wrote: >=20 > Thanks Luke. I kept looking at impl as most of the other code in = mirage.ml seemed to be using that. I switched it = over to implementation and solved at least part of the problem. On the = other hand, the KV_RO constructor was done out of frustration and = experimentation. There will be constructor options ( host, port, etc ) = but it shouldn't be another KV_RO. >=20 > Thomas, I have a basic working ( well compilable ) implementation up = now. The size and read functions just return errors based on the name = parameter, but that is enough to get some basics. I'll expand it out = further as things progress. >=20 > I'm assuming the 'Symbol not found: _camlRediskv error' is part of the = referring module issue listed above? Can I create a different folder, = use oasis to create a new library project and just 'opam pin' to = handling the non-module referring? >=20 > On Fri, Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire = > wrote: > Hi, >=20 > First, thanks for your effort! >=20 >> So I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml > No it doen't (yet), but we had some ideas to make it work (see = http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00078.= html = ) >=20 >> What I would like to start off with is a new implementation of the = KV_RO module but using Redis instead of crunch or the file system. =20 >>=20 >> I think I need three things: one is the actual implementation module = that implements the KV_RO interface / module, one module that provides = the packages and libraries you need ( the Impl module? ) and then = another for tie those together. >=20 > This is indeed what is needed to have a fully supported backend. = Before that, I think the first step (the harder one) is to get your = implementation working on Linux. Just write complete = https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = = to make it work locally for you (compile it as a normal OCaml project, = using ocamlbuild for instance), but everytime you want to do a syscall = (network or disk access) call a function from a parameter of your = functor instead of the one provided by the Unix module. >=20 > Once this is working fine locally for you, test it manually be = applying different implementations for the functor arguments. Then = extend unikernel.ml to use your functor. And = finally we can discuss on how to integrate it properly in the mirage = tool :p >=20 > Best, > Thomas >=20 >=20 >>=20 >> I think I'm struggling with the part of tying things together and = making them work. =20 >>=20 >> I started with the crunch kv_ro example since it was close enough to = what I want to do. I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro. >>=20 >> I've had functors and just normal functions that try to create the = modules based on the what is done for crunch ( impl kv_ro host (module = Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try = to use Kv or KvRoRedis directly, i receive an unbound constructor error. >>=20 >> Code can be found at: >> https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = >>=20 >> Any help or guidance would be appreciated. >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org = >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>=20 >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org = >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >=20 --Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I really think you are doing things in the wrong order. The = way I see the process:

1. Write some normal OCaml code on Unix, we test and debug it = with the normal Unix tools.
2. Abstract the system = dependencies as parameters of the functor. Usually everything related to = input/output. It's better to keep that in mind while doing 1. though, = otherwise it can causes some pain. Now you know what module type you = need to depend on.
3. Take an existing example in = mirage-skeleton and modify the body of unikernel.ml to call your code. = Now you know what shape the generated will have.
4. = create the new impl in mirage.ml to make it more easily configurable. = Use knowledge you gathered from 2. and 3. to do so.

Doing things in reverse = order won't work very well :-)

Thomas

Once again I would = advise 
On 19 Dec 2014, at 20:23, Brian Brietzke <bbrietzke@gmail.com>= wrote:

Thanks Luke.  I kept looking at impl as most = of the other code in mirage.ml seemed to be using that.  I switched it = over to implementation and solved at least part of the problem.  On = the other hand, the KV_RO constructor was done out of frustration and = experimentation.  There will be constructor options ( host, port, = etc ) but it shouldn't be another KV_RO.

Thomas, I have a basic working ( well = compilable ) implementation up now.  The size and read functions = just return errors based on the name parameter, but that is enough to = get some basics.  I'll expand it out further as things = progress.

I'm = assuming the 'Symbol not found: _camlRediskv error' is part of the = referring module issue listed above?  Can I create a different = folder, use oasis to create a new library project and just 'opam pin' to = handling the non-module referring?

On Fri, = Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:
Hi,

First, thanks for your = effort!

So I don't know if "mirage configure" actually supports your = case of referring to another module from within config.ml
No it doen't (yet), but we had = some ideas to make it work (see http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 1/msg00078.html)

What I would = like to start off with is a new implementation of the KV_RO module but = using Redis instead of crunch or the file system.  

I think I need three = things:  one is the actual implementation module that implements = the KV_RO interface / module, one module that provides the packages and = libraries you need ( the Impl module? ) and then another for tie those = together.

This is indeed what is needed to have a fully = supported backend. Before that, I think the first step (the harder one) = is to get your implementation working on Linux. Just write = complete https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml to make it work locally for you (compile it as a normal = OCaml project, using ocamlbuild for instance), but everytime you want to = do a syscall (network or disk access) call a function from a parameter = of your functor instead of the one provided by the Unix = module.

Once = this is working fine locally for you, test it manually be applying = different implementations for the functor arguments. Then extend unikernel.ml to use your functor. And finally we can = discuss on how to integrate it properly in the mirage tool :p

Best,
Thomas



I think = I'm struggling with the part of tying things together and making them = work.  

I = started with the crunch kv_ro example since it was close enough to what = I want to do.  I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro.

I've had functors and just normal = functions that try to create the modules based on the what is done for = crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that = impl cannot be found.  When i try to use Kv or KvRoRedis directly, = i receive an unbound constructor error.

Code can be found at:
https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


= --Apple-Mail=_1BE3BAE5-F9FF-4571-B8D5-336A3AB727EE-- --===============2934931030278134187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2934931030278134187==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 21:17:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 21:17:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24vg-0005aD-5a; Fri, 19 Dec 2014 21:17:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24vf-0005a8-7Q for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 21:17:43 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 5A/DD-25714-6F594945; Fri, 19 Dec 2014 21:17:42 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1419023861!14437623!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29894 invoked from network); 19 Dec 2014 21:17:41 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 21:17:41 -0000 Received: by mail-lb0-f172.google.com with SMTP id u10so1498995lbd.3 for ; Fri, 19 Dec 2014 13:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gmOxMupr+Mw7DBkAA6usx9jKbzX17N85aOCjxY0K2h4=; b=ug+u6aJL/n0RACuBNRtCU52zD73pxOpGYF5+gKZPvGtbQJE3QYDG4pDVhld410NBXd AQVWdufwhrfzbv/hvKq/QJ98DhJ+uK0DwpLXnWXUPwXbmKI6yI8HcJ5reeEuxuM0RxE/ EMeeZxDL2aZ7xmU1WVymZaBYWRXYunu+3BuknFtEJMqAr7gvMQ9TXJCwi4x1Nc4yPdVu Z1rpgRgDROL/H/74P9WFSKvmvnYSrL+6eAXJYZxLaCG0LvymwfK01v1JSTOTMSG0PbRv ThlU4FUSNtQSfRKPb0x1b7sPaz4o9o5BkmkxTn9NqzKi+P7IBZeHDrWNlz3kIBjcUEjN DgZw== MIME-Version: 1.0 X-Received: by 10.152.36.1 with SMTP id m1mr9802736laj.95.1419023860768; Fri, 19 Dec 2014 13:17:40 -0800 (PST) Received: by 10.112.48.65 with HTTP; Fri, 19 Dec 2014 13:17:40 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Dec 2014 15:17:40 -0600 Message-ID: From: Brian Brietzke To: Nicolas Ojeda Bar Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8177264407032299031==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8177264407032299031== Content-Type: multipart/alternative; boundary=089e0158b7cc26293e050a983d59 --089e0158b7cc26293e050a983d59 Content-Type: text/plain; charset=UTF-8 I don't think you can link to the external libraries in the xen based unikernels. The unikernels are designed to be self-contained little universes. Everything has to be embedded in there. Which, unfortunately means that you can't link to third-party libraries, linking to stubs or other things. I asked a similar question earlier this month. The conversation is http://lists.xenproject.org/archives/html/mirageos-devel/2014-12/msg00063.html . In other words, the expectation is that the code for the xen unikernels is to be OCaml based with out having to worry anything C related, unless you can port that C code to work inside of MinOs. On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar wrote: > > Hi list, > > I have a unikernel that uses the `uint` package (which is implemented > in C). I can compile and run fine on Unix, but when compiling for Xen > I get linking errors because the uint C stubs are not getting linked > to the unikernel... > > It would be great if someone could explain what is involved in getting > C stubs linked to Xen unikernels, whether it is a reasonable thing to > do, the standard way to do it, etc... > > Thanks! > > Best wishes, > Nicolas > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --089e0158b7cc26293e050a983d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think you can link to the external libraries i= n the xen based unikernels.

The unikernels are designed = to be self-contained little universes. Everything has to be embedded in the= re. Which, unfortunately means that you can't link to third-party libra= ries, linking to stubs or other things.

I asked a = similar question earlier this month.=C2=A0 The conversation is http://lists.xenproject.org/archives/html/mirageos-devel/2014-12/msg000= 63.html.

In other words, the expectation is th= at the code for the xen unikernels is to be OCaml based with out having to = worry anything C related, unless you can port that C code to work inside of= MinOs.

On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar <= no263@dpmms.cam.= ac.uk> wrote:
Hi list,

I have a unikernel that uses the `uint` package (which is implemented
in C).=C2=A0 I can compile and run fine on Unix, but when compiling for Xen=
I get linking errors because the uint C stubs are not getting linked
to the unikernel...

It would be great if someone could explain what is involved in getting
C stubs linked to Xen unikernels, whether it is a reasonable thing to
do, the standard way to do it, etc...

Thanks!

Best wishes,
Nicolas

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel
--089e0158b7cc26293e050a983d59-- --===============8177264407032299031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8177264407032299031==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 21:17:46 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 21:17:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24vg-0005aD-5a; Fri, 19 Dec 2014 21:17:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y24vf-0005a8-7Q for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 21:17:43 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 5A/DD-25714-6F594945; Fri, 19 Dec 2014 21:17:42 +0000 X-Env-Sender: bbrietzke@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1419023861!14437623!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29894 invoked from network); 19 Dec 2014 21:17:41 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Dec 2014 21:17:41 -0000 Received: by mail-lb0-f172.google.com with SMTP id u10so1498995lbd.3 for ; Fri, 19 Dec 2014 13:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gmOxMupr+Mw7DBkAA6usx9jKbzX17N85aOCjxY0K2h4=; b=ug+u6aJL/n0RACuBNRtCU52zD73pxOpGYF5+gKZPvGtbQJE3QYDG4pDVhld410NBXd AQVWdufwhrfzbv/hvKq/QJ98DhJ+uK0DwpLXnWXUPwXbmKI6yI8HcJ5reeEuxuM0RxE/ EMeeZxDL2aZ7xmU1WVymZaBYWRXYunu+3BuknFtEJMqAr7gvMQ9TXJCwi4x1Nc4yPdVu Z1rpgRgDROL/H/74P9WFSKvmvnYSrL+6eAXJYZxLaCG0LvymwfK01v1JSTOTMSG0PbRv ThlU4FUSNtQSfRKPb0x1b7sPaz4o9o5BkmkxTn9NqzKi+P7IBZeHDrWNlz3kIBjcUEjN DgZw== MIME-Version: 1.0 X-Received: by 10.152.36.1 with SMTP id m1mr9802736laj.95.1419023860768; Fri, 19 Dec 2014 13:17:40 -0800 (PST) Received: by 10.112.48.65 with HTTP; Fri, 19 Dec 2014 13:17:40 -0800 (PST) In-Reply-To: References: Date: Fri, 19 Dec 2014 15:17:40 -0600 Message-ID: From: Brian Brietzke To: Nicolas Ojeda Bar Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8177264407032299031==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8177264407032299031== Content-Type: multipart/alternative; boundary=089e0158b7cc26293e050a983d59 --089e0158b7cc26293e050a983d59 Content-Type: text/plain; charset=UTF-8 I don't think you can link to the external libraries in the xen based unikernels. The unikernels are designed to be self-contained little universes. Everything has to be embedded in there. Which, unfortunately means that you can't link to third-party libraries, linking to stubs or other things. I asked a similar question earlier this month. The conversation is http://lists.xenproject.org/archives/html/mirageos-devel/2014-12/msg00063.html . In other words, the expectation is that the code for the xen unikernels is to be OCaml based with out having to worry anything C related, unless you can port that C code to work inside of MinOs. On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar wrote: > > Hi list, > > I have a unikernel that uses the `uint` package (which is implemented > in C). I can compile and run fine on Unix, but when compiling for Xen > I get linking errors because the uint C stubs are not getting linked > to the unikernel... > > It would be great if someone could explain what is involved in getting > C stubs linked to Xen unikernels, whether it is a reasonable thing to > do, the standard way to do it, etc... > > Thanks! > > Best wishes, > Nicolas > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > --089e0158b7cc26293e050a983d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think you can link to the external libraries i= n the xen based unikernels.

The unikernels are designed = to be self-contained little universes. Everything has to be embedded in the= re. Which, unfortunately means that you can't link to third-party libra= ries, linking to stubs or other things.

I asked a = similar question earlier this month.=C2=A0 The conversation is http://lists.xenproject.org/archives/html/mirageos-devel/2014-12/msg000= 63.html.

In other words, the expectation is th= at the code for the xen unikernels is to be OCaml based with out having to = worry anything C related, unless you can port that C code to work inside of= MinOs.

On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar <= no263@dpmms.cam.= ac.uk> wrote:
Hi list,

I have a unikernel that uses the `uint` package (which is implemented
in C).=C2=A0 I can compile and run fine on Unix, but when compiling for Xen=
I get linking errors because the uint C stubs are not getting linked
to the unikernel...

It would be great if someone could explain what is involved in getting
C stubs linked to Xen unikernels, whether it is a reasonable thing to
do, the standard way to do it, etc...

Thanks!

Best wishes,
Nicolas

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel
--089e0158b7cc26293e050a983d59-- --===============8177264407032299031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8177264407032299031==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:02:11 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:02:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25cd-0007La-1G; Fri, 19 Dec 2014 22:02:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25ca-0007LV-Ir for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:02:05 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 19/C2-20609-B50A4945; Fri, 19 Dec 2014 22:02:03 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1419026523!16247939!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.5 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11972 invoked from network); 19 Dec 2014 22:02:03 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:02:03 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 4c9078ed; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:08:05 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Dec 2014 14:01:59 -0800 Message-Id: <1E263362-EEE1-407C-844A-ECD51FB4F587@recoil.org> References: To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Nicolas, I just noticed the uint dependency in the IPv6 stack too. The C linking is being progressively introduced in a series of commits in recent releases of Mirage (mostly by Thomas Leonard): - Mirage v2.1.1: Do not reuse the Unix linker options when building Xen unikernels. Instead, get the linker options from the ocamlfind xen_linkopts variables (#332). This release stopped just using the Unix linker flags with Xen compilation and introduces the special `xen_linkopts` ocamlfind variable that specifies CFLAGS for Xen unikernels. - TCP/IP v2.1.0: uses the new `xen_linkopts` flag for compiling the checksum stubs. mirage-xen v2.1.1 removed its local copies, so we now now have an external library (tcpip) providing external Xen stubs. See also the recent thread about TLS status, which is doing the next step: how to compile C stubs from libraries that we don't directly control (and hence can't add xen_linkopts for in their ocamlfind libraries). One way to do this in the short term is to follow what Thomas has done in https://github.com/mirage/mirage-dev/pull/49 and add a forked version of uint with the xen_cflags support. In the medium term, we'll need some mechanism to provide a Xen variant of an existing library like Zarith or uint, possibly using the opam depexts facility to query these packages at `mirage configure` time. -anil > On 19 Dec 2014, at 11:41, Nicolas Ojeda Bar wrote: > > Hi list, > > I have a unikernel that uses the `uint` package (which is implemented > in C). I can compile and run fine on Unix, but when compiling for Xen > I get linking errors because the uint C stubs are not getting linked > to the unikernel... > > It would be great if someone could explain what is involved in getting > C stubs linked to Xen unikernels, whether it is a reasonable thing to > do, the standard way to do it, etc... > > Thanks! > > Best wishes, > Nicolas > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:02:11 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:02:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25cd-0007La-1G; Fri, 19 Dec 2014 22:02:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25ca-0007LV-Ir for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:02:05 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 19/C2-20609-B50A4945; Fri, 19 Dec 2014 22:02:03 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1419026523!16247939!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.5 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11972 invoked from network); 19 Dec 2014 22:02:03 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:02:03 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 4c9078ed; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:08:05 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Dec 2014 14:01:59 -0800 Message-Id: <1E263362-EEE1-407C-844A-ECD51FB4F587@recoil.org> References: To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi Nicolas, I just noticed the uint dependency in the IPv6 stack too. The C linking is being progressively introduced in a series of commits in recent releases of Mirage (mostly by Thomas Leonard): - Mirage v2.1.1: Do not reuse the Unix linker options when building Xen unikernels. Instead, get the linker options from the ocamlfind xen_linkopts variables (#332). This release stopped just using the Unix linker flags with Xen compilation and introduces the special `xen_linkopts` ocamlfind variable that specifies CFLAGS for Xen unikernels. - TCP/IP v2.1.0: uses the new `xen_linkopts` flag for compiling the checksum stubs. mirage-xen v2.1.1 removed its local copies, so we now now have an external library (tcpip) providing external Xen stubs. See also the recent thread about TLS status, which is doing the next step: how to compile C stubs from libraries that we don't directly control (and hence can't add xen_linkopts for in their ocamlfind libraries). One way to do this in the short term is to follow what Thomas has done in https://github.com/mirage/mirage-dev/pull/49 and add a forked version of uint with the xen_cflags support. In the medium term, we'll need some mechanism to provide a Xen variant of an existing library like Zarith or uint, possibly using the opam depexts facility to query these packages at `mirage configure` time. -anil > On 19 Dec 2014, at 11:41, Nicolas Ojeda Bar wrote: > > Hi list, > > I have a unikernel that uses the `uint` package (which is implemented > in C). I can compile and run fine on Unix, but when compiling for Xen > I get linking errors because the uint C stubs are not getting linked > to the unikernel... > > It would be great if someone could explain what is involved in getting > C stubs linked to Xen unikernels, whether it is a reasonable thing to > do, the standard way to do it, etc... > > Thanks! > > Best wishes, > Nicolas > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:03:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:03:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25e8-0007QW-7P; Fri, 19 Dec 2014 22:03:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25e6-0007PM-Dh for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:03:38 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 3D/A8-02696-9B0A4945; Fri, 19 Dec 2014 22:03:37 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1419026616!16248128!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21514 invoked from network); 19 Dec 2014 22:03:36 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:03:36 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id de3f06cf; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:09:38 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Dec 2014 14:03:29 -0800 Message-Id: References: To: Brian Brietzke X-Mailer: Apple Mail (2.1993) Cc: Nicolas Ojeda Bar , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0232863231914905522==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0232863231914905522== Content-Type: multipart/alternative; boundary="Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31" --Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is mostly true, except for very deep stubs such as zarith or uint = that provide specific functionality that we do need. The xen_cflags = should let us do that in the latest releases of Mirage, and we're just = missing some build plumbing to enable it. -anil > On 19 Dec 2014, at 13:17, Brian Brietzke wrote: >=20 > I don't think you can link to the external libraries in the xen based = unikernels. >=20 > The unikernels are designed to be self-contained little universes. = Everything has to be embedded in there. Which, unfortunately means that = you can't link to third-party libraries, linking to stubs or other = things. >=20 > I asked a similar question earlier this month. The conversation is = http://lists.xenproject.org/archives/html/mirageos-devel/2014-12/msg00063.= html = . >=20 > In other words, the expectation is that the code for the xen = unikernels is to be OCaml based with out having to worry anything C = related, unless you can port that C code to work inside of MinOs. >=20 > On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar = > wrote: > Hi list, >=20 > I have a unikernel that uses the `uint` package (which is implemented > in C). I can compile and run fine on Unix, but when compiling for Xen > I get linking errors because the uint C stubs are not getting linked > to the unikernel... >=20 > It would be great if someone could explain what is involved in getting > C stubs linked to Xen unikernels, whether it is a reasonable thing to > do, the standard way to do it, etc... >=20 > Thanks! >=20 > Best wishes, > Nicolas >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org = > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is mostly true, except for very deep stubs such as = zarith or uint that provide specific functionality that we do need. =  The xen_cflags should let us do that in the latest releases of = Mirage, and we're just missing some build plumbing to enable it.

-anil

On 19 Dec 2014, at 13:17, Brian Brietzke <bbrietzke@gmail.com>= wrote:

I don't think you can link to the external = libraries in the xen based unikernels.

The unikernels are designed to be = self-contained little universes. Everything has to be embedded in there. = Which, unfortunately means that you can't link to third-party libraries, = linking to stubs or other things.

I asked a similar question earlier this = month.  The conversation is http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 2/msg00063.html.

In other words, the expectation is that the code for the xen = unikernels is to be OCaml based with out having to worry anything C = related, unless you can port that C code to work inside of = MinOs.

On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar = <no263@dpmms.cam.ac.uk> = wrote:
Hi list,

I have a unikernel that uses the `uint` package (which is implemented
in C).  I can compile and run fine on Unix, but when compiling for = Xen
I get linking errors because the uint C stubs are not getting linked
to the unikernel...

It would be great if someone could explain what is involved in = getting
C stubs linked to Xen unikernels, whether it is a reasonable thing to
do, the standard way to do it, etc...

Thanks!

Best wishes,
Nicolas

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31-- --===============0232863231914905522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0232863231914905522==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:03:40 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:03:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25e8-0007QW-7P; Fri, 19 Dec 2014 22:03:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25e6-0007PM-Dh for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:03:38 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 3D/A8-02696-9B0A4945; Fri, 19 Dec 2014 22:03:37 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1419026616!16248128!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21514 invoked from network); 19 Dec 2014 22:03:36 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:03:36 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id de3f06cf; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:09:38 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Dec 2014 14:03:29 -0800 Message-Id: References: To: Brian Brietzke X-Mailer: Apple Mail (2.1993) Cc: Nicolas Ojeda Bar , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] how to link c stubs to xen unikernels ? X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0232863231914905522==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0232863231914905522== Content-Type: multipart/alternative; boundary="Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31" --Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is mostly true, except for very deep stubs such as zarith or uint = that provide specific functionality that we do need. The xen_cflags = should let us do that in the latest releases of Mirage, and we're just = missing some build plumbing to enable it. -anil > On 19 Dec 2014, at 13:17, Brian Brietzke wrote: >=20 > I don't think you can link to the external libraries in the xen based = unikernels. >=20 > The unikernels are designed to be self-contained little universes. = Everything has to be embedded in there. Which, unfortunately means that = you can't link to third-party libraries, linking to stubs or other = things. >=20 > I asked a similar question earlier this month. The conversation is = http://lists.xenproject.org/archives/html/mirageos-devel/2014-12/msg00063.= html = . >=20 > In other words, the expectation is that the code for the xen = unikernels is to be OCaml based with out having to worry anything C = related, unless you can port that C code to work inside of MinOs. >=20 > On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar = > wrote: > Hi list, >=20 > I have a unikernel that uses the `uint` package (which is implemented > in C). I can compile and run fine on Unix, but when compiling for Xen > I get linking errors because the uint C stubs are not getting linked > to the unikernel... >=20 > It would be great if someone could explain what is involved in getting > C stubs linked to Xen unikernels, whether it is a reasonable thing to > do, the standard way to do it, etc... >=20 > Thanks! >=20 > Best wishes, > Nicolas >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org = > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is mostly true, except for very deep stubs such as = zarith or uint that provide specific functionality that we do need. =  The xen_cflags should let us do that in the latest releases of = Mirage, and we're just missing some build plumbing to enable it.

-anil

On 19 Dec 2014, at 13:17, Brian Brietzke <bbrietzke@gmail.com>= wrote:

I don't think you can link to the external = libraries in the xen based unikernels.

The unikernels are designed to be = self-contained little universes. Everything has to be embedded in there. = Which, unfortunately means that you can't link to third-party libraries, = linking to stubs or other things.

I asked a similar question earlier this = month.  The conversation is http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 2/msg00063.html.

In other words, the expectation is that the code for the xen = unikernels is to be OCaml based with out having to worry anything C = related, unless you can port that C code to work inside of = MinOs.

On Fri, Dec 19, 2014 at 1:41 PM, Nicolas Ojeda Bar = <no263@dpmms.cam.ac.uk> = wrote:
Hi list,

I have a unikernel that uses the `uint` package (which is implemented
in C).  I can compile and run fine on Unix, but when compiling for = Xen
I get linking errors because the uint C stubs are not getting linked
to the unikernel...

It would be great if someone could explain what is involved in = getting
C stubs linked to Xen unikernels, whether it is a reasonable thing to
do, the standard way to do it, etc...

Thanks!

Best wishes,
Nicolas

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_7F48DCA9-6723-4D3B-BC29-A74A59FC3B31-- --===============0232863231914905522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0232863231914905522==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:05:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25fh-0007Zl-Fi; Fri, 19 Dec 2014 22:05:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25fg-0007Zg-Ei for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:05:16 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id D0/7E-02957-B11A4945; Fri, 19 Dec 2014 22:05:15 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1419026713!16280958!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7234 invoked from network); 19 Dec 2014 22:05:13 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:05:13 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 81544b25; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:11:15 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <548B6002-539D-4BEB-B2EF-7DB28EBDD3E7@gazagnaire.org> Date: Fri, 19 Dec 2014 14:05:06 -0800 Message-Id: <331492ED-2287-412B-BE26-B2E15ACEDC7E@recoil.org> References: <548B6002-539D-4BEB-B2EF-7DB28EBDD3E7@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: Brian Brietzke , mirageos-devel Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427656930503811673==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1427656930503811673== Content-Type: multipart/alternative; boundary="Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B" --Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is spot on. When I develop Mirage code, putting it into the = functor is basically the last thing I do. Start with Unix, but don't = let Unix get too deep into your code, and *then* abstract away the = pieces as Thomas describes. Also, don't be afraid of proposing breaking changes to interfaces such = as KV_RO -- we've made a number of such changes (most recently for the = IPv6 introduction), so I expect the same will be needed for a Redis = backend to KV_RO as well! -anil > On 19 Dec 2014, at 12:36, Thomas Gazagnaire = wrote: >=20 > I really think you are doing things in the wrong order. The way I see = the process: >=20 > 1. Write some normal OCaml code on Unix, we test and debug it with the = normal Unix tools. > 2. Abstract the system dependencies as parameters of the functor. = Usually everything related to input/output. It's better to keep that in = mind while doing 1. though, otherwise it can causes some pain. Now you = know what module type you need to depend on. > 3. Take an existing example in mirage-skeleton and modify the body of = unikernel.ml to call your code. Now you know what shape the generated = will have. > 4. create the new impl in mirage.ml to make it more easily = configurable. Use knowledge you gathered from 2. and 3. to do so. >=20 > Doing things in reverse order won't work very well :-) >=20 > Thomas >=20 > Once again I would advise=20 >> On 19 Dec 2014, at 20:23, Brian Brietzke > wrote: >>=20 >> Thanks Luke. I kept looking at impl as most of the other code in = mirage.ml seemed to be using that. I switched it = over to implementation and solved at least part of the problem. On the = other hand, the KV_RO constructor was done out of frustration and = experimentation. There will be constructor options ( host, port, etc ) = but it shouldn't be another KV_RO. >>=20 >> Thomas, I have a basic working ( well compilable ) implementation up = now. The size and read functions just return errors based on the name = parameter, but that is enough to get some basics. I'll expand it out = further as things progress. >>=20 >> I'm assuming the 'Symbol not found: _camlRediskv error' is part of = the referring module issue listed above? Can I create a different = folder, use oasis to create a new library project and just 'opam pin' to = handling the non-module referring? >>=20 >> On Fri, Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire = > wrote: >> Hi, >>=20 >> First, thanks for your effort! >>=20 >>> So I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml >> No it doen't (yet), but we had some ideas to make it work (see = http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00078.= html = ) >>=20 >>> What I would like to start off with is a new implementation of the = KV_RO module but using Redis instead of crunch or the file system. =20 >>>=20 >>> I think I need three things: one is the actual implementation = module that implements the KV_RO interface / module, one module that = provides the packages and libraries you need ( the Impl module? ) and = then another for tie those together. >>=20 >> This is indeed what is needed to have a fully supported backend. = Before that, I think the first step (the harder one) is to get your = implementation working on Linux. Just write complete = https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = = to make it work locally for you (compile it as a normal OCaml project, = using ocamlbuild for instance), but everytime you want to do a syscall = (network or disk access) call a function from a parameter of your = functor instead of the one provided by the Unix module. >>=20 >> Once this is working fine locally for you, test it manually be = applying different implementations for the functor arguments. Then = extend unikernel.ml to use your functor. And = finally we can discuss on how to integrate it properly in the mirage = tool :p >>=20 >> Best, >> Thomas >>=20 >>=20 >>>=20 >>> I think I'm struggling with the part of tying things together and = making them work. =20 >>>=20 >>> I started with the crunch kv_ro example since it was close enough to = what I want to do. I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro. >>>=20 >>> I've had functors and just normal functions that try to create the = modules based on the what is done for crunch ( impl kv_ro host (module = Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try = to use Kv or KvRoRedis directly, i receive an unbound constructor error. >>>=20 >>> Code can be found at: >>> https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = >>>=20 >>> Any help or guidance would be appreciated. >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is spot on.  When I develop Mirage code, putting it = into the functor is basically the last thing I do.  Start with = Unix, but don't let Unix get too deep into your code, and *then* = abstract away the pieces as Thomas describes.

Also, don't be afraid of proposing = breaking changes to interfaces such as KV_RO -- we've made a number of = such changes (most recently for the IPv6 introduction), so I expect the = same will be needed for a Redis backend to KV_RO as well!

-anil

On 19 Dec 2014, at 12:36, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:

I really think = you are doing things in the wrong order. The way I see the process:

1. Write some normal = OCaml code on Unix, we test and debug it with the normal Unix = tools.
2. Abstract the system dependencies as = parameters of the functor. Usually everything related to input/output. = It's better to keep that in mind while doing 1. though, otherwise it can = causes some pain. Now you know what module type you need to depend = on.
3. Take an existing example in mirage-skeleton = and modify the body of unikernel.ml to call your code. Now you know what = shape the generated will have.
4. create the new = impl in mirage.ml to make it more easily configurable. Use knowledge you = gathered from 2. and 3. to do so.

Doing things in reverse order won't = work very well :-)

Thomas

Once again I would advise 
On 19 Dec 2014, at 20:23, Brian Brietzke <bbrietzke@gmail.com>= wrote:

Thanks Luke.  I kept looking at impl as most = of the other code in mirage.ml seemed to be using that.  I switched it = over to implementation and solved at least part of the problem.  On = the other hand, the KV_RO constructor was done out of frustration and = experimentation.  There will be constructor options ( host, port, = etc ) but it shouldn't be another KV_RO.

Thomas, I have a basic working ( well = compilable ) implementation up now.  The size and read functions = just return errors based on the name parameter, but that is enough to = get some basics.  I'll expand it out further as things = progress.

I'm = assuming the 'Symbol not found: _camlRediskv error' is part of the = referring module issue listed above?  Can I create a different = folder, use oasis to create a new library project and just 'opam pin' to = handling the non-module referring?

On Fri, = Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:
Hi,

First, thanks for your = effort!

So I don't know if "mirage configure" actually supports your = case of referring to another module from within config.ml
No it doen't (yet), but we had = some ideas to make it work (see http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 1/msg00078.html)

What I would = like to start off with is a new implementation of the KV_RO module but = using Redis instead of crunch or the file system.  

I think I need three = things:  one is the actual implementation module that implements = the KV_RO interface / module, one module that provides the packages and = libraries you need ( the Impl module? ) and then another for tie those = together.

This is indeed what is needed to have a fully = supported backend. Before that, I think the first step (the harder one) = is to get your implementation working on Linux. Just write = complete https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml to make it work locally for you (compile it as a normal = OCaml project, using ocamlbuild for instance), but everytime you want to = do a syscall (network or disk access) call a function from a parameter = of your functor instead of the one provided by the Unix = module.

Once = this is working fine locally for you, test it manually be applying = different implementations for the functor arguments. Then extend unikernel.ml to use your functor. And finally we can = discuss on how to integrate it properly in the mirage tool :p

Best,
Thomas



I think = I'm struggling with the part of tying things together and making them = work.  

I = started with the crunch kv_ro example since it was close enough to what = I want to do.  I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro.

I've had functors and just normal = functions that try to create the modules based on the what is done for = crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that = impl cannot be found.  When i try to use Kv or KvRoRedis directly, = i receive an unbound constructor error.

Code can be found at:
https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


_____________________________________________= __
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B-- --===============1427656930503811673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1427656930503811673==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:05:17 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25fh-0007Zl-Fi; Fri, 19 Dec 2014 22:05:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25fg-0007Zg-Ei for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:05:16 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id D0/7E-02957-B11A4945; Fri, 19 Dec 2014 22:05:15 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1419026713!16280958!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7234 invoked from network); 19 Dec 2014 22:05:13 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:05:13 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 81544b25; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:11:15 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <548B6002-539D-4BEB-B2EF-7DB28EBDD3E7@gazagnaire.org> Date: Fri, 19 Dec 2014 14:05:06 -0800 Message-Id: <331492ED-2287-412B-BE26-B2E15ACEDC7E@recoil.org> References: <548B6002-539D-4BEB-B2EF-7DB28EBDD3E7@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: Brian Brietzke , mirageos-devel Subject: Re: [MirageOS-devel] Custom KV_RO Implementation X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427656930503811673==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1427656930503811673== Content-Type: multipart/alternative; boundary="Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B" --Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is spot on. When I develop Mirage code, putting it into the = functor is basically the last thing I do. Start with Unix, but don't = let Unix get too deep into your code, and *then* abstract away the = pieces as Thomas describes. Also, don't be afraid of proposing breaking changes to interfaces such = as KV_RO -- we've made a number of such changes (most recently for the = IPv6 introduction), so I expect the same will be needed for a Redis = backend to KV_RO as well! -anil > On 19 Dec 2014, at 12:36, Thomas Gazagnaire = wrote: >=20 > I really think you are doing things in the wrong order. The way I see = the process: >=20 > 1. Write some normal OCaml code on Unix, we test and debug it with the = normal Unix tools. > 2. Abstract the system dependencies as parameters of the functor. = Usually everything related to input/output. It's better to keep that in = mind while doing 1. though, otherwise it can causes some pain. Now you = know what module type you need to depend on. > 3. Take an existing example in mirage-skeleton and modify the body of = unikernel.ml to call your code. Now you know what shape the generated = will have. > 4. create the new impl in mirage.ml to make it more easily = configurable. Use knowledge you gathered from 2. and 3. to do so. >=20 > Doing things in reverse order won't work very well :-) >=20 > Thomas >=20 > Once again I would advise=20 >> On 19 Dec 2014, at 20:23, Brian Brietzke > wrote: >>=20 >> Thanks Luke. I kept looking at impl as most of the other code in = mirage.ml seemed to be using that. I switched it = over to implementation and solved at least part of the problem. On the = other hand, the KV_RO constructor was done out of frustration and = experimentation. There will be constructor options ( host, port, etc ) = but it shouldn't be another KV_RO. >>=20 >> Thomas, I have a basic working ( well compilable ) implementation up = now. The size and read functions just return errors based on the name = parameter, but that is enough to get some basics. I'll expand it out = further as things progress. >>=20 >> I'm assuming the 'Symbol not found: _camlRediskv error' is part of = the referring module issue listed above? Can I create a different = folder, use oasis to create a new library project and just 'opam pin' to = handling the non-module referring? >>=20 >> On Fri, Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire = > wrote: >> Hi, >>=20 >> First, thanks for your effort! >>=20 >>> So I don't know if "mirage configure" actually supports your case of = referring to another module from within config.ml >> No it doen't (yet), but we had some ideas to make it work (see = http://lists.xenproject.org/archives/html/mirageos-devel/2014-11/msg00078.= html = ) >>=20 >>> What I would like to start off with is a new implementation of the = KV_RO module but using Redis instead of crunch or the file system. =20 >>>=20 >>> I think I need three things: one is the actual implementation = module that implements the KV_RO interface / module, one module that = provides the packages and libraries you need ( the Impl module? ) and = then another for tie those together. >>=20 >> This is indeed what is needed to have a fully supported backend. = Before that, I think the first step (the harder one) is to get your = implementation working on Linux. Just write complete = https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = = to make it work locally for you (compile it as a normal OCaml project, = using ocamlbuild for instance), but everytime you want to do a syscall = (network or disk access) call a function from a parameter of your = functor instead of the one provided by the Unix module. >>=20 >> Once this is working fine locally for you, test it manually be = applying different implementations for the functor arguments. Then = extend unikernel.ml to use your functor. And = finally we can discuss on how to integrate it properly in the mirage = tool :p >>=20 >> Best, >> Thomas >>=20 >>=20 >>>=20 >>> I think I'm struggling with the part of tying things together and = making them work. =20 >>>=20 >>> I started with the crunch kv_ro example since it was close enough to = what I want to do. I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro. >>>=20 >>> I've had functors and just normal functions that try to create the = modules based on the what is done for crunch ( impl kv_ro host (module = Kv/KvRoRedis/etc )) and I'm told that impl cannot be found. When i try = to use Kv or KvRoRedis directly, i receive an unbound constructor error. >>>=20 >>> Code can be found at: >>> https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/rediskv.ml = >>>=20 >>> Any help or guidance would be appreciated. >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is spot on.  When I develop Mirage code, putting it = into the functor is basically the last thing I do.  Start with = Unix, but don't let Unix get too deep into your code, and *then* = abstract away the pieces as Thomas describes.

Also, don't be afraid of proposing = breaking changes to interfaces such as KV_RO -- we've made a number of = such changes (most recently for the IPv6 introduction), so I expect the = same will be needed for a Redis backend to KV_RO as well!

-anil

On 19 Dec 2014, at 12:36, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:

I really think = you are doing things in the wrong order. The way I see the process:

1. Write some normal = OCaml code on Unix, we test and debug it with the normal Unix = tools.
2. Abstract the system dependencies as = parameters of the functor. Usually everything related to input/output. = It's better to keep that in mind while doing 1. though, otherwise it can = causes some pain. Now you know what module type you need to depend = on.
3. Take an existing example in mirage-skeleton = and modify the body of unikernel.ml to call your code. Now you know what = shape the generated will have.
4. create the new = impl in mirage.ml to make it more easily configurable. Use knowledge you = gathered from 2. and 3. to do so.

Doing things in reverse order won't = work very well :-)

Thomas

Once again I would advise 
On 19 Dec 2014, at 20:23, Brian Brietzke <bbrietzke@gmail.com>= wrote:

Thanks Luke.  I kept looking at impl as most = of the other code in mirage.ml seemed to be using that.  I switched it = over to implementation and solved at least part of the problem.  On = the other hand, the KV_RO constructor was done out of frustration and = experimentation.  There will be constructor options ( host, port, = etc ) but it shouldn't be another KV_RO.

Thomas, I have a basic working ( well = compilable ) implementation up now.  The size and read functions = just return errors based on the name parameter, but that is enough to = get some basics.  I'll expand it out further as things = progress.

I'm = assuming the 'Symbol not found: _camlRediskv error' is part of the = referring module issue listed above?  Can I create a different = folder, use oasis to create a new library project and just 'opam pin' to = handling the non-module referring?

On Fri, = Dec 19, 2014 at 10:58 AM, Thomas Gazagnaire <thomas@gazagnaire.org> wrote:
Hi,

First, thanks for your = effort!

So I don't know if "mirage configure" actually supports your = case of referring to another module from within config.ml
No it doen't (yet), but we had = some ideas to make it work (see http://lists.xenproject.org/archives/html/mirageos-devel/2014-1= 1/msg00078.html)

What I would = like to start off with is a new implementation of the KV_RO module but = using Redis instead of crunch or the file system.  

I think I need three = things:  one is the actual implementation module that implements = the KV_RO interface / module, one module that provides the packages and = libraries you need ( the Impl module? ) and then another for tie those = together.

This is indeed what is needed to have a fully = supported backend. Before that, I think the first step (the harder one) = is to get your implementation working on Linux. Just write = complete https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml to make it work locally for you (compile it as a normal = OCaml project, using ocamlbuild for instance), but everytime you want to = do a syscall (network or disk access) call a function from a parameter = of your functor instead of the one provided by the Unix = module.

Once = this is working fine locally for you, test it manually be applying = different implementations for the functor arguments. Then extend unikernel.ml to use your functor. And finally we can = discuss on how to integrate it properly in the mirage tool :p

Best,
Thomas



I think = I'm struggling with the part of tying things together and making them = work.  

I = started with the crunch kv_ro example since it was close enough to what = I want to do.  I have a module named Kv that provides the = libraries/packages/configure roughed out and had ( and will add it back = ) a module for the redis kv_ro.

I've had functors and just normal = functions that try to create the modules based on the what is done for = crunch ( impl kv_ro host (module Kv/KvRoRedis/etc )) and I'm told that = impl cannot be found.  When i try to use Kv or KvRoRedis directly, = i receive an unbound constructor error.

Code can be found at:
https://github.com/bbrietzke/sad_butter/blob/redis_kv/src/redis= kv.ml

Any help or guidance would be appreciated.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


_____________________________________________= __
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel

= --Apple-Mail=_4C723C26-D9CA-4B1E-88D8-6A6EFD82D63B-- --===============1427656930503811673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1427656930503811673==-- From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:11:22 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:11:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25la-0007hy-OQ; Fri, 19 Dec 2014 22:11:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25lZ-0007hr-ED for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:11:21 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 56/0D-02743-882A4945; Fri, 19 Dec 2014 22:11:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1419027079!16296807!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4974 invoked from network); 19 Dec 2014 22:11:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:11:19 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 31591a94; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:17:21 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> Date: Fri, 19 Dec 2014 14:11:14 -0800 Message-Id: <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment. Look in the xen/ subdirectory and grep for the C file that contains it. We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well. The build hacks are gradually being undone! -anil > On 19 Dec 2014, at 09:25, Anil Madhavapeddy wrote: > > CCing the list. > >> On 19 Dec 2014, at 08:49, Masoud Koleini wrote: >> >> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error: >> >> undefined reference to `caml_dealloc_page' >> >> how do you think I can fix it? >> >> Thanks. >> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >>> Not at the moment, although we could easily add an explicit deallocator into >>> Io_page. You need to very careful that the page is not used after its lifetime, >>> so more pool-based abstractions are preferred (where the pages are recycled into >>> an OCaml-managed data structure and reused rather than GCed). >>> >>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB >>> or so -- if the page allocator still remains low, then it's unlikely to be a GC >>> issue and an actual leak somewhere due to holding onto references and keeping >>> the page live. >>> >>> -anil >>> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini wrote: >>>> >>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC? >>>> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>>> I am wondering if the following issue is already addressed: >>>>>> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>>> >>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>>> >>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>>>> the GC parameters in the OCaml runtime to trigger a collection more often. >>>>> It should be harmless however, since (as the bug report observes), a failure >>>>> to allocate an Io_page results in a GC compaction that frees up memory so >>>>> that the allocation eventually succeeds. >>>>> >>>>> Any particular reason for asking -- is the bug affecting your switch somehow? >>>>> >>>>> -anil >>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>>> >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> and may contain confidential information. If you have received this >> message in error, please send it back to me, and immediately delete it. >> Please do not use, copy or disclose the information contained in this >> message or in any attachment. Any views or opinions expressed by the >> author of this email do not necessarily reflect the views of the >> University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Fri Dec 19 22:11:22 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 19 Dec 2014 22:11:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25la-0007hy-OQ; Fri, 19 Dec 2014 22:11:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y25lZ-0007hr-ED for mirageos-devel@lists.xenproject.org; Fri, 19 Dec 2014 22:11:21 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 56/0D-02743-882A4945; Fri, 19 Dec 2014 22:11:20 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-12.tower-27.messagelabs.com!1419027079!16296807!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4974 invoked from network); 19 Dec 2014 22:11:19 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2014 22:11:19 -0000 Received: from flick.lan (menlopark.keplers.com [74.93.6.213]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 31591a94; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Dec 2014 22:17:21 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> Date: Fri, 19 Dec 2014 14:11:14 -0800 Message-Id: <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment. Look in the xen/ subdirectory and grep for the C file that contains it. We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well. The build hacks are gradually being undone! -anil > On 19 Dec 2014, at 09:25, Anil Madhavapeddy wrote: > > CCing the list. > >> On 19 Dec 2014, at 08:49, Masoud Koleini wrote: >> >> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error: >> >> undefined reference to `caml_dealloc_page' >> >> how do you think I can fix it? >> >> Thanks. >> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >>> Not at the moment, although we could easily add an explicit deallocator into >>> Io_page. You need to very careful that the page is not used after its lifetime, >>> so more pool-based abstractions are preferred (where the pages are recycled into >>> an OCaml-managed data structure and reused rather than GCed). >>> >>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB >>> or so -- if the page allocator still remains low, then it's unlikely to be a GC >>> issue and an actual leak somewhere due to holding onto references and keeping >>> the page live. >>> >>> -anil >>> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini wrote: >>>> >>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC? >>>> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini wrote: >>>>>> I am wondering if the following issue is already addressed: >>>>>> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >>>>>> >>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >>>>>> >>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust >>>>> the GC parameters in the OCaml runtime to trigger a collection more often. >>>>> It should be harmless however, since (as the bug report observes), a failure >>>>> to allocate an Io_page results in a GC compaction that frees up memory so >>>>> that the allocation eventually succeeds. >>>>> >>>>> Any particular reason for asking -- is the bug affecting your switch somehow? >>>>> >>>>> -anil >>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>>> >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> and may contain confidential information. If you have received this >> message in error, please send it back to me, and immediately delete it. >> Please do not use, copy or disclose the information contained in this >> message or in any attachment. Any views or opinions expressed by the >> author of this email do not necessarily reflect the views of the >> University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 01:15:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 01:15:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y28e8-0002Gl-Q8; Sat, 20 Dec 2014 01:15:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y28e8-0002Gg-5o for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 01:15:52 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C7/21-25727-7CDC4945; Sat, 20 Dec 2014 01:15:51 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1419038150!14674179!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1978 invoked from network); 20 Dec 2014 01:15:50 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 01:15:50 -0000 Received: by mail-wg0-f48.google.com with SMTP id y19so2643947wgg.21 for ; Fri, 19 Dec 2014 17:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=aB+zkyr7n9T2X4H8xGaTmeYVMS4lT1rjWM7UkagPW/w=; b=c9sYTgbPP0bV5b/ZSMldsf8Pupm3/XK0vT950AYe0tf/OrMlDm5DbpgiDFLfB2RuZE oi9lW1Zz0A8iaqaq4Whbs1tlQHMg4Ru8/mZDhFdlQ14jVch/Xy3NHVU9gm73NZBtUHTf GQ5qaaD3OaWXwVKzImJKUdbd9EJ/RJorqCNSsMSdMsruxBlE6skymQ+ySzGgZJrfv58T ht6VjjfBC9IeOKZdlO4qOf8A4eRDjI0/AupXUqc7FQDpWAOn/G2dP8afzb8sLyHThZVi vEYY7ABmw0E1xdtSA2jIwUMvFq1RqaySo1gjoltDhub+BH1HiG2EpejAyy8VGsdl7jXN mbtg== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr10729463wic.57.1419038150226; Fri, 19 Dec 2014 17:15:50 -0800 (PST) Received: by 10.27.45.205 with HTTP; Fri, 19 Dec 2014 17:15:50 -0800 (PST) Date: Fri, 19 Dec 2014 22:15:50 -0300 X-Google-Sender-Auth: lf2e-0_C38dVnIeru-HO91lDgBg Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] mirage-www over ipv6 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi list, Just a quick note to let you know that we have mirage-www working over ipv6 at http://[2001:41c8:21:a::10]. I don't actually have ipv6 right now, so it would be great if someone who does could confirm that it is working (or not). Some of the needed functionality is not yet exposed by the `mirage` tool, so if you want to build this you will need patched versions of `mirage-tcpip`, `ocaml-conduit`, and `mirage-www` which you can obtain and build as follows: ``` opam pin add tcpip https://github.com/nojb/mirage-tcpip#mirage-www-ipv6 opam pin add conduit https://github.com/nojb/ocaml-conduit#mirage-www-ipv6 git clone -b mirage-www-ipv6 https://github.com/nojb/mirage-www cd mirage-www make configure make build ``` Best wishes, Nicolas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 01:15:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 01:15:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y28e8-0002Gl-Q8; Sat, 20 Dec 2014 01:15:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y28e8-0002Gg-5o for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 01:15:52 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C7/21-25727-7CDC4945; Sat, 20 Dec 2014 01:15:51 +0000 X-Env-Sender: n.oje.bar@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1419038150!14674179!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1978 invoked from network); 20 Dec 2014 01:15:50 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 01:15:50 -0000 Received: by mail-wg0-f48.google.com with SMTP id y19so2643947wgg.21 for ; Fri, 19 Dec 2014 17:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=aB+zkyr7n9T2X4H8xGaTmeYVMS4lT1rjWM7UkagPW/w=; b=c9sYTgbPP0bV5b/ZSMldsf8Pupm3/XK0vT950AYe0tf/OrMlDm5DbpgiDFLfB2RuZE oi9lW1Zz0A8iaqaq4Whbs1tlQHMg4Ru8/mZDhFdlQ14jVch/Xy3NHVU9gm73NZBtUHTf GQ5qaaD3OaWXwVKzImJKUdbd9EJ/RJorqCNSsMSdMsruxBlE6skymQ+ySzGgZJrfv58T ht6VjjfBC9IeOKZdlO4qOf8A4eRDjI0/AupXUqc7FQDpWAOn/G2dP8afzb8sLyHThZVi vEYY7ABmw0E1xdtSA2jIwUMvFq1RqaySo1gjoltDhub+BH1HiG2EpejAyy8VGsdl7jXN mbtg== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr10729463wic.57.1419038150226; Fri, 19 Dec 2014 17:15:50 -0800 (PST) Received: by 10.27.45.205 with HTTP; Fri, 19 Dec 2014 17:15:50 -0800 (PST) Date: Fri, 19 Dec 2014 22:15:50 -0300 X-Google-Sender-Auth: lf2e-0_C38dVnIeru-HO91lDgBg Message-ID: From: Nicolas Ojeda Bar To: "mirageos-devel@lists.xenproject.org" Subject: [MirageOS-devel] mirage-www over ipv6 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Hi list, Just a quick note to let you know that we have mirage-www working over ipv6 at http://[2001:41c8:21:a::10]. I don't actually have ipv6 right now, so it would be great if someone who does could confirm that it is working (or not). Some of the needed functionality is not yet exposed by the `mirage` tool, so if you want to build this you will need patched versions of `mirage-tcpip`, `ocaml-conduit`, and `mirage-www` which you can obtain and build as follows: ``` opam pin add tcpip https://github.com/nojb/mirage-tcpip#mirage-www-ipv6 opam pin add conduit https://github.com/nojb/ocaml-conduit#mirage-www-ipv6 git clone -b mirage-www-ipv6 https://github.com/nojb/mirage-www cd mirage-www make configure make build ``` Best wishes, Nicolas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 02:08:18 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 02:08:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29Sq-0004Pb-5g; Sat, 20 Dec 2014 02:08:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29So-0004PW-HT for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 02:08:14 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 67/0B-02953-D0AD4945; Sat, 20 Dec 2014 02:08:13 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1419041292!16289979!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14252 invoked from network); 20 Dec 2014 02:08:13 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 02:08:13 -0000 Received: by mail-wg0-f48.google.com with SMTP id y19so2693722wgg.21 for ; Fri, 19 Dec 2014 18:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b6QQRDAjmvVswBGDGCNkfAOcK4rZYCJo/bLVU0TRhLU=; b=Ru4Am/11jPqUvmqdFb5l5x75txKlcxP5N4svCoLe2JJdtXPnVnteJRkmt23tRRt/z6 6wzDLKeaYIWIq9/lAKAJDg2KRzQPIP0hVWSDs0hWR4mKUh2BlkQ92RGF+pre8Ra2yRm7 jlmF7o+T0LqctoQk9rJ4QEVs+sqqj76aOPsQr8711nVQPcLWjv8z0iSuEgvIBR7RfTNv zl82GNYivQCoE4uTZdCQki5rLfFwyeyimS4MsAljPd3tNeIivnUk/zFiVn1ESNepJnhp KkLTa4W6SBGRHj/IuvIIlQwC4A+4wj4zkKFckGzTLKn7/IwtxVnN721hF6KL5wuSZ6YP hygw== X-Received: by 10.180.104.65 with SMTP id gc1mr10777128wib.46.1419041292511; Fri, 19 Dec 2014 18:08:12 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id ly9sm14703901wjb.24.2014.12.19.18.08.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 18:08:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Sat, 20 Dec 2014 02:08:10 +0000 Message-Id: References: To: Anil Madhavapeddy X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] ocaml 4.02 support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > - Use Thomas' new CFLAGS infrastructure to compile libasmrun from OCaml as a library just as we do everything else. > > I'd prefer the latter as it gets yet more code out of mirage-platform, and we can still do custom patches via a fork (as we do with openlibm). Thoughts? I think that's the only way to go! Thomas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 02:08:18 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 02:08:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29Sq-0004Pb-5g; Sat, 20 Dec 2014 02:08:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29So-0004PW-HT for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 02:08:14 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 67/0B-02953-D0AD4945; Sat, 20 Dec 2014 02:08:13 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1419041292!16289979!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14252 invoked from network); 20 Dec 2014 02:08:13 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 02:08:13 -0000 Received: by mail-wg0-f48.google.com with SMTP id y19so2693722wgg.21 for ; Fri, 19 Dec 2014 18:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b6QQRDAjmvVswBGDGCNkfAOcK4rZYCJo/bLVU0TRhLU=; b=Ru4Am/11jPqUvmqdFb5l5x75txKlcxP5N4svCoLe2JJdtXPnVnteJRkmt23tRRt/z6 6wzDLKeaYIWIq9/lAKAJDg2KRzQPIP0hVWSDs0hWR4mKUh2BlkQ92RGF+pre8Ra2yRm7 jlmF7o+T0LqctoQk9rJ4QEVs+sqqj76aOPsQr8711nVQPcLWjv8z0iSuEgvIBR7RfTNv zl82GNYivQCoE4uTZdCQki5rLfFwyeyimS4MsAljPd3tNeIivnUk/zFiVn1ESNepJnhp KkLTa4W6SBGRHj/IuvIIlQwC4A+4wj4zkKFckGzTLKn7/IwtxVnN721hF6KL5wuSZ6YP hygw== X-Received: by 10.180.104.65 with SMTP id gc1mr10777128wib.46.1419041292511; Fri, 19 Dec 2014 18:08:12 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id ly9sm14703901wjb.24.2014.12.19.18.08.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 18:08:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: Date: Sat, 20 Dec 2014 02:08:10 +0000 Message-Id: References: To: Anil Madhavapeddy X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] ocaml 4.02 support X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org > - Use Thomas' new CFLAGS infrastructure to compile libasmrun from OCaml as a library just as we do everything else. > > I'd prefer the latter as it gets yet more code out of mirage-platform, and we can still do custom patches via a fork (as we do with openlibm). Thoughts? I think that's the only way to go! Thomas _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 02:18:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 02:18:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29ct-0004ld-7k; Sat, 20 Dec 2014 02:18:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29cr-0004lY-Cv for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 02:18:37 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 13/17-14214-C7CD4945; Sat, 20 Dec 2014 02:18:36 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-206.messagelabs.com!1419041913!14423673!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22114 invoked from network); 20 Dec 2014 02:18:33 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Dec 2014 02:18:33 -0000 Received: from [192.168.0.140] (c-98-248-38-18.hsd1.ca.comcast.net [98.248.38.18]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 45cc6ed4; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 20 Dec 2014 02:24:36 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Dec 2014 18:18:29 -0800 Message-Id: <5DCE9536-C610-4497-A981-13E49C6C2275@recoil.org> References: To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] mirage-www over ipv6 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 19 Dec 2014, at 17:15, Nicolas Ojeda Bar wrote: > > Hi list, > > Just a quick note to let you know that we have mirage-www working over > ipv6 at http://[2001:41c8:21:a::10]. I don't actually have ipv6 right > now, so it would be great if someone who does could confirm that it is > working (or not). > > Some of the needed functionality is not yet exposed by the `mirage` > tool, so if you want to build this you will need patched versions of > `mirage-tcpip`, `ocaml-conduit`, and `mirage-www` which you can obtain > and build as follows: > > ``` > opam pin add tcpip https://github.com/nojb/mirage-tcpip#mirage-www-ipv6 > opam pin add conduit https://github.com/nojb/ocaml-conduit#mirage-www-ipv6 > git clone -b mirage-www-ipv6 https://github.com/nojb/mirage-www > cd mirage-www > make configure > make build > ``` Awesome, it works for me! [avsm@bark ~]$ curl 'http://[2001:41c8:21:a::10]' | head -5 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 8445 100 8445 0 0 56155 0 --:--:-- --:--:-- --:--:-- 56677 I'll get this onto a live deployment of the site shortly :-) -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 02:18:43 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 02:18:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29ct-0004ld-7k; Sat, 20 Dec 2014 02:18:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y29cr-0004lY-Cv for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 02:18:37 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 13/17-14214-C7CD4945; Sat, 20 Dec 2014 02:18:36 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-2.tower-206.messagelabs.com!1419041913!14423673!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22114 invoked from network); 20 Dec 2014 02:18:33 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Dec 2014 02:18:33 -0000 Received: from [192.168.0.140] (c-98-248-38-18.hsd1.ca.comcast.net [98.248.38.18]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 45cc6ed4; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 20 Dec 2014 02:24:36 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Dec 2014 18:18:29 -0800 Message-Id: <5DCE9536-C610-4497-A981-13E49C6C2275@recoil.org> References: To: Nicolas Ojeda Bar X-Mailer: Apple Mail (2.1993) Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] mirage-www over ipv6 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 19 Dec 2014, at 17:15, Nicolas Ojeda Bar wrote: > > Hi list, > > Just a quick note to let you know that we have mirage-www working over > ipv6 at http://[2001:41c8:21:a::10]. I don't actually have ipv6 right > now, so it would be great if someone who does could confirm that it is > working (or not). > > Some of the needed functionality is not yet exposed by the `mirage` > tool, so if you want to build this you will need patched versions of > `mirage-tcpip`, `ocaml-conduit`, and `mirage-www` which you can obtain > and build as follows: > > ``` > opam pin add tcpip https://github.com/nojb/mirage-tcpip#mirage-www-ipv6 > opam pin add conduit https://github.com/nojb/ocaml-conduit#mirage-www-ipv6 > git clone -b mirage-www-ipv6 https://github.com/nojb/mirage-www > cd mirage-www > make configure > make build > ``` Awesome, it works for me! [avsm@bark ~]$ curl 'http://[2001:41c8:21:a::10]' | head -5 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 8445 100 8445 0 0 56155 0 --:--:-- --:--:-- --:--:-- 56677 I'll get this onto a live deployment of the site shortly :-) -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 10:44:54 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 10:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2HWi-0006fZ-Le; Sat, 20 Dec 2014 10:44:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2HWg-0006fU-El for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 10:44:46 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 49/34-02957-D1355945; Sat, 20 Dec 2014 10:44:45 +0000 X-Env-Sender: vb@luminar.eu.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1419072284!16307579!1 X-Originating-IP: [37.187.116.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15370 invoked from network); 20 Dec 2014 10:44:44 -0000 Received: from luminar.eu.org (HELO luminar.eu.org) (37.187.116.20) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Dec 2014 10:44:44 -0000 Received: from [IPv6:2a01:e35:2e2c:85e0:52e5:49ff:fee3:c667] (unknown [IPv6:2a01:e35:2e2c:85e0:52e5:49ff:fee3:c667]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by luminar.eu.org (Postfix) with ESMTPSA id 4842CFF111 for ; Sat, 20 Dec 2014 11:45:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=luminar.eu.org; s=mail; t=1419072352; bh=qBd6Sx0Qw8g5MLhxF3lymQnnCyAZ2vGz8cB709XoLB8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=X8ltpD39HLrplra54r6Rt2igksLgvkRV2uQA+wvWgDhnmrShj6tjLxtJbXtrJOz/2 zkN/5LIB6oFBZXbjLd9a5/CazQPtpq6ffFfbmjBwjyWsnxV9D+hr96mlyW/ua5Ox8m QhUvM7kc14ZfltY7dFFq6C68PNJp816KPhHWMHWo= Message-ID: <5495531B.7040806@luminar.eu.org> Date: Sat, 20 Dec 2014 11:44:43 +0100 From: Vincent Bernardoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: In-Reply-To: Subject: Re: [MirageOS-devel] mirage-www over ipv6 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 20/12/2014 02:15, Nicolas Ojeda Bar wrote: > working (or not). Yay! Working for me, congratulation! -- Vincent _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 10:44:54 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 10:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2HWi-0006fZ-Le; Sat, 20 Dec 2014 10:44:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2HWg-0006fU-El for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 10:44:46 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 49/34-02957-D1355945; Sat, 20 Dec 2014 10:44:45 +0000 X-Env-Sender: vb@luminar.eu.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1419072284!16307579!1 X-Originating-IP: [37.187.116.20] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15370 invoked from network); 20 Dec 2014 10:44:44 -0000 Received: from luminar.eu.org (HELO luminar.eu.org) (37.187.116.20) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Dec 2014 10:44:44 -0000 Received: from [IPv6:2a01:e35:2e2c:85e0:52e5:49ff:fee3:c667] (unknown [IPv6:2a01:e35:2e2c:85e0:52e5:49ff:fee3:c667]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by luminar.eu.org (Postfix) with ESMTPSA id 4842CFF111 for ; Sat, 20 Dec 2014 11:45:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=luminar.eu.org; s=mail; t=1419072352; bh=qBd6Sx0Qw8g5MLhxF3lymQnnCyAZ2vGz8cB709XoLB8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=X8ltpD39HLrplra54r6Rt2igksLgvkRV2uQA+wvWgDhnmrShj6tjLxtJbXtrJOz/2 zkN/5LIB6oFBZXbjLd9a5/CazQPtpq6ffFfbmjBwjyWsnxV9D+hr96mlyW/ua5Ox8m QhUvM7kc14ZfltY7dFFq6C68PNJp816KPhHWMHWo= Message-ID: <5495531B.7040806@luminar.eu.org> Date: Sat, 20 Dec 2014 11:44:43 +0100 From: Vincent Bernardoff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: In-Reply-To: Subject: Re: [MirageOS-devel] mirage-www over ipv6 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 20/12/2014 02:15, Nicolas Ojeda Bar wrote: > working (or not). Yay! Working for me, congratulation! -- Vincent _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 11:52:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 11:52:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2IaU-0000co-3s; Sat, 20 Dec 2014 11:52:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2IaS-0000cj-DT for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 11:52:44 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id AA/79-25727-B0365945; Sat, 20 Dec 2014 11:52:43 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1419076362!14827749!1 X-Originating-IP: [209.85.212.169] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3702 invoked from network); 20 Dec 2014 11:52:42 -0000 Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 11:52:42 -0000 Received: by mail-wi0-f169.google.com with SMTP id r20so6897746wiv.2 for ; Sat, 20 Dec 2014 03:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=JABE3pEKBCXFQgHI1YutdY1IE+GeSfsSnYqUX+G5a6s=; b=Ur8Ail0369lq+jjTDhGXSKwu/Edq6V+CmYpsWeZjiDRClak895yrhekvb8KF8CAkvp nowzhrvDaoyYn9EsCtHYsc5l89T3T7LCYeDlc3We0BCdd3axZnq8EaWmsgF5BgvYNynL 5VpQ4XST7Yp/22HZjcR5SEYrhvS13+9MqDEu5N9pmUQwkG+Sm30epVMPCB9bKQ04Kdfj bEq3K4JZohADpsyOF7Mc7NDg2mCpeSn4oDZ0mxA6E8wEpUrtr0VhaScqB2JVrgBLH96o 0UWmax7QD/Foqa0Q6sNDW99YyuOAojDysWnFAm9MkaUvYznS4C3r4hZKXZI9dSfT5Wo/ QglQ== X-Received: by 10.180.79.200 with SMTP id l8mr9828213wix.65.1419076362241; Sat, 20 Dec 2014 03:52:42 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id d2sm16090231wjs.32.2014.12.20.03.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Dec 2014 03:52:41 -0800 (PST) From: Thomas Gazagnaire Message-Id: Date: Sat, 20 Dec 2014 11:52:39 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] Release of Irmin 0.9.0 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I'm happy to announce the release of the new version of Irmin (0.9.0). It will be shortly available in opam[1]. Docs are available online[2]. Feedback is gladly welcome! If you were using Irmin 0.8.3, the main API changes are: - the way store are created, see examples/ and the examples in the doc[3]: you don't need to instantiate a functor for every new store configuration anymore. - every store operation takes a description of the task (which will show in the related commit messages, if any - I have plan to have a full debug trace in the commit message, but that's not yet there). Again see the examples to see how to do it. - [list] takes only one argument now (previously a list of paths) - add a [remove_rec] function to remove directories - [View], [Sync], [Snapshot], [Dot] are now stand-alone functors that you need to instantiate when needed. Do not hesitate to ask questions on the list if you struggle to update from previous versions of Irmin. The full list of changes: * Improve the efficiency of the Git backend * Expose a cleaner API for the Unix backends * Expose a cleaner public API * Rename `Origin` into `Task` and use it pervasively through the API * Expose a high-level REST API over HTTP (#80) * Fix the Git backend to stop constantly overwrite `.git/HEAD` (#76) * Add a limit on concurrently open files (#93, #75) * Add `remove_rec` to remove directories (#74, #85) * Remove dependency to `core_kernel` (#22, #81) * Remove dependency to `cryptokit and `sha1` and use `nocrypto` instead * Remove dependency to caml4 * Fix writing contents at the root of the store (#73) * More efficient synchronization protocol between Irmin stores (#11) Best, Thomas [1] https://github.com/ocaml/opam-repository/pull/3243 [2] http://samoht.github.io/irmin/Irmin.html (only the doc of the master branch for now on) [3] http://samoht.github.io/irmin/Irmin.html#examples _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 11:52:51 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 11:52:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2IaU-0000co-3s; Sat, 20 Dec 2014 11:52:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2IaS-0000cj-DT for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 11:52:44 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id AA/79-25727-B0365945; Sat, 20 Dec 2014 11:52:43 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1419076362!14827749!1 X-Originating-IP: [209.85.212.169] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3702 invoked from network); 20 Dec 2014 11:52:42 -0000 Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 11:52:42 -0000 Received: by mail-wi0-f169.google.com with SMTP id r20so6897746wiv.2 for ; Sat, 20 Dec 2014 03:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=JABE3pEKBCXFQgHI1YutdY1IE+GeSfsSnYqUX+G5a6s=; b=Ur8Ail0369lq+jjTDhGXSKwu/Edq6V+CmYpsWeZjiDRClak895yrhekvb8KF8CAkvp nowzhrvDaoyYn9EsCtHYsc5l89T3T7LCYeDlc3We0BCdd3axZnq8EaWmsgF5BgvYNynL 5VpQ4XST7Yp/22HZjcR5SEYrhvS13+9MqDEu5N9pmUQwkG+Sm30epVMPCB9bKQ04Kdfj bEq3K4JZohADpsyOF7Mc7NDg2mCpeSn4oDZ0mxA6E8wEpUrtr0VhaScqB2JVrgBLH96o 0UWmax7QD/Foqa0Q6sNDW99YyuOAojDysWnFAm9MkaUvYznS4C3r4hZKXZI9dSfT5Wo/ QglQ== X-Received: by 10.180.79.200 with SMTP id l8mr9828213wix.65.1419076362241; Sat, 20 Dec 2014 03:52:42 -0800 (PST) Received: from [192.168.0.2] (cpc25-cmbg14-2-0-cust121.5-4.cable.virginm.net. [213.106.112.122]) by mx.google.com with ESMTPSA id d2sm16090231wjs.32.2014.12.20.03.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Dec 2014 03:52:41 -0800 (PST) From: Thomas Gazagnaire Message-Id: Date: Sat, 20 Dec 2014 11:52:39 +0000 To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] Release of Irmin 0.9.0 X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org I'm happy to announce the release of the new version of Irmin (0.9.0). It will be shortly available in opam[1]. Docs are available online[2]. Feedback is gladly welcome! If you were using Irmin 0.8.3, the main API changes are: - the way store are created, see examples/ and the examples in the doc[3]: you don't need to instantiate a functor for every new store configuration anymore. - every store operation takes a description of the task (which will show in the related commit messages, if any - I have plan to have a full debug trace in the commit message, but that's not yet there). Again see the examples to see how to do it. - [list] takes only one argument now (previously a list of paths) - add a [remove_rec] function to remove directories - [View], [Sync], [Snapshot], [Dot] are now stand-alone functors that you need to instantiate when needed. Do not hesitate to ask questions on the list if you struggle to update from previous versions of Irmin. The full list of changes: * Improve the efficiency of the Git backend * Expose a cleaner API for the Unix backends * Expose a cleaner public API * Rename `Origin` into `Task` and use it pervasively through the API * Expose a high-level REST API over HTTP (#80) * Fix the Git backend to stop constantly overwrite `.git/HEAD` (#76) * Add a limit on concurrently open files (#93, #75) * Add `remove_rec` to remove directories (#74, #85) * Remove dependency to `core_kernel` (#22, #81) * Remove dependency to `cryptokit and `sha1` and use `nocrypto` instead * Remove dependency to caml4 * Fix writing contents at the root of the store (#73) * More efficient synchronization protocol between Irmin stores (#11) Best, Thomas [1] https://github.com/ocaml/opam-repository/pull/3243 [2] http://samoht.github.io/irmin/Irmin.html (only the doc of the master branch for now on) [3] http://samoht.github.io/irmin/Irmin.html#examples _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 17:07:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 17:07:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2NUZ-0002pb-24; Sat, 20 Dec 2014 17:06:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2NUX-0002pW-KU for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 17:06:57 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id D7/8D-09842-0BCA5945; Sat, 20 Dec 2014 17:06:56 +0000 X-Env-Sender: h.rotsos@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1419095213!8926331!1 X-Originating-IP: [209.85.218.50] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30339 invoked from network); 20 Dec 2014 17:06:54 -0000 Received: from mail-oi0-f50.google.com (HELO mail-oi0-f50.google.com) (209.85.218.50) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 17:06:54 -0000 Received: by mail-oi0-f50.google.com with SMTP id x69so5436283oia.9 for ; Sat, 20 Dec 2014 09:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ok/6TvjNkTQNN2yGb0hFqvNEUEFiIGLgfl2bMnGWydk=; b=lTUfz7RZFYew7AMsxfoV0EHbEfTY01UeFFXr+Cd3IZ4GBJ//cYK8yIpgzfo9P6spgu hhtkuaByFYqd9s1P7d/vmQmtfrpLgGnnM8nDgabqIjLtq3hjd0wYLtqkqBz4pP7LlC4f QcjEI4R5rjzJ1i2QKoZzBO7avh9Fwd7t9vgOKlNMaBouasiSxwW0dQqQhyK1mFIYbuR3 RDssEs8WZsVUloh7XghJOBKlUmRPuj5mfOYXQoZLMNmLb1fdz36AicJnlSAB59rd07t0 FfWCIbk+Wpcjdp3dg28lXVYsP32z86WuhKZhhIVpdoZwrP3baj2PGh0BL7MMnfJ5Qz6V oFrQ== MIME-Version: 1.0 X-Received: by 10.60.63.168 with SMTP id h8mr8298088oes.74.1419095213349; Sat, 20 Dec 2014 09:06:53 -0800 (PST) Received: by 10.60.174.101 with HTTP; Sat, 20 Dec 2014 09:06:53 -0800 (PST) In-Reply-To: <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> Date: Sat, 20 Dec 2014 19:06:53 +0200 X-Google-Sender-Auth: 7BOwdfLAxSiFbCJm6IlUe2itS4I Message-ID: From: Haris Rotsos To: Anil Madhavapeddy Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2852731168877390747==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2852731168877390747== Content-Type: multipart/alternative; boundary=001a11c255c2182358050aa8da55 --001a11c255c2182358050aa8da55 Content-Type: text/plain; charset=UTF-8 I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid. I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel. if you check https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory. >From a design point of view the best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed as a handler to ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline. On 20 December 2014 at 00:11, Anil Madhavapeddy wrote: > > The actual definition of these functions is probably in the > mirage/mirage-platform repository at the moment. Look in the xen/ > subdirectory and grep for the C file that contains it. > > We can migrate this library to use xen_cflags and avoid the need for this > repetition quite soon as well. The build hacks are gradually being undone! > > -anil > > > On 19 Dec 2014, at 09:25, Anil Madhavapeddy wrote: > > > > CCing the list. > > > >> On 19 Dec 2014, at 08:49, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >> > >> I have added the function to stub_alloc_pages.c and defined it as > external function in io_page.ml. No problem in installing io_page, but > when compiling the program, I receive the error: > >> > >> undefined reference to `caml_dealloc_page' > >> > >> how do you think I can fix it? > >> > >> Thanks. > >> > >> On 18/12/14 13:46, Anil Madhavapeddy wrote: > >>> Not at the moment, although we could easily add an explicit > deallocator into > >>> Io_page. You need to very careful that the page is not used after its > lifetime, > >>> so more pool-based abstractions are preferred (where the pages are > recycled into > >>> an OCaml-managed data structure and reused rather than GCed). > >>> > >>> You should be able to pump up the amount of RAM the VM gets > temporarily to 4GB > >>> or so -- if the page allocator still remains low, then it's unlikely > to be a GC > >>> issue and an actual leak somewhere due to holding onto references and > keeping > >>> the page live. > >>> > >>> -anil > >>> > >>>> On 18 Dec 2014, at 05:41, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>> > >>>> Is it possible to deallocate an Io_page after packet is send, not to > wait for GC? > >>>> > >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: > >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>>>> I am wondering if the following issue is already addressed: > >>>>>> > >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 > >>>>>> > >>>>>> > https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html > >>>>>> > >>>>> It probably still happens at 64MB of RAM -- it requires some code to > adjust > >>>>> the GC parameters in the OCaml runtime to trigger a collection more > often. > >>>>> It should be harmless however, since (as the bug report observes), a > failure > >>>>> to allocate an Io_page results in a GC compaction that frees up > memory so > >>>>> that the allocation eventually succeeds. > >>>>> > >>>>> Any particular reason for asking -- is the bug affecting your switch > somehow? > >>>>> > >>>>> -anil > >>>> > >>>> > >>>> > >>>> > >>>> This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > >>>> > >>>> This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > >>>> > >> > >> > >> > >> > >> > >> This message and any attachment are intended solely for the addressee > >> and may contain confidential information. If you have received this > >> message in error, please send it back to me, and immediately delete it. > >> Please do not use, copy or disclose the information contained in this > >> message or in any attachment. Any views or opinions expressed by the > >> author of this email do not necessarily reflect the views of the > >> University of Nottingham. > >> > >> This message has been checked for viruses but the contents of an > >> attachment may still contain software viruses which could damage your > >> computer system, you are advised to perform your own checks. Email > >> communications with the University of Nottingham may be monitored as > >> permitted by UK legislation. > >> > > > > > > _______________________________________________ > > MirageOS-devel mailing list > > MirageOS-devel@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Charalampos Rotsos PhD student The University of Cambridge Computer Laboratory William Gates Building JJ Thomson Avenue Cambridge CB3 0FD Phone: +44-(0) 1223 767032 Email: cr409@cl.cam.ac.uk --001a11c255c2182358050aa8da55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am following up to share some experience from when I was= experimenting with the original mirage switch. I also have a few design su= ggestions, but maybe they are invalid.=C2=A0

I think the= problem mentioned in the original mail stems from the way packets are hand= led by a xen unikernel. =C2=A0if you check=C2=A0https://github.com/mirag= e/mirage-net-xen/blob/master/lib/netif.ml on line 300, for each new pac= ket arriving on a VIF, the code will start a thread and ignore the result. = As a result, if you start sending lots of packets to a unikernel and the ma= in processing pipeline cannot keep up with the rate, then new packets are a= llocated and delegated to an handling thread, but these threads will never = return and they will create a huge backlog, which at some point will exhaus= t memory.=C2=A0

From a design point of view the best app= roach to solve this problem, I think, is to create a pool of threads with a= fixed size. If the pool doesn't have a free thread, then the packet is= dropped. Alternatively, the driver can be redesigned to create backpressur= e to the netback and force packets to drop in the Dom0, instead of the unik= ernel, and thus reduce a bit the cpu load. In the past I tried to rewrite t= he rx_poll method, But the problem is that the function that is passed =C2= =A0 as a handler to ack new pages from the netback is not lwt aware, thus y= ou cannot easily integrate some of the lwt asyncronicity in the processing = pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of= these functions is probably in the mirage/mirage-platform repository at th= e moment.=C2=A0 Look in the xen/ subdirectory and grep for the C file that = contains it.

We can migrate this library to use xen_cflags and avoid the need for this r= epetition quite soon as well.=C2=A0 The build hacks are gradually being und= one!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote= :
>>
>> I have added the function to stub_alloc_pages.c and defined it as = external function in io_pag= e.ml. No problem in installing io_page, but when compiling the program,= I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit de= allocator into
>>> Io_page.=C2=A0 You need to very careful that the page is not u= sed after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages= are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).<= br> >>>
>>> You should be able to pump up the amount of RAM the VM gets te= mporarily to 4GB
>>> or so -- if the page allocator still remains low, then it'= s unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto referen= ces and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk&g= t; wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is se= nd, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk= > wrote:
>>>>>> I am wondering if the following issue is already a= ddressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/= 33
>>>>>>
>>>>>> https://lists.cam.ac.uk/p= ipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it require= s some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a co= llection more often.
>>>>> It should be harmless however, since (as the bug repor= t observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that= frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecti= ng your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for th= e addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete it= .=C2=A0 =C2=A0Please do not use, copy or disclose the information contained= in this message or in any attachment.=C2=A0 Any views or opinions expresse= d by the author of this email do not necessarily reflect the views of the U= niversity of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents= of an attachment may still contain software viruses which could damage you= r computer system, you are advised to perform your own checks. Email commun= ications with the University of Nottingham may be monitored as permitted by= UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addres= see
>> and may contain confidential information. If you have received thi= s
>> message in error, please send it back to me, and immediately delet= e it.
>> Please do not use, copy or disclose the information contained in t= his
>> message or in any attachment.=C2=A0 Any views or opinions expresse= d by the
>> author of this email do not necessarily reflect the views of the >> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage y= our
>> computer system, you are advised to perform your own checks. Email=
>> communications with the University of Nottingham may be monitored = as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@= lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/lis= tinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Charalampos Rotsos
PhD student
The Univers= ity of Cambridge
Computer Laboratory
William Gates Building
JJ Tho= mson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Em= ail: cr409@cl.cam.ac.uk
--001a11c255c2182358050aa8da55-- --===============2852731168877390747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2852731168877390747==-- From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 17:07:04 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 17:07:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2NUZ-0002pb-24; Sat, 20 Dec 2014 17:06:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2NUX-0002pW-KU for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 17:06:57 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id D7/8D-09842-0BCA5945; Sat, 20 Dec 2014 17:06:56 +0000 X-Env-Sender: h.rotsos@gmail.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1419095213!8926331!1 X-Originating-IP: [209.85.218.50] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30339 invoked from network); 20 Dec 2014 17:06:54 -0000 Received: from mail-oi0-f50.google.com (HELO mail-oi0-f50.google.com) (209.85.218.50) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 20 Dec 2014 17:06:54 -0000 Received: by mail-oi0-f50.google.com with SMTP id x69so5436283oia.9 for ; Sat, 20 Dec 2014 09:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ok/6TvjNkTQNN2yGb0hFqvNEUEFiIGLgfl2bMnGWydk=; b=lTUfz7RZFYew7AMsxfoV0EHbEfTY01UeFFXr+Cd3IZ4GBJ//cYK8yIpgzfo9P6spgu hhtkuaByFYqd9s1P7d/vmQmtfrpLgGnnM8nDgabqIjLtq3hjd0wYLtqkqBz4pP7LlC4f QcjEI4R5rjzJ1i2QKoZzBO7avh9Fwd7t9vgOKlNMaBouasiSxwW0dQqQhyK1mFIYbuR3 RDssEs8WZsVUloh7XghJOBKlUmRPuj5mfOYXQoZLMNmLb1fdz36AicJnlSAB59rd07t0 FfWCIbk+Wpcjdp3dg28lXVYsP32z86WuhKZhhIVpdoZwrP3baj2PGh0BL7MMnfJ5Qz6V oFrQ== MIME-Version: 1.0 X-Received: by 10.60.63.168 with SMTP id h8mr8298088oes.74.1419095213349; Sat, 20 Dec 2014 09:06:53 -0800 (PST) Received: by 10.60.174.101 with HTTP; Sat, 20 Dec 2014 09:06:53 -0800 (PST) In-Reply-To: <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> Date: Sat, 20 Dec 2014 19:06:53 +0200 X-Google-Sender-Auth: 7BOwdfLAxSiFbCJm6IlUe2itS4I Message-ID: From: Haris Rotsos To: Anil Madhavapeddy Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2852731168877390747==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============2852731168877390747== Content-Type: multipart/alternative; boundary=001a11c255c2182358050aa8da55 --001a11c255c2182358050aa8da55 Content-Type: text/plain; charset=UTF-8 I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid. I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel. if you check https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory. >From a design point of view the best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed as a handler to ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline. On 20 December 2014 at 00:11, Anil Madhavapeddy wrote: > > The actual definition of these functions is probably in the > mirage/mirage-platform repository at the moment. Look in the xen/ > subdirectory and grep for the C file that contains it. > > We can migrate this library to use xen_cflags and avoid the need for this > repetition quite soon as well. The build hacks are gradually being undone! > > -anil > > > On 19 Dec 2014, at 09:25, Anil Madhavapeddy wrote: > > > > CCing the list. > > > >> On 19 Dec 2014, at 08:49, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >> > >> I have added the function to stub_alloc_pages.c and defined it as > external function in io_page.ml. No problem in installing io_page, but > when compiling the program, I receive the error: > >> > >> undefined reference to `caml_dealloc_page' > >> > >> how do you think I can fix it? > >> > >> Thanks. > >> > >> On 18/12/14 13:46, Anil Madhavapeddy wrote: > >>> Not at the moment, although we could easily add an explicit > deallocator into > >>> Io_page. You need to very careful that the page is not used after its > lifetime, > >>> so more pool-based abstractions are preferred (where the pages are > recycled into > >>> an OCaml-managed data structure and reused rather than GCed). > >>> > >>> You should be able to pump up the amount of RAM the VM gets > temporarily to 4GB > >>> or so -- if the page allocator still remains low, then it's unlikely > to be a GC > >>> issue and an actual leak somewhere due to holding onto references and > keeping > >>> the page live. > >>> > >>> -anil > >>> > >>>> On 18 Dec 2014, at 05:41, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>> > >>>> Is it possible to deallocate an Io_page after packet is send, not to > wait for GC? > >>>> > >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: > >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini < > masoud.koleini@nottingham.ac.uk> wrote: > >>>>>> I am wondering if the following issue is already addressed: > >>>>>> > >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 > >>>>>> > >>>>>> > https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html > >>>>>> > >>>>> It probably still happens at 64MB of RAM -- it requires some code to > adjust > >>>>> the GC parameters in the OCaml runtime to trigger a collection more > often. > >>>>> It should be harmless however, since (as the bug report observes), a > failure > >>>>> to allocate an Io_page results in a GC compaction that frees up > memory so > >>>>> that the allocation eventually succeeds. > >>>>> > >>>>> Any particular reason for asking -- is the bug affecting your switch > somehow? > >>>>> > >>>>> -anil > >>>> > >>>> > >>>> > >>>> > >>>> This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this message > in error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > >>>> > >>>> This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > >>>> > >> > >> > >> > >> > >> > >> This message and any attachment are intended solely for the addressee > >> and may contain confidential information. If you have received this > >> message in error, please send it back to me, and immediately delete it. > >> Please do not use, copy or disclose the information contained in this > >> message or in any attachment. Any views or opinions expressed by the > >> author of this email do not necessarily reflect the views of the > >> University of Nottingham. > >> > >> This message has been checked for viruses but the contents of an > >> attachment may still contain software viruses which could damage your > >> computer system, you are advised to perform your own checks. Email > >> communications with the University of Nottingham may be monitored as > >> permitted by UK legislation. > >> > > > > > > _______________________________________________ > > MirageOS-devel mailing list > > MirageOS-devel@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Charalampos Rotsos PhD student The University of Cambridge Computer Laboratory William Gates Building JJ Thomson Avenue Cambridge CB3 0FD Phone: +44-(0) 1223 767032 Email: cr409@cl.cam.ac.uk --001a11c255c2182358050aa8da55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am following up to share some experience from when I was= experimenting with the original mirage switch. I also have a few design su= ggestions, but maybe they are invalid.=C2=A0

I think the= problem mentioned in the original mail stems from the way packets are hand= led by a xen unikernel. =C2=A0if you check=C2=A0https://github.com/mirag= e/mirage-net-xen/blob/master/lib/netif.ml on line 300, for each new pac= ket arriving on a VIF, the code will start a thread and ignore the result. = As a result, if you start sending lots of packets to a unikernel and the ma= in processing pipeline cannot keep up with the rate, then new packets are a= llocated and delegated to an handling thread, but these threads will never = return and they will create a huge backlog, which at some point will exhaus= t memory.=C2=A0

From a design point of view the best app= roach to solve this problem, I think, is to create a pool of threads with a= fixed size. If the pool doesn't have a free thread, then the packet is= dropped. Alternatively, the driver can be redesigned to create backpressur= e to the netback and force packets to drop in the Dom0, instead of the unik= ernel, and thus reduce a bit the cpu load. In the past I tried to rewrite t= he rx_poll method, But the problem is that the function that is passed =C2= =A0 as a handler to ack new pages from the netback is not lwt aware, thus y= ou cannot easily integrate some of the lwt asyncronicity in the processing = pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of= these functions is probably in the mirage/mirage-platform repository at th= e moment.=C2=A0 Look in the xen/ subdirectory and grep for the C file that = contains it.

We can migrate this library to use xen_cflags and avoid the need for this r= epetition quite soon as well.=C2=A0 The build hacks are gradually being und= one!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote= :
>>
>> I have added the function to stub_alloc_pages.c and defined it as = external function in io_pag= e.ml. No problem in installing io_page, but when compiling the program,= I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit de= allocator into
>>> Io_page.=C2=A0 You need to very careful that the page is not u= sed after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages= are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).<= br> >>>
>>> You should be able to pump up the amount of RAM the VM gets te= mporarily to 4GB
>>> or so -- if the page allocator still remains low, then it'= s unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto referen= ces and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk&g= t; wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is se= nd, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk= > wrote:
>>>>>> I am wondering if the following issue is already a= ddressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/= 33
>>>>>>
>>>>>> https://lists.cam.ac.uk/p= ipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it require= s some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a co= llection more often.
>>>>> It should be harmless however, since (as the bug repor= t observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that= frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecti= ng your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for th= e addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete it= .=C2=A0 =C2=A0Please do not use, copy or disclose the information contained= in this message or in any attachment.=C2=A0 Any views or opinions expresse= d by the author of this email do not necessarily reflect the views of the U= niversity of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents= of an attachment may still contain software viruses which could damage you= r computer system, you are advised to perform your own checks. Email commun= ications with the University of Nottingham may be monitored as permitted by= UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addres= see
>> and may contain confidential information. If you have received thi= s
>> message in error, please send it back to me, and immediately delet= e it.
>> Please do not use, copy or disclose the information contained in t= his
>> message or in any attachment.=C2=A0 Any views or opinions expresse= d by the
>> author of this email do not necessarily reflect the views of the >> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage y= our
>> computer system, you are advised to perform your own checks. Email=
>> communications with the University of Nottingham may be monitored = as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@= lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/lis= tinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Charalampos Rotsos
PhD student
The Univers= ity of Cambridge
Computer Laboratory
William Gates Building
JJ Tho= mson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Em= ail: cr409@cl.cam.ac.uk
--001a11c255c2182358050aa8da55-- --===============2852731168877390747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============2852731168877390747==-- From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 17:31:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 17:31:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2Nsg-0003a9-1e; Sat, 20 Dec 2014 17:31:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2Nsf-0003XV-Bi for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 17:31:53 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 22/9B-24859-882B5945; Sat, 20 Dec 2014 17:31:52 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-31.messagelabs.com!1419096709!14863085!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28342 invoked from network); 20 Dec 2014 17:31:50 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Dec 2014 17:31:50 -0000 Received: from [192.168.0.140] (c-98-248-38-18.hsd1.ca.comcast.net [98.248.38.18]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 084648d5; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 20 Dec 2014 17:37:54 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sat, 20 Dec 2014 09:31:45 -0800 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> To: Haris Rotsos X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9220168901003050114==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============9220168901003050114== Content-Type: multipart/alternative; boundary="Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52" --Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is an excellent point -- applying backpressure going back to dom0 = would help balance out load once multiple netfronts come into play. However, the issue with the ring handler being Lwt-aware is that it's = not clear what to do if the function blocks. All subsequent acks would = also be blocked since the ring has to be processed in order (although = the responses on the ring themselves may be out of order). I think we should take a look at the Ring API itself once Dave's = refactoring has landed and is released. A more concurrent API could = push the backpressure to the layer immediately after the Ring ack. -anil > On 20 Dec 2014, at 09:06, Haris Rotsos wrote: >=20 > I am following up to share some experience from when I was = experimenting with the original mirage switch. I also have a few design = suggestions, but maybe they are invalid.=20 >=20 > I think the problem mentioned in the original mail stems from the way = packets are handled by a xen unikernel. if you check = https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml = on = line 300, for each new packet arriving on a VIF, the code will start a = thread and ignore the result. As a result, if you start sending lots of = packets to a unikernel and the main processing pipeline cannot keep up = with the rate, then new packets are allocated and delegated to an = handling thread, but these threads will never return and they will = create a huge backlog, which at some point will exhaust memory.=20 >=20 > =46rom a design point of view the best approach to solve this problem, = I think, is to create a pool of threads with a fixed size. If the pool = doesn't have a free thread, then the packet is dropped. Alternatively, = the driver can be redesigned to create backpressure to the netback and = force packets to drop in the Dom0, instead of the unikernel, and thus = reduce a bit the cpu load. In the past I tried to rewrite the rx_poll = method, But the problem is that the function that is passed as a = handler to ack new pages from the netback is not lwt aware, thus you = cannot easily integrate some of the lwt asyncronicity in the processing = pipeline. >=20 > On 20 December 2014 at 00:11, Anil Madhavapeddy > wrote: > The actual definition of these functions is probably in the = mirage/mirage-platform repository at the moment. Look in the xen/ = subdirectory and grep for the C file that contains it. >=20 > We can migrate this library to use xen_cflags and avoid the need for = this repetition quite soon as well. The build hacks are gradually being = undone! >=20 > -anil >=20 > > On 19 Dec 2014, at 09:25, Anil Madhavapeddy > wrote: > > > > CCing the list. > > > >> On 19 Dec 2014, at 08:49, Masoud Koleini = > wrote: > >> > >> I have added the function to stub_alloc_pages.c and defined it as = external function in io_page.ml . No problem in = installing io_page, but when compiling the program, I receive the error: > >> > >> undefined reference to `caml_dealloc_page' > >> > >> how do you think I can fix it? > >> > >> Thanks. > >> > >> On 18/12/14 13:46, Anil Madhavapeddy wrote: > >>> Not at the moment, although we could easily add an explicit = deallocator into > >>> Io_page. You need to very careful that the page is not used after = its lifetime, > >>> so more pool-based abstractions are preferred (where the pages are = recycled into > >>> an OCaml-managed data structure and reused rather than GCed). > >>> > >>> You should be able to pump up the amount of RAM the VM gets = temporarily to 4GB > >>> or so -- if the page allocator still remains low, then it's = unlikely to be a GC > >>> issue and an actual leak somewhere due to holding onto references = and keeping > >>> the page live. > >>> > >>> -anil > >>> > >>>> On 18 Dec 2014, at 05:41, Masoud Koleini = > wrote: > >>>> > >>>> Is it possible to deallocate an Io_page after packet is send, not = to wait for GC? > >>>> > >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: > >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini = > wrote: > >>>>>> I am wondering if the following issue is already addressed: > >>>>>> > >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 = > >>>>>> > >>>>>> = https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html = > >>>>>> > >>>>> It probably still happens at 64MB of RAM -- it requires some = code to adjust > >>>>> the GC parameters in the OCaml runtime to trigger a collection = more often. > >>>>> It should be harmless however, since (as the bug report = observes), a failure > >>>>> to allocate an Io_page results in a GC compaction that frees up = memory so > >>>>> that the allocation eventually succeeds. > >>>>> > >>>>> Any particular reason for asking -- is the bug affecting your = switch somehow? > >>>>> > >>>>> -anil > >>>> > >>>> > >>>> > >>>> > >>>> This message and any attachment are intended solely for the = addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete = it. Please do not use, copy or disclose the information contained in = this message or in any attachment. Any views or opinions expressed by = the author of this email do not necessarily reflect the views of the = University of Nottingham. > >>>> > >>>> This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your = computer system, you are advised to perform your own checks. Email = communications with the University of Nottingham may be monitored as = permitted by UK legislation. > >>>> > >> > >> > >> > >> > >> > >> This message and any attachment are intended solely for the = addressee > >> and may contain confidential information. If you have received this > >> message in error, please send it back to me, and immediately delete = it. > >> Please do not use, copy or disclose the information contained in = this > >> message or in any attachment. Any views or opinions expressed by = the > >> author of this email do not necessarily reflect the views of the > >> University of Nottingham. > >> > >> This message has been checked for viruses but the contents of an > >> attachment may still contain software viruses which could damage = your > >> computer system, you are advised to perform your own checks. Email > >> communications with the University of Nottingham may be monitored = as > >> permitted by UK legislation. > >> > > > > > > _______________________________________________ > > MirageOS-devel mailing list > > MirageOS-devel@lists.xenproject.org = > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = > > >=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org = > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >=20 >=20 > --=20 > Charalampos Rotsos > PhD student > The University of Cambridge > Computer Laboratory > William Gates Building > JJ Thomson Avenue > Cambridge > CB3 0FD >=20 > Phone: +44-(0) 1223 767032 > Email: cr409@cl.cam.ac.uk --Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is an excellent point -- applying backpressure going = back to dom0 would help balance out load once multiple netfronts come = into play.

However, = the issue with the ring handler being Lwt-aware is that it's not clear = what to do if the function blocks.  All subsequent acks would also = be blocked since the ring has to be processed in order (although the = responses on the ring themselves may be out of order).

I think we should take a = look at the Ring API itself once Dave's refactoring has landed and is = released.  A more concurrent API could push the backpressure to the = layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> = wrote:

I am following up to share some experience from = when I was experimenting with the original mirage switch. I also have a = few design suggestions, but maybe they are invalid. 

I think the problem = mentioned in the original mail stems from the way packets are handled by = a xen unikernel.  if you check https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.= ml on line 300, for each new packet arriving on a VIF, the code will = start a thread and ignore the result. As a result, if you start sending = lots of packets to a unikernel and the main processing pipeline cannot = keep up with the rate, then new packets are allocated and delegated to = an handling thread, but these threads will never return and they will = create a huge backlog, which at some point will exhaust = memory. 

=46rom = a design point of view the best approach to solve this problem, I think, = is to create a pool of threads with a fixed size. If the pool doesn't = have a free thread, then the packet is dropped. Alternatively, the = driver can be redesigned to create backpressure to the netback and force = packets to drop in the Dom0, instead of the unikernel, and thus reduce a = bit the cpu load. In the past I tried to rewrite the rx_poll method, But = the problem is that the function that is passed   as a handler to = ack new pages from the netback is not lwt aware, thus you cannot easily = integrate some of the lwt asyncronicity in the processing = pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy = <anil@recoil.org> = wrote:
The actual definition = of these functions is probably in the mirage/mirage-platform repository = at the moment.  Look in the xen/ subdirectory and grep for the C = file that contains it.

We can migrate this library to use xen_cflags and avoid the need for = this repetition quite soon as well.  The build hacks are gradually = being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> = wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it = as external function in io_page.ml. No problem in installing io_page, but when = compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit = deallocator into
>>> Io_page.  You need to very careful that the page is = not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the = pages are recycled into
>>> an OCaml-managed data structure and reused rather than = GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets = temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's = unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto = references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is = send, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>> I am wondering if the following issue is = already addressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg0010= 4.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it = requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a = collection more often.
>>>>> It should be harmless however, since (as the bug = report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction = that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug = affecting your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for = the addressee and may contain confidential information. If you have = received this message in error, please send it back to me, and = immediately delete it.   Please do not use, copy or disclose = the information contained in this message or in any attachment.  = Any views or opinions expressed by the author of this email do not = necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the = contents of an attachment may still contain software viruses which could = damage your computer system, you are advised to perform your own checks. = Email communications with the University of Nottingham may be monitored = as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the = addressee
>> and may contain confidential information. If you have received = this
>> message in error, please send it back to me, and immediately = delete it.
>> Please do not use, copy or disclose the information contained = in this
>> message or in any attachment.  Any views or opinions = expressed by the
>> author of this email do not necessarily reflect the views of = the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of = an
>> attachment may still contain software viruses which could = damage your
>> computer system, you are advised to perform your own checks. = Email
>> communications with the University of Nottingham may be = monitored as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


--
Charalampos Rotsos
PhD = student
The University of Cambridge
Computer = Laboratory
William Gates Building
JJ Thomson = Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk
=

= --Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52-- --===============9220168901003050114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============9220168901003050114==-- From mirageos-devel-bounces@lists.xenproject.org Sat Dec 20 17:31:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 20 Dec 2014 17:31:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2Nsg-0003a9-1e; Sat, 20 Dec 2014 17:31:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2Nsf-0003XV-Bi for mirageos-devel@lists.xenproject.org; Sat, 20 Dec 2014 17:31:53 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 22/9B-24859-882B5945; Sat, 20 Dec 2014 17:31:52 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-31.messagelabs.com!1419096709!14863085!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28342 invoked from network); 20 Dec 2014 17:31:50 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Dec 2014 17:31:50 -0000 Received: from [192.168.0.140] (c-98-248-38-18.hsd1.ca.comcast.net [98.248.38.18]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 084648d5; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sat, 20 Dec 2014 17:37:54 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Sat, 20 Dec 2014 09:31:45 -0800 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> To: Haris Rotsos X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9220168901003050114==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============9220168901003050114== Content-Type: multipart/alternative; boundary="Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52" --Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is an excellent point -- applying backpressure going back to dom0 = would help balance out load once multiple netfronts come into play. However, the issue with the ring handler being Lwt-aware is that it's = not clear what to do if the function blocks. All subsequent acks would = also be blocked since the ring has to be processed in order (although = the responses on the ring themselves may be out of order). I think we should take a look at the Ring API itself once Dave's = refactoring has landed and is released. A more concurrent API could = push the backpressure to the layer immediately after the Ring ack. -anil > On 20 Dec 2014, at 09:06, Haris Rotsos wrote: >=20 > I am following up to share some experience from when I was = experimenting with the original mirage switch. I also have a few design = suggestions, but maybe they are invalid.=20 >=20 > I think the problem mentioned in the original mail stems from the way = packets are handled by a xen unikernel. if you check = https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml = on = line 300, for each new packet arriving on a VIF, the code will start a = thread and ignore the result. As a result, if you start sending lots of = packets to a unikernel and the main processing pipeline cannot keep up = with the rate, then new packets are allocated and delegated to an = handling thread, but these threads will never return and they will = create a huge backlog, which at some point will exhaust memory.=20 >=20 > =46rom a design point of view the best approach to solve this problem, = I think, is to create a pool of threads with a fixed size. If the pool = doesn't have a free thread, then the packet is dropped. Alternatively, = the driver can be redesigned to create backpressure to the netback and = force packets to drop in the Dom0, instead of the unikernel, and thus = reduce a bit the cpu load. In the past I tried to rewrite the rx_poll = method, But the problem is that the function that is passed as a = handler to ack new pages from the netback is not lwt aware, thus you = cannot easily integrate some of the lwt asyncronicity in the processing = pipeline. >=20 > On 20 December 2014 at 00:11, Anil Madhavapeddy > wrote: > The actual definition of these functions is probably in the = mirage/mirage-platform repository at the moment. Look in the xen/ = subdirectory and grep for the C file that contains it. >=20 > We can migrate this library to use xen_cflags and avoid the need for = this repetition quite soon as well. The build hacks are gradually being = undone! >=20 > -anil >=20 > > On 19 Dec 2014, at 09:25, Anil Madhavapeddy > wrote: > > > > CCing the list. > > > >> On 19 Dec 2014, at 08:49, Masoud Koleini = > wrote: > >> > >> I have added the function to stub_alloc_pages.c and defined it as = external function in io_page.ml . No problem in = installing io_page, but when compiling the program, I receive the error: > >> > >> undefined reference to `caml_dealloc_page' > >> > >> how do you think I can fix it? > >> > >> Thanks. > >> > >> On 18/12/14 13:46, Anil Madhavapeddy wrote: > >>> Not at the moment, although we could easily add an explicit = deallocator into > >>> Io_page. You need to very careful that the page is not used after = its lifetime, > >>> so more pool-based abstractions are preferred (where the pages are = recycled into > >>> an OCaml-managed data structure and reused rather than GCed). > >>> > >>> You should be able to pump up the amount of RAM the VM gets = temporarily to 4GB > >>> or so -- if the page allocator still remains low, then it's = unlikely to be a GC > >>> issue and an actual leak somewhere due to holding onto references = and keeping > >>> the page live. > >>> > >>> -anil > >>> > >>>> On 18 Dec 2014, at 05:41, Masoud Koleini = > wrote: > >>>> > >>>> Is it possible to deallocate an Io_page after packet is send, not = to wait for GC? > >>>> > >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: > >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini = > wrote: > >>>>>> I am wondering if the following issue is already addressed: > >>>>>> > >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 = > >>>>>> > >>>>>> = https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html = > >>>>>> > >>>>> It probably still happens at 64MB of RAM -- it requires some = code to adjust > >>>>> the GC parameters in the OCaml runtime to trigger a collection = more often. > >>>>> It should be harmless however, since (as the bug report = observes), a failure > >>>>> to allocate an Io_page results in a GC compaction that frees up = memory so > >>>>> that the allocation eventually succeeds. > >>>>> > >>>>> Any particular reason for asking -- is the bug affecting your = switch somehow? > >>>>> > >>>>> -anil > >>>> > >>>> > >>>> > >>>> > >>>> This message and any attachment are intended solely for the = addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete = it. Please do not use, copy or disclose the information contained in = this message or in any attachment. Any views or opinions expressed by = the author of this email do not necessarily reflect the views of the = University of Nottingham. > >>>> > >>>> This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your = computer system, you are advised to perform your own checks. Email = communications with the University of Nottingham may be monitored as = permitted by UK legislation. > >>>> > >> > >> > >> > >> > >> > >> This message and any attachment are intended solely for the = addressee > >> and may contain confidential information. If you have received this > >> message in error, please send it back to me, and immediately delete = it. > >> Please do not use, copy or disclose the information contained in = this > >> message or in any attachment. Any views or opinions expressed by = the > >> author of this email do not necessarily reflect the views of the > >> University of Nottingham. > >> > >> This message has been checked for viruses but the contents of an > >> attachment may still contain software viruses which could damage = your > >> computer system, you are advised to perform your own checks. Email > >> communications with the University of Nottingham may be monitored = as > >> permitted by UK legislation. > >> > > > > > > _______________________________________________ > > MirageOS-devel mailing list > > MirageOS-devel@lists.xenproject.org = > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = > > >=20 >=20 > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org = > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >=20 >=20 > --=20 > Charalampos Rotsos > PhD student > The University of Cambridge > Computer Laboratory > William Gates Building > JJ Thomson Avenue > Cambridge > CB3 0FD >=20 > Phone: +44-(0) 1223 767032 > Email: cr409@cl.cam.ac.uk --Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is an excellent point -- applying backpressure going = back to dom0 would help balance out load once multiple netfronts come = into play.

However, = the issue with the ring handler being Lwt-aware is that it's not clear = what to do if the function blocks.  All subsequent acks would also = be blocked since the ring has to be processed in order (although the = responses on the ring themselves may be out of order).

I think we should take a = look at the Ring API itself once Dave's refactoring has landed and is = released.  A more concurrent API could push the backpressure to the = layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> = wrote:

I am following up to share some experience from = when I was experimenting with the original mirage switch. I also have a = few design suggestions, but maybe they are invalid. 

I think the problem = mentioned in the original mail stems from the way packets are handled by = a xen unikernel.  if you check https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.= ml on line 300, for each new packet arriving on a VIF, the code will = start a thread and ignore the result. As a result, if you start sending = lots of packets to a unikernel and the main processing pipeline cannot = keep up with the rate, then new packets are allocated and delegated to = an handling thread, but these threads will never return and they will = create a huge backlog, which at some point will exhaust = memory. 

=46rom = a design point of view the best approach to solve this problem, I think, = is to create a pool of threads with a fixed size. If the pool doesn't = have a free thread, then the packet is dropped. Alternatively, the = driver can be redesigned to create backpressure to the netback and force = packets to drop in the Dom0, instead of the unikernel, and thus reduce a = bit the cpu load. In the past I tried to rewrite the rx_poll method, But = the problem is that the function that is passed   as a handler to = ack new pages from the netback is not lwt aware, thus you cannot easily = integrate some of the lwt asyncronicity in the processing = pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy = <anil@recoil.org> = wrote:
The actual definition = of these functions is probably in the mirage/mirage-platform repository = at the moment.  Look in the xen/ subdirectory and grep for the C = file that contains it.

We can migrate this library to use xen_cflags and avoid the need for = this repetition quite soon as well.  The build hacks are gradually = being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> = wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it = as external function in io_page.ml. No problem in installing io_page, but when = compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit = deallocator into
>>> Io_page.  You need to very careful that the page is = not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the = pages are recycled into
>>> an OCaml-managed data structure and reused rather than = GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets = temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's = unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto = references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is = send, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>> I am wondering if the following issue is = already addressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg0010= 4.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it = requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a = collection more often.
>>>>> It should be harmless however, since (as the bug = report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction = that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug = affecting your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for = the addressee and may contain confidential information. If you have = received this message in error, please send it back to me, and = immediately delete it.   Please do not use, copy or disclose = the information contained in this message or in any attachment.  = Any views or opinions expressed by the author of this email do not = necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the = contents of an attachment may still contain software viruses which could = damage your computer system, you are advised to perform your own checks. = Email communications with the University of Nottingham may be monitored = as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the = addressee
>> and may contain confidential information. If you have received = this
>> message in error, please send it back to me, and immediately = delete it.
>> Please do not use, copy or disclose the information contained = in this
>> message or in any attachment.  Any views or opinions = expressed by the
>> author of this email do not necessarily reflect the views of = the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of = an
>> attachment may still contain software viruses which could = damage your
>> computer system, you are advised to perform your own checks. = Email
>> communications with the University of Nottingham may be = monitored as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


--
Charalampos Rotsos
PhD = student
The University of Cambridge
Computer = Laboratory
William Gates Building
JJ Thomson = Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk
=

= --Apple-Mail=_E0F624B0-954F-4D25-8C23-B7CB223BDB52-- --===============9220168901003050114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============9220168901003050114==-- From mirageos-devel-bounces@lists.xenproject.org Sun Dec 21 22:39:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 21 Dec 2014 22:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2pAH-0002sz-Dv; Sun, 21 Dec 2014 22:39:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2pAG-0002su-2X for mirageos-devel@lists.xenproject.org; Sun, 21 Dec 2014 22:39:52 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 24/BB-07724-73C47945; Sun, 21 Dec 2014 22:39:51 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1419201588!14956014!1 X-Originating-IP: [209.85.220.50] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12487 invoked from network); 21 Dec 2014 22:39:49 -0000 Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 21 Dec 2014 22:39:49 -0000 Received: by mail-pa0-f50.google.com with SMTP id bj1so4735723pad.9 for ; Sun, 21 Dec 2014 14:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VGREIQeyn+aYsnTYJWAzNQ4jc8uMlx8TuZDvP5/4NxY=; b=ZLBVjzbLUniePI1wqbfNvSXlGi4DkUaPTC0tDUseQ8l9YZTy9bsaRqO6RaP8sDBWTX 9qf1sHCOG5+pDkK1VY65JmHgH38dMbJoulCdJl23ODFPfaIWE/WKI5ZJMFQMW9OP4etH FPiArvYrELTct9D/vdGlxHXP+J9S015RUSqNmhuZuuWbtyty6ygw6Bd5mdcU61gxgt/S Y9fxHmbdQKVTR0yZNQ2cOLS3/SjV6sSzoa0/d1/XGEuNkqHjf1NqjpoCis5i/8VWzkVY Nf9zWGSvj3dPeQUR4DVtbCjPgBGG5695pE1A0SodrcjTDY0RyXX8ddAXayqqrwtpz7Li Yi1Q== MIME-Version: 1.0 X-Received: by 10.70.90.10 with SMTP id bs10mr29885796pdb.165.1419201587670; Sun, 21 Dec 2014 14:39:47 -0800 (PST) Received: by 10.70.93.65 with HTTP; Sun, 21 Dec 2014 14:39:47 -0800 (PST) In-Reply-To: References: <546CCAB1.5050202@mehnert.org> <75FF7C1E-15BB-4E51-8973-7399B873133D@recoil.org> <718D811F-7444-4D17-8AC6-BEF84EF072A7@recoil.org> <546F1448.80007@mehnert.org> <54730077.8070103@mehnert.org> Date: Sun, 21 Dec 2014 22:39:47 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy Cc: david , Nicolas Ojeda Bar , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] mirage-entropy design proposal X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5732119533990542528==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============5732119533990542528== Content-Type: multipart/alternative; boundary=001a11c223107f75a6050ac19eb3 --001a11c223107f75a6050ac19eb3 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 24, 2014 at 10:09 AM, Anil Madhavapeddy wrote: > > On 24 Nov 2014, at 09:55, Hannes Mehnert wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA384 > > > > Hi, > > > > let me try to summarise the entropy sources: > > a) configuration-time compiled-in random (patch from nic) > > b) gettimeofday seeded (OCaml) Random (current code in > mirage-entropy-xen) > > > > c) adapt Lwt engine loop to feed some bits of entropy (david > > suggested, PR to lwt) > > d) xenstore/vchan continuously feeding entropy from dom0 (dave is > > working on that) > I've now got a prototype of this. There's now a daemon called "xentropyd" which watches for domains being created and connects to them, offering them entropy. The entropy is read from /dev/urandom through a rate-limiter and sent to the domain over a secondary console ring. To give it a go try: opam remote add mirage-dev-dave git://github.com/djs55/mirage-dev#xentropyd # install the depexts, mainly the xenctrl.h header: # apt-get install `opam install xentropyd -e ubuntu` opam install xentropyd You can then run ~/.opam/system/bin/xentropyd as root in domain 0. It'll print debug to stdout by default. git clone git://github.com/mirage/mirage-skeleton cd mirage-skeleton/entropy mirage configure --xen mirage build This example simply prints a chunk of received entropy to the console. The main outstanding question is what should the default mirage-entropy-xen behaviour be? I've created an RFC-style patch which shows how to use the new entropy source: https://github.com/mirage/mirage-entropy/pull/8 It's intended more for discussion than merging since it creates a hard dependency on xentropyd. Cheers, Dave > > e) rdrand (code https://github.com/TimKnast/ocaml-rdseed) > > Following on from a), we could also dump random data in a block device > at image build-tiem, and delete it whenever it's read. > > > > > Let me remark that a and b can only be used for initial seeding (there > > isn't any more entropy to get from these later)! Also, using only one > > entropy source alone is not a good idea. > > Absolutely. > > > > > Now some real-world cases (only Xen-based, in unix land it's simple > > (rely on host /dev/(u)random)!): > > 1) ARM (cubieboard, full control over dom0 [no time]): a, c, d > > 2) X86 (server hosting, full control over dom0): a, b, c, d, e? > > 3) X86 (cloud hosting, no control over dom0): a, b, c, e? > > > > I still think 3 is a bit weak (esp if rdrand is not available) -- the > > solution I can think of right now is to come up with a deployment > > service, which receives unikernels and has API keys to deploy the > > image(s). This service has to be hosted on a machine with real > > entropy, and dumps some of its entropy into the image. It has to > > ensure that every image is deployed only once (or: each image to be > > deployed is first modified to contain some fresh random data). This > > would give us sth similar to /var/db/entropy/ (where the seed is saved > > during shutdown, fed into the RNG during startup). > > Related to above, except the first revision doesn't need machine<->machine > comms > > Anil > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Dave Scott --001a11c223107f75a6050ac19eb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 24, 2014 at 10:09 AM, Anil Madhavapeddy &= lt;anil@recoil.org= > wrote:
On 24 Nov 2014, at 09:5= 5, Hannes Mehnert <hannes@mehnert.= org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
> Hi,
>
> let me try to summarise the entropy sources:
> a) configuration-time compiled-in random (patch from nic)
> b) gettimeofday seeded (OCaml) Random (current code in mirage-entropy-= xen)
>
> c) adapt Lwt engine loop to feed some bits of entropy (david
> suggested, PR to lwt)
> d) xenstore/vchan continuously feeding entropy from dom0 (dave is
> working on that)

I've n= ow got a prototype of this. There's now a daemon called "xentropyd= " which watches for domains being created and connects to them, offeri= ng them entropy. The entropy is read from /dev/urandom through a rate-limit= er and sent to the domain over a secondary console ring.

To give it a go try:

opam remote add mirage= -dev-dave git://gi= thub.com/djs55/mirage-dev#xentropyd
# install the depexts, ma= inly the xenctrl.h header:
# apt-get install `opam install xentro= pyd -e ubuntu`
opam install xentropyd

Yo= u can then run=C2=A0~/.opam/system/bin/xentropyd as root in domain 0. It= 9;ll print debug to stdout by default.

cd mirage-skeleton/entropy
mirage = configure --xen
mirage build

This exampl= e simply prints a chunk of received entropy to the console.

<= /div>
The main outstanding question is what should the default mirage-e= ntropy-xen behaviour be? I've created an RFC-style patch which shows ho= w to use the new entropy source:


It's intended more for= discussion than merging since it creates a hard dependency on xentropyd.

Cheers,
Dave

=C2= =A0
> e) rdrand (code https://github.com/TimKnast/ocaml-rdseed)

Following on from a), we could also dump random data in a block devi= ce
at image build-tiem, and delete it whenever it's read.

>
> Let me remark that a and b can only be used for initial seeding (there=
> isn't any more entropy to get from these later)! Also, using only = one
> entropy source alone is not a good idea.

Absolutely.

>
> Now some real-world cases (only Xen-based, in unix land it's simpl= e
> (rely on host /dev/(u)random)!):
> 1) ARM (cubieboard, full control over dom0 [no time]): a, c, d
> 2) X86 (server hosting, full control over dom0): a, b, c, d, e?
> 3) X86 (cloud hosting, no control over dom0): a, b, c, e?
>
> I still think 3 is a bit weak (esp if rdrand is not available) -- the<= br> > solution I can think of right now is to come up with a deployment
> service, which receives unikernels and has API keys to deploy the
> image(s). This service has to be hosted on a machine with real
> entropy, and dumps some of its entropy into the image. It has to
> ensure that every image is deployed only once (or: each image to be > deployed is first modified to contain some fresh random data). This > would give us sth similar to /var/db/entropy/ (where the seed is saved=
> during shutdown, fed into the RNG during startup).

Related to above, except the first revision doesn't need machine= <->machine
comms

Anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Dave Scott
--001a11c223107f75a6050ac19eb3-- --===============5732119533990542528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5732119533990542528==-- From mirageos-devel-bounces@lists.xenproject.org Sun Dec 21 22:39:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 21 Dec 2014 22:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2pAH-0002sz-Dv; Sun, 21 Dec 2014 22:39:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y2pAG-0002su-2X for mirageos-devel@lists.xenproject.org; Sun, 21 Dec 2014 22:39:52 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 24/BB-07724-73C47945; Sun, 21 Dec 2014 22:39:51 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1419201588!14956014!1 X-Originating-IP: [209.85.220.50] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12487 invoked from network); 21 Dec 2014 22:39:49 -0000 Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 21 Dec 2014 22:39:49 -0000 Received: by mail-pa0-f50.google.com with SMTP id bj1so4735723pad.9 for ; Sun, 21 Dec 2014 14:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VGREIQeyn+aYsnTYJWAzNQ4jc8uMlx8TuZDvP5/4NxY=; b=ZLBVjzbLUniePI1wqbfNvSXlGi4DkUaPTC0tDUseQ8l9YZTy9bsaRqO6RaP8sDBWTX 9qf1sHCOG5+pDkK1VY65JmHgH38dMbJoulCdJl23ODFPfaIWE/WKI5ZJMFQMW9OP4etH FPiArvYrELTct9D/vdGlxHXP+J9S015RUSqNmhuZuuWbtyty6ygw6Bd5mdcU61gxgt/S Y9fxHmbdQKVTR0yZNQ2cOLS3/SjV6sSzoa0/d1/XGEuNkqHjf1NqjpoCis5i/8VWzkVY Nf9zWGSvj3dPeQUR4DVtbCjPgBGG5695pE1A0SodrcjTDY0RyXX8ddAXayqqrwtpz7Li Yi1Q== MIME-Version: 1.0 X-Received: by 10.70.90.10 with SMTP id bs10mr29885796pdb.165.1419201587670; Sun, 21 Dec 2014 14:39:47 -0800 (PST) Received: by 10.70.93.65 with HTTP; Sun, 21 Dec 2014 14:39:47 -0800 (PST) In-Reply-To: References: <546CCAB1.5050202@mehnert.org> <75FF7C1E-15BB-4E51-8973-7399B873133D@recoil.org> <718D811F-7444-4D17-8AC6-BEF84EF072A7@recoil.org> <546F1448.80007@mehnert.org> <54730077.8070103@mehnert.org> Date: Sun, 21 Dec 2014 22:39:47 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy Cc: david , Nicolas Ojeda Bar , "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] mirage-entropy design proposal X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5732119533990542528==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============5732119533990542528== Content-Type: multipart/alternative; boundary=001a11c223107f75a6050ac19eb3 --001a11c223107f75a6050ac19eb3 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 24, 2014 at 10:09 AM, Anil Madhavapeddy wrote: > > On 24 Nov 2014, at 09:55, Hannes Mehnert wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA384 > > > > Hi, > > > > let me try to summarise the entropy sources: > > a) configuration-time compiled-in random (patch from nic) > > b) gettimeofday seeded (OCaml) Random (current code in > mirage-entropy-xen) > > > > c) adapt Lwt engine loop to feed some bits of entropy (david > > suggested, PR to lwt) > > d) xenstore/vchan continuously feeding entropy from dom0 (dave is > > working on that) > I've now got a prototype of this. There's now a daemon called "xentropyd" which watches for domains being created and connects to them, offering them entropy. The entropy is read from /dev/urandom through a rate-limiter and sent to the domain over a secondary console ring. To give it a go try: opam remote add mirage-dev-dave git://github.com/djs55/mirage-dev#xentropyd # install the depexts, mainly the xenctrl.h header: # apt-get install `opam install xentropyd -e ubuntu` opam install xentropyd You can then run ~/.opam/system/bin/xentropyd as root in domain 0. It'll print debug to stdout by default. git clone git://github.com/mirage/mirage-skeleton cd mirage-skeleton/entropy mirage configure --xen mirage build This example simply prints a chunk of received entropy to the console. The main outstanding question is what should the default mirage-entropy-xen behaviour be? I've created an RFC-style patch which shows how to use the new entropy source: https://github.com/mirage/mirage-entropy/pull/8 It's intended more for discussion than merging since it creates a hard dependency on xentropyd. Cheers, Dave > > e) rdrand (code https://github.com/TimKnast/ocaml-rdseed) > > Following on from a), we could also dump random data in a block device > at image build-tiem, and delete it whenever it's read. > > > > > Let me remark that a and b can only be used for initial seeding (there > > isn't any more entropy to get from these later)! Also, using only one > > entropy source alone is not a good idea. > > Absolutely. > > > > > Now some real-world cases (only Xen-based, in unix land it's simple > > (rely on host /dev/(u)random)!): > > 1) ARM (cubieboard, full control over dom0 [no time]): a, c, d > > 2) X86 (server hosting, full control over dom0): a, b, c, d, e? > > 3) X86 (cloud hosting, no control over dom0): a, b, c, e? > > > > I still think 3 is a bit weak (esp if rdrand is not available) -- the > > solution I can think of right now is to come up with a deployment > > service, which receives unikernels and has API keys to deploy the > > image(s). This service has to be hosted on a machine with real > > entropy, and dumps some of its entropy into the image. It has to > > ensure that every image is deployed only once (or: each image to be > > deployed is first modified to contain some fresh random data). This > > would give us sth similar to /var/db/entropy/ (where the seed is saved > > during shutdown, fed into the RNG during startup). > > Related to above, except the first revision doesn't need machine<->machine > comms > > Anil > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Dave Scott --001a11c223107f75a6050ac19eb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 24, 2014 at 10:09 AM, Anil Madhavapeddy &= lt;anil@recoil.org= > wrote:
On 24 Nov 2014, at 09:5= 5, Hannes Mehnert <hannes@mehnert.= org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
> Hi,
>
> let me try to summarise the entropy sources:
> a) configuration-time compiled-in random (patch from nic)
> b) gettimeofday seeded (OCaml) Random (current code in mirage-entropy-= xen)
>
> c) adapt Lwt engine loop to feed some bits of entropy (david
> suggested, PR to lwt)
> d) xenstore/vchan continuously feeding entropy from dom0 (dave is
> working on that)

I've n= ow got a prototype of this. There's now a daemon called "xentropyd= " which watches for domains being created and connects to them, offeri= ng them entropy. The entropy is read from /dev/urandom through a rate-limit= er and sent to the domain over a secondary console ring.

To give it a go try:

opam remote add mirage= -dev-dave git://gi= thub.com/djs55/mirage-dev#xentropyd
# install the depexts, ma= inly the xenctrl.h header:
# apt-get install `opam install xentro= pyd -e ubuntu`
opam install xentropyd

Yo= u can then run=C2=A0~/.opam/system/bin/xentropyd as root in domain 0. It= 9;ll print debug to stdout by default.

cd mirage-skeleton/entropy
mirage = configure --xen
mirage build

This exampl= e simply prints a chunk of received entropy to the console.

<= /div>
The main outstanding question is what should the default mirage-e= ntropy-xen behaviour be? I've created an RFC-style patch which shows ho= w to use the new entropy source:


It's intended more for= discussion than merging since it creates a hard dependency on xentropyd.

Cheers,
Dave

=C2= =A0
> e) rdrand (code https://github.com/TimKnast/ocaml-rdseed)

Following on from a), we could also dump random data in a block devi= ce
at image build-tiem, and delete it whenever it's read.

>
> Let me remark that a and b can only be used for initial seeding (there=
> isn't any more entropy to get from these later)! Also, using only = one
> entropy source alone is not a good idea.

Absolutely.

>
> Now some real-world cases (only Xen-based, in unix land it's simpl= e
> (rely on host /dev/(u)random)!):
> 1) ARM (cubieboard, full control over dom0 [no time]): a, c, d
> 2) X86 (server hosting, full control over dom0): a, b, c, d, e?
> 3) X86 (cloud hosting, no control over dom0): a, b, c, e?
>
> I still think 3 is a bit weak (esp if rdrand is not available) -- the<= br> > solution I can think of right now is to come up with a deployment
> service, which receives unikernels and has API keys to deploy the
> image(s). This service has to be hosted on a machine with real
> entropy, and dumps some of its entropy into the image. It has to
> ensure that every image is deployed only once (or: each image to be > deployed is first modified to contain some fresh random data). This > would give us sth similar to /var/db/entropy/ (where the seed is saved=
> during shutdown, fed into the RNG during startup).

Related to above, except the first revision doesn't need machine= <->machine
comms

Anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--
Dave Scott
--001a11c223107f75a6050ac19eb3-- --===============5732119533990542528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============5732119533990542528==-- From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 10:28:20 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 10:28:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Dn-000404-6e; Mon, 22 Dec 2014 10:28:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Dl-0003zz-Pz for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 10:28:13 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 9F/18-19763-D32F7945; Mon, 22 Dec 2014 10:28:13 +0000 X-Env-Sender: hannes@mehnert.org X-Msg-Ref: server-12.tower-206.messagelabs.com!1419244092!14657398!1 X-Originating-IP: [213.73.89.200] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9178 invoked from network); 22 Dec 2014 10:28:12 -0000 Received: from mail.mehnert.org (HELO mail.mehnert.org) (213.73.89.200) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2014 10:28:12 -0000 Received: from [192.168.1.100] (i5E86D2C4.versanet.de [94.134.210.196]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (verified OK)) by mail.mehnert.org (Postfix) with ESMTPS id 4CCBC16D3 for ; Mon, 22 Dec 2014 11:28:11 +0100 (CET) Message-ID: <5497F222.8060208@mehnert.org> Date: Mon, 22 Dec 2014 11:27:46 +0100 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: <548589E7.8070700@mehnert.org> In-Reply-To: <548589E7.8070700@mehnert.org> Subject: Re: [MirageOS-devel] talk at the 31st chaos communication congress about openmirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 hey again, streaming will be available at http://streaming.media.ccc.de/ .. please note the talk has been scheduled to 27th December at 12:45 (in GMT+1) in Saal 2 (fitting 1500 people) -- one of the first talks directly after the keynote... hannes On 12/08/2014 12:22, Hannes Mehnert wrote: > david kaloper and myself will present mirage (and especially > crypto and security protocols) at the 31st chaos communication > congress (27-30th december in hamburg, germany). > > a preliminary schedule is already published, find our description > at https://events.ccc.de/congress/2014/Fahrplan/events/6443.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJUl/IhAAoJELyJZYjffCjuI1kP/i2frPknkfb0QuK0BNfGrv/w AvmN8ZxgQnNI9qF7XnkwR6yvnRNiS/Xx0hxAFwN7/pmiE1Ew3JyKb3R/0K8csoL4 +GoG3aXK14aHMKQtv2GkOtXrbbovG0pp/C9DuAcwuz7OQs+LKtTQfPDqHHFaHQH7 rLdfKYr/EK8i6IQ2k/n+OeZBxiPR6S6TqRQsOBPK5B+tWbJMHNn7oZsnDYkoh14b 21k1d3TsxDp6ZfagsizWbjnUYfkX0uoGkA20vf+rQGPMUkZ4B2qyQ4xK2f2bdiYx CkvCGcgB6/lSDRBfeiyvzcljFLK/KT2VLwBlzd7LAXMO3UfUs5A9ZtwbUcd13rEm o0y1QcJJ5wVl13gReR556A/nKCAcqYJWqY5a2hNJ1gX2gr2BHYFIIe/JPQoHp6Ag M0o+2Bek0swOIs41WANpD3fnUNUxRldyzIJ0GI0jGIb5RQkIe0It0++D5zIPOib2 M/vkFp9RF89jwXwbiqnw7+T28FXM60LHwD7MWXauAfMXSOQygQxcCDA9+7yXkA5y kW47Q030VY4ewNRz6ZjUtDLJeStmKEL/ranMmLOa3rsl6HDR4E7m5lHUrt9BLLam tvb1N9+eXzkSLXY5S7GalDu2vsMTTBnXtfVulSPv9T+CtI0yj3OAIrQtyQzCFWpe n1I39aM7gY1qR+MjtPIG =dRwR -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 10:28:20 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 10:28:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Dn-000404-6e; Mon, 22 Dec 2014 10:28:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Dl-0003zz-Pz for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 10:28:13 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 9F/18-19763-D32F7945; Mon, 22 Dec 2014 10:28:13 +0000 X-Env-Sender: hannes@mehnert.org X-Msg-Ref: server-12.tower-206.messagelabs.com!1419244092!14657398!1 X-Originating-IP: [213.73.89.200] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9178 invoked from network); 22 Dec 2014 10:28:12 -0000 Received: from mail.mehnert.org (HELO mail.mehnert.org) (213.73.89.200) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2014 10:28:12 -0000 Received: from [192.168.1.100] (i5E86D2C4.versanet.de [94.134.210.196]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (verified OK)) by mail.mehnert.org (Postfix) with ESMTPS id 4CCBC16D3 for ; Mon, 22 Dec 2014 11:28:11 +0100 (CET) Message-ID: <5497F222.8060208@mehnert.org> Date: Mon, 22 Dec 2014 11:27:46 +0100 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: <548589E7.8070700@mehnert.org> In-Reply-To: <548589E7.8070700@mehnert.org> Subject: Re: [MirageOS-devel] talk at the 31st chaos communication congress about openmirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 hey again, streaming will be available at http://streaming.media.ccc.de/ .. please note the talk has been scheduled to 27th December at 12:45 (in GMT+1) in Saal 2 (fitting 1500 people) -- one of the first talks directly after the keynote... hannes On 12/08/2014 12:22, Hannes Mehnert wrote: > david kaloper and myself will present mirage (and especially > crypto and security protocols) at the 31st chaos communication > congress (27-30th december in hamburg, germany). > > a preliminary schedule is already published, find our description > at https://events.ccc.de/congress/2014/Fahrplan/events/6443.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJUl/IhAAoJELyJZYjffCjuI1kP/i2frPknkfb0QuK0BNfGrv/w AvmN8ZxgQnNI9qF7XnkwR6yvnRNiS/Xx0hxAFwN7/pmiE1Ew3JyKb3R/0K8csoL4 +GoG3aXK14aHMKQtv2GkOtXrbbovG0pp/C9DuAcwuz7OQs+LKtTQfPDqHHFaHQH7 rLdfKYr/EK8i6IQ2k/n+OeZBxiPR6S6TqRQsOBPK5B+tWbJMHNn7oZsnDYkoh14b 21k1d3TsxDp6ZfagsizWbjnUYfkX0uoGkA20vf+rQGPMUkZ4B2qyQ4xK2f2bdiYx CkvCGcgB6/lSDRBfeiyvzcljFLK/KT2VLwBlzd7LAXMO3UfUs5A9ZtwbUcd13rEm o0y1QcJJ5wVl13gReR556A/nKCAcqYJWqY5a2hNJ1gX2gr2BHYFIIe/JPQoHp6Ag M0o+2Bek0swOIs41WANpD3fnUNUxRldyzIJ0GI0jGIb5RQkIe0It0++D5zIPOib2 M/vkFp9RF89jwXwbiqnw7+T28FXM60LHwD7MWXauAfMXSOQygQxcCDA9+7yXkA5y kW47Q030VY4ewNRz6ZjUtDLJeStmKEL/ranMmLOa3rsl6HDR4E7m5lHUrt9BLLam tvb1N9+eXzkSLXY5S7GalDu2vsMTTBnXtfVulSPv9T+CtI0yj3OAIrQtyQzCFWpe n1I39aM7gY1qR+MjtPIG =dRwR -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 10:31:27 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 10:31:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Gt-00041r-Ge; Mon, 22 Dec 2014 10:31:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Gr-00041m-Qu for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 10:31:25 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 7D/6A-20609-DF2F7945; Mon, 22 Dec 2014 10:31:25 +0000 X-Env-Sender: hannes@mehnert.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1419244284!16610736!1 X-Originating-IP: [213.73.89.200] X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10918 invoked from network); 22 Dec 2014 10:31:24 -0000 Received: from mail.mehnert.org (HELO mail.mehnert.org) (213.73.89.200) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2014 10:31:24 -0000 Received: from [192.168.1.100] (i5E86D2C4.versanet.de [94.134.210.196]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (verified OK)) by mail.mehnert.org (Postfix) with ESMTPS id 01DF216E1 for ; Mon, 22 Dec 2014 11:31:23 +0100 (CET) Message-ID: <5497F2E2.3020009@mehnert.org> Date: Mon, 22 Dec 2014 11:30:58 +0100 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: In-Reply-To: Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 12/19/2014 18:33, Thomas Leonard wrote: > Now we just need to get Xen support in nocrypto, but that should > be fairly straight-forward. What needs to be done there? Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJUl/LiAAoJELyJZYjffCjul6UP/2EFU1Ww5w1+5rc7OSn59/MB TIxP1bR/irLA77yRNrCTwHMFN9XOU62LTCflZGCseVwvh0nOsR5CJHEvXWGlF7h1 PITttYblR0LelSjArVmAA6sPLEXZdHmqxL2R3WqXkznDWjQ43Mwu7FWyGI49Ajqa RIWoHaNKKZQUYZJZ0rAZ82aamhqfmSaoaj8GabfuhQ4vE0/p7T4BQbjqG1+1WIMm QPPGl4gwIQUqPFgAaUSn5b4P031GLEQe0fd8VTzJHlQntsK4wLzaTHm4JRBVtd8Y ZyHf4k1Out1RrICzLW6acxpAjo1UKI+FRyluhe1tzFAwVg5QO2EaedZnNYV01o67 KY3tNj6vkWMXsoItDoEQsm6lWhvocsb7tv+kLkxpvScRtTPsrdbH7Q72j8BBZyRW fhUTDJ8LZQcNsqUvyIdq79nRHi1uXgYCCKeVRsuR/NkM/FeFd0AxKa4zkHRddHsK xIslJuJsYyvc6AgVcm+U9Yn2APKlY7HSSNSzCJS9GpTXC+AvSUyF5PqDE/VvGmU1 QMfIqPNTOv4WA/BqEcjeX0s2PJhdgZP2WnW3NF1VVDJ1E0EypfHceLyEIvAIxIsb PkurmEznO9fR8nS8oIlsRWQNcen1CGQ0RZVPY6O4Rf8m0HKi3E2uvQ+6sr2REyDU moaJ3CYz3Vt/r+QFQCnN =N93v -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 10:31:27 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 10:31:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Gt-00041r-Ge; Mon, 22 Dec 2014 10:31:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Gr-00041m-Qu for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 10:31:25 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 7D/6A-20609-DF2F7945; Mon, 22 Dec 2014 10:31:25 +0000 X-Env-Sender: hannes@mehnert.org X-Msg-Ref: server-15.tower-27.messagelabs.com!1419244284!16610736!1 X-Originating-IP: [213.73.89.200] X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10918 invoked from network); 22 Dec 2014 10:31:24 -0000 Received: from mail.mehnert.org (HELO mail.mehnert.org) (213.73.89.200) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2014 10:31:24 -0000 Received: from [192.168.1.100] (i5E86D2C4.versanet.de [94.134.210.196]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (verified OK)) by mail.mehnert.org (Postfix) with ESMTPS id 01DF216E1 for ; Mon, 22 Dec 2014 11:31:23 +0100 (CET) Message-ID: <5497F2E2.3020009@mehnert.org> Date: Mon, 22 Dec 2014 11:30:58 +0100 From: Hannes Mehnert User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mirageos-devel@lists.xenproject.org References: In-Reply-To: Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 12/19/2014 18:33, Thomas Leonard wrote: > Now we just need to get Xen support in nocrypto, but that should > be fairly straight-forward. What needs to be done there? Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJUl/LiAAoJELyJZYjffCjul6UP/2EFU1Ww5w1+5rc7OSn59/MB TIxP1bR/irLA77yRNrCTwHMFN9XOU62LTCflZGCseVwvh0nOsR5CJHEvXWGlF7h1 PITttYblR0LelSjArVmAA6sPLEXZdHmqxL2R3WqXkznDWjQ43Mwu7FWyGI49Ajqa RIWoHaNKKZQUYZJZ0rAZ82aamhqfmSaoaj8GabfuhQ4vE0/p7T4BQbjqG1+1WIMm QPPGl4gwIQUqPFgAaUSn5b4P031GLEQe0fd8VTzJHlQntsK4wLzaTHm4JRBVtd8Y ZyHf4k1Out1RrICzLW6acxpAjo1UKI+FRyluhe1tzFAwVg5QO2EaedZnNYV01o67 KY3tNj6vkWMXsoItDoEQsm6lWhvocsb7tv+kLkxpvScRtTPsrdbH7Q72j8BBZyRW fhUTDJ8LZQcNsqUvyIdq79nRHi1uXgYCCKeVRsuR/NkM/FeFd0AxKa4zkHRddHsK xIslJuJsYyvc6AgVcm+U9Yn2APKlY7HSSNSzCJS9GpTXC+AvSUyF5PqDE/VvGmU1 QMfIqPNTOv4WA/BqEcjeX0s2PJhdgZP2WnW3NF1VVDJ1E0EypfHceLyEIvAIxIsb PkurmEznO9fR8nS8oIlsRWQNcen1CGQ0RZVPY6O4Rf8m0HKi3E2uvQ+6sr2REyDU moaJ3CYz3Vt/r+QFQCnN =N93v -----END PGP SIGNATURE----- _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 10:36:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 10:36:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30M0-0004EO-VW; Mon, 22 Dec 2014 10:36:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Ly-0004EC-VO for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 10:36:43 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id FB/C8-25276-A34F7945; Mon, 22 Dec 2014 10:36:42 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1419244599!17189569!1 X-Originating-IP: [209.85.215.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3293 invoked from network); 22 Dec 2014 10:36:40 -0000 Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Dec 2014 10:36:40 -0000 Received: by mail-la0-f42.google.com with SMTP id gd6so3822621lab.1 for ; Mon, 22 Dec 2014 02:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fcTBpK3YqklaGURNU41cn3qIAlKqEMU7s0an/euqx7w=; b=clyDhFUfQjDscDFhI8zYW8j5y1yUx0oBUQthHLpeYCMEJjpTw7s8BTJeUtaRl8mxjF wiO9Xd/qkhoyr8QXMjptRJWjdwJWHzLmuzPgxE+LHmMijgCk7s/jC7VaBGvfWFa0KBD/ m0Ue9eVeP/tdX6USNgxFvAeel3Do1lvgZtpueb8i5ta1P7/QJg8h7+MQDfYHvGYUJL/n T4p4+jWNBY9BaHZRiwFjkL/tK1jjaP+AVlRXZrtXtQIQpSk6GZnH9F0MJ9n8SYfVFhwu vmg1eN9GDTKZ76PWg5Y62Wv4IZUu1cwlGuoRgVQkDHrO1Se9zhEh5QfFC1PDAS43SvQR q0mA== MIME-Version: 1.0 X-Received: by 10.112.63.133 with SMTP id g5mr21245900lbs.33.1419244599588; Mon, 22 Dec 2014 02:36:39 -0800 (PST) Received: by 10.25.207.3 with HTTP; Mon, 22 Dec 2014 02:36:39 -0800 (PST) In-Reply-To: <5497F2E2.3020009@mehnert.org> References: <5497F2E2.3020009@mehnert.org> Date: Mon, 22 Dec 2014 10:36:39 +0000 Message-ID: From: Thomas Leonard To: Hannes Mehnert Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 22 December 2014 at 10:30, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384 > > On 12/19/2014 18:33, Thomas Leonard wrote: >> Now we just need to get Xen support in nocrypto, but that should >> be fairly straight-forward. > > What needs to be done there? Detect if mirage-xen is installed and build a second copy of each object file built against those headers. See tcpip for an example. I'm looking into it now... If you want a quick fix, binaries compiled on ARM Linux will probably work anyway if you just add the xen_linkopts option to the META file (not tested though). -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 10:36:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 10:36:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30M0-0004EO-VW; Mon, 22 Dec 2014 10:36:44 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y30Ly-0004EC-VO for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 10:36:43 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id FB/C8-25276-A34F7945; Mon, 22 Dec 2014 10:36:42 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1419244599!17189569!1 X-Originating-IP: [209.85.215.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3293 invoked from network); 22 Dec 2014 10:36:40 -0000 Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 22 Dec 2014 10:36:40 -0000 Received: by mail-la0-f42.google.com with SMTP id gd6so3822621lab.1 for ; Mon, 22 Dec 2014 02:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fcTBpK3YqklaGURNU41cn3qIAlKqEMU7s0an/euqx7w=; b=clyDhFUfQjDscDFhI8zYW8j5y1yUx0oBUQthHLpeYCMEJjpTw7s8BTJeUtaRl8mxjF wiO9Xd/qkhoyr8QXMjptRJWjdwJWHzLmuzPgxE+LHmMijgCk7s/jC7VaBGvfWFa0KBD/ m0Ue9eVeP/tdX6USNgxFvAeel3Do1lvgZtpueb8i5ta1P7/QJg8h7+MQDfYHvGYUJL/n T4p4+jWNBY9BaHZRiwFjkL/tK1jjaP+AVlRXZrtXtQIQpSk6GZnH9F0MJ9n8SYfVFhwu vmg1eN9GDTKZ76PWg5Y62Wv4IZUu1cwlGuoRgVQkDHrO1Se9zhEh5QfFC1PDAS43SvQR q0mA== MIME-Version: 1.0 X-Received: by 10.112.63.133 with SMTP id g5mr21245900lbs.33.1419244599588; Mon, 22 Dec 2014 02:36:39 -0800 (PST) Received: by 10.25.207.3 with HTTP; Mon, 22 Dec 2014 02:36:39 -0800 (PST) In-Reply-To: <5497F2E2.3020009@mehnert.org> References: <5497F2E2.3020009@mehnert.org> Date: Mon, 22 Dec 2014 10:36:39 +0000 Message-ID: From: Thomas Leonard To: Hannes Mehnert Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 22 December 2014 at 10:30, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA384 > > On 12/19/2014 18:33, Thomas Leonard wrote: >> Now we just need to get Xen support in nocrypto, but that should >> be fairly straight-forward. > > What needs to be done there? Detect if mirage-xen is installed and build a second copy of each object file built against those headers. See tcpip for an example. I'm looking into it now... If you want a quick fix, binaries compiled on ARM Linux will probably work anyway if you just add the xen_linkopts option to the META file (not tested though). -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 12:00:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 12:00:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y31eo-0006yC-6i; Mon, 22 Dec 2014 12:00:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y31en-0006y2-94 for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 12:00:13 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id E8/BA-31453-CC708945; Mon, 22 Dec 2014 12:00:12 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1419249611!10558393!1 X-Originating-IP: [209.85.217.170] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30894 invoked from network); 22 Dec 2014 12:00:12 -0000 Received: from mail-lb0-f170.google.com (HELO mail-lb0-f170.google.com) (209.85.217.170) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 Dec 2014 12:00:12 -0000 Received: by mail-lb0-f170.google.com with SMTP id 10so3787700lbg.29 for ; Mon, 22 Dec 2014 04:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TLNhmIQqP6fx3vI7Qot3JEnT5mMGqsxgTFzDbHDhSdc=; b=suuxciy/t7AFB2HRw8OE2CXOzkKUcgav7Dm3FYDX5yRksRmbRt636qM8HwdbwLlZ/Y NMJqnLFZZFyGHtY9aNsgVMOGxtMpBDvKf70SrM8+pHd5oKgKmXfyILHxk6k0Lemkb3Y+ 9HIadBZ62paZGOscvXCJkSOePoS6Pedqe79fgjh7lyNtUSX8wpdMbkDiAeVVsgVy6+mu X7dKFzjEdn74k0dkoRTGhPCJoeUubAfu9NPPnLn9O6HOX/MxCSQXK3348SuyH5d+EnFf F9Bygvj4Ey1FvK+Z51Bi2VdNiuRLy2GZqb/OOaEsS4u/85huGKdktnPObNW+IRSB1dir 5GtQ== MIME-Version: 1.0 X-Received: by 10.112.150.136 with SMTP id ui8mr21842885lbb.60.1419249611608; Mon, 22 Dec 2014 04:00:11 -0800 (PST) Received: by 10.25.207.3 with HTTP; Mon, 22 Dec 2014 04:00:11 -0800 (PST) In-Reply-To: References: <5497F2E2.3020009@mehnert.org> Date: Mon, 22 Dec 2014 12:00:11 +0000 Message-ID: From: Thomas Leonard To: Hannes Mehnert Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 22 December 2014 at 10:36, Thomas Leonard wrote: > On 22 December 2014 at 10:30, Hannes Mehnert wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA384 >> >> On 12/19/2014 18:33, Thomas Leonard wrote: >>> Now we just need to get Xen support in nocrypto, but that should >>> be fairly straight-forward. >> >> What needs to be done there? > > Detect if mirage-xen is installed and build a second copy of each > object file built against those headers. See tcpip for an example. I'm > looking into it now... https://github.com/mirleft/ocaml-nocrypto/pull/44 -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Mon Dec 22 12:00:19 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 22 Dec 2014 12:00:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y31eo-0006yC-6i; Mon, 22 Dec 2014 12:00:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y31en-0006y2-94 for mirageos-devel@lists.xenproject.org; Mon, 22 Dec 2014 12:00:13 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id E8/BA-31453-CC708945; Mon, 22 Dec 2014 12:00:12 +0000 X-Env-Sender: talex5@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1419249611!10558393!1 X-Originating-IP: [209.85.217.170] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30894 invoked from network); 22 Dec 2014 12:00:12 -0000 Received: from mail-lb0-f170.google.com (HELO mail-lb0-f170.google.com) (209.85.217.170) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 Dec 2014 12:00:12 -0000 Received: by mail-lb0-f170.google.com with SMTP id 10so3787700lbg.29 for ; Mon, 22 Dec 2014 04:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TLNhmIQqP6fx3vI7Qot3JEnT5mMGqsxgTFzDbHDhSdc=; b=suuxciy/t7AFB2HRw8OE2CXOzkKUcgav7Dm3FYDX5yRksRmbRt636qM8HwdbwLlZ/Y NMJqnLFZZFyGHtY9aNsgVMOGxtMpBDvKf70SrM8+pHd5oKgKmXfyILHxk6k0Lemkb3Y+ 9HIadBZ62paZGOscvXCJkSOePoS6Pedqe79fgjh7lyNtUSX8wpdMbkDiAeVVsgVy6+mu X7dKFzjEdn74k0dkoRTGhPCJoeUubAfu9NPPnLn9O6HOX/MxCSQXK3348SuyH5d+EnFf F9Bygvj4Ey1FvK+Z51Bi2VdNiuRLy2GZqb/OOaEsS4u/85huGKdktnPObNW+IRSB1dir 5GtQ== MIME-Version: 1.0 X-Received: by 10.112.150.136 with SMTP id ui8mr21842885lbb.60.1419249611608; Mon, 22 Dec 2014 04:00:11 -0800 (PST) Received: by 10.25.207.3 with HTTP; Mon, 22 Dec 2014 04:00:11 -0800 (PST) In-Reply-To: References: <5497F2E2.3020009@mehnert.org> Date: Mon, 22 Dec 2014 12:00:11 +0000 Message-ID: From: Thomas Leonard To: Hannes Mehnert Cc: "mirageos-devel@lists.xenproject.org" Subject: Re: [MirageOS-devel] TLS on Xen status X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org On 22 December 2014 at 10:36, Thomas Leonard wrote: > On 22 December 2014 at 10:30, Hannes Mehnert wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA384 >> >> On 12/19/2014 18:33, Thomas Leonard wrote: >>> Now we just need to get Xen support in nocrypto, but that should >>> be fairly straight-forward. >> >> What needs to be done there? > > Detect if mirage-xen is installed and build a second copy of each > object file built against those headers. See tcpip for an example. I'm > looking into it now... https://github.com/mirleft/ocaml-nocrypto/pull/44 -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 11:47:44 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 11:47:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3kPi-0004KI-Lu; Wed, 24 Dec 2014 11:47:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3kPh-0004KD-Nq for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 11:47:38 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 5D/AD-03148-8D7AA945; Wed, 24 Dec 2014 11:47:36 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-2.tower-27.messagelabs.com!1419421654!17043219!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_60_70,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23330 invoked from network); 24 Dec 2014 11:47:34 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-2.tower-27.messagelabs.com with SMTP; 24 Dec 2014 11:47:34 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9FB2C36711B_49AA7D6B for ; Wed, 24 Dec 2014 11:47:34 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 4AAEE2C8128_49AA7D6F for ; Wed, 24 Dec 2014 11:47:34 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y3kPe-0002Mo-7I; Wed, 24 Dec 2014 11:47:34 +0000 Message-ID: <549AA7D6.7000906@nottingham.ac.uk> Date: Wed, 24 Dec 2014 11:47:34 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Anil Madhavapeddy , Haris Rotsos References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> In-Reply-To: Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167938967087179773==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============1167938967087179773== Content-Type: multipart/alternative; boundary="------------060108040000070007040205" This is a multi-part message in MIME format. --------------060108040000070007040205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Length: 9493 Content-Transfer-Encoding: quoted-printable Thanks. What is the right way of increasing the size of allocated ring in netif=3F I found that in high packet rate, that would be a limiting factor. On 20/12/14 17:31, Anil Madhavapeddy wrote: > This is an excellent point -- applying backpressure going back to dom0 > would help balance out load once multiple netfronts come into play. > > However, the issue with the ring handler being Lwt-aware is that it's > not clear what to do if the function blocks. All subsequent acks > would also be blocked since the ring has to be processed in order > (although the responses on the ring themselves may be out of order). > > I think we should take a look at the Ring API itself once Dave's > refactoring has landed and is released. A more concurrent API could > push the backpressure to the layer immediately after the Ring ack. > > -anil > >> On 20 Dec 2014, at 09:06, Haris Rotsos > > wrote: >> >> I am following up to share some experience from when I was >> experimenting with the original mirage switch. I also have a few >> design suggestions, but maybe they are invalid. >> >> I think the problem mentioned in the original mail stems from the way >> packets are handled by a xen unikernel. if you check >> https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on >> line 300, for each new packet arriving on a VIF, the code will start >> a thread and ignore the result. As a result, if you start sending >> lots of packets to a unikernel and the main processing pipeline >> cannot keep up with the rate, then new packets are allocated and >> delegated to an handling thread, but these threads will never return >> and they will create a huge backlog, which at some point will exhaust >> memory. >> >> From a design point of view the best approach to solve this problem, >> I think, is to create a pool of threads with a fixed size. If the >> pool doesn't have a free thread, then the packet is dropped. >> Alternatively, the driver can be redesigned to create backpressure to >> the netback and force packets to drop in the Dom0, instead of the >> unikernel, and thus reduce a bit the cpu load. In the past I tried to >> rewrite the rx_poll method, But the problem is that the function that >> is passed as a handler to ack new pages from the netback is not lwt >> aware, thus you cannot easily integrate some of the lwt asyncronicity >> in the processing pipeline. >> >> On 20 December 2014 at 00:11, Anil Madhavapeddy > > wrote: >> >> The actual definition of these functions is probably in the >> mirage/mirage-platform repository at the moment. Look in the >> xen/ subdirectory and grep for the C file that contains it. >> >> We can migrate this library to use xen_cflags and avoid the need >> for this repetition quite soon as well. The build hacks are >> gradually being undone! >> >> -anil >> >> > On 19 Dec 2014, at 09:25, Anil Madhavapeddy > > wrote: >> > >> > CCing the list. >> > >> >> On 19 Dec 2014, at 08:49, Masoud Koleini >> > > wrote: >> >> >> >> I have added the function to stub_alloc_pages.c and defined it >> as external function in io_page.ml . No >> problem in installing io_page, but when compiling the program, I >> receive the error: >> >> >> >> undefined reference to `caml_dealloc_page' >> >> >> >> how do you think I can fix it=3F >> >> >> >> Thanks. >> >> >> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >> >>> Not at the moment, although we could easily add an explicit >> deallocator into >> >>> Io_page. You need to very careful that the page is not used >> after its lifetime, >> >>> so more pool-based abstractions are preferred (where the >> pages are recycled into >> >>> an OCaml-managed data structure and reused rather than GCed). >> >>> >> >>> You should be able to pump up the amount of RAM the VM gets >> temporarily to 4GB >> >>> or so -- if the page allocator still remains low, then it's >> unlikely to be a GC >> >>> issue and an actual leak somewhere due to holding onto >> references and keeping >> >>> the page live. >> >>> >> >>> -anil >> >>> >> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini >> > > wrote: >> >>>> >> >>>> Is it possible to deallocate an Io_page after packet is >> send, not to wait for GC=3F >> >>>> >> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >> >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini >> > > wrote: >> >>>>>> I am wondering if the following issue is already addressed: >> >>>>>> >> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >> >>>>>> >> >>>>>> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> >>>>>> >> >>>>> It probably still happens at 64MB of RAM -- it requires >> some code to adjust >> >>>>> the GC parameters in the OCaml runtime to trigger a >> collection more often. >> >>>>> It should be harmless however, since (as the bug report >> observes), a failure >> >>>>> to allocate an Io_page results in a GC compaction that >> frees up memory so >> >>>>> that the allocation eventually succeeds. >> >>>>> >> >>>>> Any particular reason for asking -- is the bug affecting >> your switch somehow=3F >> >>>>> >> >>>>> -anil >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This message and any attachment are intended solely for the >> addressee and may contain confidential information. If you have >> received this message in error, please send it back to me, and >> immediately delete it. Please do not use, copy or disclose the >> information contained in this message or in any attachment. Any >> views or opinions expressed by the author of this email do not >> necessarily reflect the views of the University of Nottingham. >> >>>> >> >>>> This message has been checked for viruses but the contents >> of an attachment may still contain software viruses which could >> damage your computer system, you are advised to perform your own >> checks. Email communications with the University of Nottingham >> may be monitored as permitted by UK legislation. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> This message and any attachment are intended solely for the >> addressee >> >> and may contain confidential information. If you have received >> this >> >> message in error, please send it back to me, and immediately >> delete it. >> >> Please do not use, copy or disclose the information contained >> in this >> >> message or in any attachment. Any views or opinions expressed >> by the >> >> author of this email do not necessarily reflect the views of the >> >> University of Nottingham. >> >> >> >> This message has been checked for viruses but the contents of an >> >> attachment may still contain software viruses which could >> damage your >> >> computer system, you are advised to perform your own checks. Email >> >> communications with the University of Nottingham may be >> monitored as >> >> permitted by UK legislation. >> >> >> > >> > >> > _______________________________________________ >> > MirageOS-devel mailing list >> > MirageOS-devel@lists.xenproject.org >> >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> >> -- >> Charalampos Rotsos >> PhD student >> The University of Cambridge >> Computer Laboratory >> William Gates Building >> JJ Thomson Avenue >> Cambridge >> CB3 0FD >> >> Phone: +44-(0) 1223 767032 >> Email: cr409@cl.cam.ac.uk > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. --------------060108040000070007040205 Content-Type: text/html; charset=windows-1252 Content-Length: 21437 Content-Transfer-Encoding: quoted-printable Thanks.

What is the right way of increasing the size of allocated ring in netif=3F I found that in high packet rate, that would be a limiting factor.

On 20/12/14 17:31, Anil Madhavapeddy wrote:
This is an excellent point -- applying backpressure going back to dom0 would help balance out load once multiple netfronts come into play.

However, the issue with the ring handler being Lwt-aware is that it's not clear what to do if the function blocks. =A0All subsequent acks would also be blocked since the ring has to be processed in order (although the responses on the ring themselves may be out of order).

I think we should take a look at the Ring API itself once Dave's refactoring has landed and is released. =A0A more concurrent API could push the backpressure to the layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> wrote:

I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid.=A0

I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel. =A0if you check=A0https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory.=A0

From a design point of view the best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed =A0 as a handler to ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment.=A0 Look in the xen/ subdirectory and grep for the C file that contains it.

We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well.=A0 The build hacks are gradually being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it=3F
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit deallocator into
>>> Io_page.=A0 You need to very careful that the page is not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC=3F
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>> I am wondering if the following issue is already addressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a collection more often.
>>>>> It should be harmless however, since (as the bug report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecting your switch somehow=3F
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.=A0 =A0Please do not use, copy or disclose the information contained in this message or in any attachment.=A0 Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.=A0 Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
--------------060108040000070007040205-- --===============1167938967087179773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1167938967087179773==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 11:47:44 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 11:47:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3kPi-0004KI-Lu; Wed, 24 Dec 2014 11:47:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3kPh-0004KD-Nq for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 11:47:38 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 5D/AD-03148-8D7AA945; Wed, 24 Dec 2014 11:47:36 +0000 X-Env-Sender: pszmk1@nottingham.ac.uk X-Msg-Ref: server-2.tower-27.messagelabs.com!1419421654!17043219!1 X-Originating-IP: [128.243.43.121] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_60_70,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23330 invoked from network); 24 Dec 2014 11:47:34 -0000 Received: from uidappmx06.nottingham.ac.uk (HELO uidappmx06.nottingham.ac.uk) (128.243.43.121) by server-2.tower-27.messagelabs.com with SMTP; 24 Dec 2014 11:47:34 -0000 Received: from uidappmx06.nottingham.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9FB2C36711B_49AA7D6B for ; Wed, 24 Dec 2014 11:47:34 +0000 (GMT) Received: from smtp3.nottingham.ac.uk (smtp3.nottingham.ac.uk [128.243.44.55]) by uidappmx06.nottingham.ac.uk (Sophos Email Appliance) with ESMTP id 4AAEE2C8128_49AA7D6F for ; Wed, 24 Dec 2014 11:47:34 +0000 (GMT) Received: from cirrus.cs.nott.ac.uk ([128.243.23.185]) by smtp3.nottingham.ac.uk with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Y3kPe-0002Mo-7I; Wed, 24 Dec 2014 11:47:34 +0000 Message-ID: <549AA7D6.7000906@nottingham.ac.uk> Date: Wed, 24 Dec 2014 11:47:34 +0000 From: Masoud Koleini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Anil Madhavapeddy , Haris Rotsos References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> In-Reply-To: Cc: mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167938967087179773==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org This is a multi-part message in MIME format. --===============1167938967087179773== Content-Type: multipart/alternative; boundary="------------060108040000070007040205" This is a multi-part message in MIME format. --------------060108040000070007040205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Length: 9493 Content-Transfer-Encoding: quoted-printable Thanks. What is the right way of increasing the size of allocated ring in netif=3F I found that in high packet rate, that would be a limiting factor. On 20/12/14 17:31, Anil Madhavapeddy wrote: > This is an excellent point -- applying backpressure going back to dom0 > would help balance out load once multiple netfronts come into play. > > However, the issue with the ring handler being Lwt-aware is that it's > not clear what to do if the function blocks. All subsequent acks > would also be blocked since the ring has to be processed in order > (although the responses on the ring themselves may be out of order). > > I think we should take a look at the Ring API itself once Dave's > refactoring has landed and is released. A more concurrent API could > push the backpressure to the layer immediately after the Ring ack. > > -anil > >> On 20 Dec 2014, at 09:06, Haris Rotsos > > wrote: >> >> I am following up to share some experience from when I was >> experimenting with the original mirage switch. I also have a few >> design suggestions, but maybe they are invalid. >> >> I think the problem mentioned in the original mail stems from the way >> packets are handled by a xen unikernel. if you check >> https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on >> line 300, for each new packet arriving on a VIF, the code will start >> a thread and ignore the result. As a result, if you start sending >> lots of packets to a unikernel and the main processing pipeline >> cannot keep up with the rate, then new packets are allocated and >> delegated to an handling thread, but these threads will never return >> and they will create a huge backlog, which at some point will exhaust >> memory. >> >> From a design point of view the best approach to solve this problem, >> I think, is to create a pool of threads with a fixed size. If the >> pool doesn't have a free thread, then the packet is dropped. >> Alternatively, the driver can be redesigned to create backpressure to >> the netback and force packets to drop in the Dom0, instead of the >> unikernel, and thus reduce a bit the cpu load. In the past I tried to >> rewrite the rx_poll method, But the problem is that the function that >> is passed as a handler to ack new pages from the netback is not lwt >> aware, thus you cannot easily integrate some of the lwt asyncronicity >> in the processing pipeline. >> >> On 20 December 2014 at 00:11, Anil Madhavapeddy > > wrote: >> >> The actual definition of these functions is probably in the >> mirage/mirage-platform repository at the moment. Look in the >> xen/ subdirectory and grep for the C file that contains it. >> >> We can migrate this library to use xen_cflags and avoid the need >> for this repetition quite soon as well. The build hacks are >> gradually being undone! >> >> -anil >> >> > On 19 Dec 2014, at 09:25, Anil Madhavapeddy > > wrote: >> > >> > CCing the list. >> > >> >> On 19 Dec 2014, at 08:49, Masoud Koleini >> > > wrote: >> >> >> >> I have added the function to stub_alloc_pages.c and defined it >> as external function in io_page.ml . No >> problem in installing io_page, but when compiling the program, I >> receive the error: >> >> >> >> undefined reference to `caml_dealloc_page' >> >> >> >> how do you think I can fix it=3F >> >> >> >> Thanks. >> >> >> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >> >>> Not at the moment, although we could easily add an explicit >> deallocator into >> >>> Io_page. You need to very careful that the page is not used >> after its lifetime, >> >>> so more pool-based abstractions are preferred (where the >> pages are recycled into >> >>> an OCaml-managed data structure and reused rather than GCed). >> >>> >> >>> You should be able to pump up the amount of RAM the VM gets >> temporarily to 4GB >> >>> or so -- if the page allocator still remains low, then it's >> unlikely to be a GC >> >>> issue and an actual leak somewhere due to holding onto >> references and keeping >> >>> the page live. >> >>> >> >>> -anil >> >>> >> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini >> > > wrote: >> >>>> >> >>>> Is it possible to deallocate an Io_page after packet is >> send, not to wait for GC=3F >> >>>> >> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >> >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini >> > > wrote: >> >>>>>> I am wondering if the following issue is already addressed: >> >>>>>> >> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >> >>>>>> >> >>>>>> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> >>>>>> >> >>>>> It probably still happens at 64MB of RAM -- it requires >> some code to adjust >> >>>>> the GC parameters in the OCaml runtime to trigger a >> collection more often. >> >>>>> It should be harmless however, since (as the bug report >> observes), a failure >> >>>>> to allocate an Io_page results in a GC compaction that >> frees up memory so >> >>>>> that the allocation eventually succeeds. >> >>>>> >> >>>>> Any particular reason for asking -- is the bug affecting >> your switch somehow=3F >> >>>>> >> >>>>> -anil >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This message and any attachment are intended solely for the >> addressee and may contain confidential information. If you have >> received this message in error, please send it back to me, and >> immediately delete it. Please do not use, copy or disclose the >> information contained in this message or in any attachment. Any >> views or opinions expressed by the author of this email do not >> necessarily reflect the views of the University of Nottingham. >> >>>> >> >>>> This message has been checked for viruses but the contents >> of an attachment may still contain software viruses which could >> damage your computer system, you are advised to perform your own >> checks. Email communications with the University of Nottingham >> may be monitored as permitted by UK legislation. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> This message and any attachment are intended solely for the >> addressee >> >> and may contain confidential information. If you have received >> this >> >> message in error, please send it back to me, and immediately >> delete it. >> >> Please do not use, copy or disclose the information contained >> in this >> >> message or in any attachment. Any views or opinions expressed >> by the >> >> author of this email do not necessarily reflect the views of the >> >> University of Nottingham. >> >> >> >> This message has been checked for viruses but the contents of an >> >> attachment may still contain software viruses which could >> damage your >> >> computer system, you are advised to perform your own checks. Email >> >> communications with the University of Nottingham may be >> monitored as >> >> permitted by UK legislation. >> >> >> > >> > >> > _______________________________________________ >> > MirageOS-devel mailing list >> > MirageOS-devel@lists.xenproject.org >> >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> >> >> >> -- >> Charalampos Rotsos >> PhD student >> The University of Cambridge >> Computer Laboratory >> William Gates Building >> JJ Thomson Avenue >> Cambridge >> CB3 0FD >> >> Phone: +44-(0) 1223 767032 >> Email: cr409@cl.cam.ac.uk > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. --------------060108040000070007040205 Content-Type: text/html; charset=windows-1252 Content-Length: 21437 Content-Transfer-Encoding: quoted-printable Thanks.

What is the right way of increasing the size of allocated ring in netif=3F I found that in high packet rate, that would be a limiting factor.

On 20/12/14 17:31, Anil Madhavapeddy wrote:
This is an excellent point -- applying backpressure going back to dom0 would help balance out load once multiple netfronts come into play.

However, the issue with the ring handler being Lwt-aware is that it's not clear what to do if the function blocks. =A0All subsequent acks would also be blocked since the ring has to be processed in order (although the responses on the ring themselves may be out of order).

I think we should take a look at the Ring API itself once Dave's refactoring has landed and is released. =A0A more concurrent API could push the backpressure to the layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> wrote:

I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid.=A0

I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel. =A0if you check=A0https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory.=A0

From a design point of view the best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed =A0 as a handler to ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment.=A0 Look in the xen/ subdirectory and grep for the C file that contains it.

We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well.=A0 The build hacks are gradually being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it=3F
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit deallocator into
>>> Io_page.=A0 You need to very careful that the page is not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC=3F
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>> I am wondering if the following issue is already addressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a collection more often.
>>>>> It should be harmless however, since (as the bug report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecting your switch somehow=3F
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.=A0 =A0Please do not use, copy or disclose the information contained in this message or in any attachment.=A0 Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.=A0 Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
--------------060108040000070007040205-- --===============1167938967087179773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1167938967087179773==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 16:58:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 16:58:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pGg-0003R1-3F; Wed, 24 Dec 2014 16:58:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pGe-0003Qw-Di for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 16:58:36 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 59/79-19763-BB0FA945; Wed, 24 Dec 2014 16:58:35 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-206.messagelabs.com!1419440313!9687993!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8801 invoked from network); 24 Dec 2014 16:58:33 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2014 16:58:33 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 42b6422d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 24 Dec 2014 17:04:51 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <549AA7D6.7000906@nottingham.ac.uk> Date: Wed, 24 Dec 2014 16:58:30 +0000 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> <549AA7D6.7000906@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: Haris Rotsos , mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6005248481501305767==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6005248481501305767== Content-Type: multipart/alternative; boundary="Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E" --Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Increasing the ring size requires patches to Xen's dom0 as well, and may = not be entirely trivial due to the increase from a single page to = multiple pages. I know that these changes did happen for the blkback = (and Thomas Leonard added indirect block descriptor support to our = blkfront to take advantage), but I don't know if they are supported on = dom0's netback (which is much more latency sensitive). Dave, any idea of the status here? -anil > On 24 Dec 2014, at 11:47, Masoud Koleini = wrote: >=20 > Thanks. >=20 > What is the right way of increasing the size of allocated ring in = netif? I found that in high packet rate, that would be a limiting = factor. >=20 > On 20/12/14 17:31, Anil Madhavapeddy wrote: >> This is an excellent point -- applying backpressure going back to = dom0 would help balance out load once multiple netfronts come into play. >>=20 >> However, the issue with the ring handler being Lwt-aware is that it's = not clear what to do if the function blocks. All subsequent acks would = also be blocked since the ring has to be processed in order (although = the responses on the ring themselves may be out of order). >>=20 >> I think we should take a look at the Ring API itself once Dave's = refactoring has landed and is released. A more concurrent API could = push the backpressure to the layer immediately after the Ring ack. >>=20 >> -anil >>=20 >>> On 20 Dec 2014, at 09:06, Haris Rotsos > wrote: >>>=20 >>> I am following up to share some experience from when I was = experimenting with the original mirage switch. I also have a few design = suggestions, but maybe they are invalid.=20 >>>=20 >>> I think the problem mentioned in the original mail stems from the = way packets are handled by a xen unikernel. if you check = https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml = on = line 300, for each new packet arriving on a VIF, the code will start a = thread and ignore the result. As a result, if you start sending lots of = packets to a unikernel and the main processing pipeline cannot keep up = with the rate, then new packets are allocated and delegated to an = handling thread, but these threads will never return and they will = create a huge backlog, which at some point will exhaust memory.=20 >>>=20 >>> =46rom a design point of view the best approach to solve this = problem, I think, is to create a pool of threads with a fixed size. If = the pool doesn't have a free thread, then the packet is dropped. = Alternatively, the driver can be redesigned to create backpressure to = the netback and force packets to drop in the Dom0, instead of the = unikernel, and thus reduce a bit the cpu load. In the past I tried to = rewrite the rx_poll method, But the problem is that the function that is = passed as a handler to ack new pages from the netback is not lwt = aware, thus you cannot easily integrate some of the lwt asyncronicity in = the processing pipeline. >>>=20 >>> On 20 December 2014 at 00:11, Anil Madhavapeddy > wrote: >>> The actual definition of these functions is probably in the = mirage/mirage-platform repository at the moment. Look in the xen/ = subdirectory and grep for the C file that contains it. >>>=20 >>> We can migrate this library to use xen_cflags and avoid the need for = this repetition quite soon as well. The build hacks are gradually being = undone! >>>=20 >>> -anil >>>=20 >>> > On 19 Dec 2014, at 09:25, Anil Madhavapeddy > wrote: >>> > >>> > CCing the list. >>> > >>> >> On 19 Dec 2014, at 08:49, Masoud Koleini = > wrote: >>> >> >>> >> I have added the function to stub_alloc_pages.c and defined it as = external function in io_page.ml . No problem in = installing io_page, but when compiling the program, I receive the error: >>> >> >>> >> undefined reference to `caml_dealloc_page' >>> >> >>> >> how do you think I can fix it? >>> >> >>> >> Thanks. >>> >> >>> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >>> >>> Not at the moment, although we could easily add an explicit = deallocator into >>> >>> Io_page. You need to very careful that the page is not used = after its lifetime, >>> >>> so more pool-based abstractions are preferred (where the pages = are recycled into >>> >>> an OCaml-managed data structure and reused rather than GCed). >>> >>> >>> >>> You should be able to pump up the amount of RAM the VM gets = temporarily to 4GB >>> >>> or so -- if the page allocator still remains low, then it's = unlikely to be a GC >>> >>> issue and an actual leak somewhere due to holding onto = references and keeping >>> >>> the page live. >>> >>> >>> >>> -anil >>> >>> >>> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini = > wrote: >>> >>>> >>> >>>> Is it possible to deallocate an Io_page after packet is send, = not to wait for GC? >>> >>>> >>> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>> >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini = > wrote: >>> >>>>>> I am wondering if the following issue is already addressed: >>> >>>>>> >>> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 = >>> >>>>>> >>> >>>>>> = https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html = >>> >>>>>> >>> >>>>> It probably still happens at 64MB of RAM -- it requires some = code to adjust >>> >>>>> the GC parameters in the OCaml runtime to trigger a collection = more often. >>> >>>>> It should be harmless however, since (as the bug report = observes), a failure >>> >>>>> to allocate an Io_page results in a GC compaction that frees = up memory so >>> >>>>> that the allocation eventually succeeds. >>> >>>>> >>> >>>>> Any particular reason for asking -- is the bug affecting your = switch somehow? >>> >>>>> >>> >>>>> -anil >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> This message and any attachment are intended solely for the = addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete = it. Please do not use, copy or disclose the information contained in = this message or in any attachment. Any views or opinions expressed by = the author of this email do not necessarily reflect the views of the = University of Nottingham. >>> >>>> >>> >>>> This message has been checked for viruses but the contents of = an attachment may still contain software viruses which could damage your = computer system, you are advised to perform = your own checks. Email communications with the University of Nottingham = may be monitored as permitted by UK legislation. >>> >>>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> This message and any attachment are intended solely for the = addressee >>> >> and may contain confidential information. If you have received = this >>> >> message in error, please send it back to me, and immediately = delete it. >>> >> Please do not use, copy or disclose the information contained in = this >>> >> message or in any attachment. Any views or opinions expressed by = the >>> >> author of this email do not necessarily reflect the views of the >>> >> University of Nottingham. >>> >> >>> >> This message has been checked for viruses but the contents of an >>> >> attachment may still contain software viruses which could damage = your >>> >> computer system, you are advised to perform your own checks. = Email >>> >> communications with the University of Nottingham may be monitored = as >>> >> permitted by UK legislation. >>> >> >>> > >>> > >>> > _______________________________________________ >>> > MirageOS-devel mailing list >>> > MirageOS-devel@lists.xenproject.org = >>> > = http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>> > >>>=20 >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>>=20 >>>=20 >>> --=20 >>> Charalampos Rotsos >>> PhD student >>> The University of Cambridge >>> Computer Laboratory >>> William Gates Building >>> JJ Thomson Avenue >>> Cambridge >>> CB3 0FD >>>=20 >>> Phone: +44-(0) 1223 767032 >>> Email: cr409@cl.cam.ac.uk >=20 >=20 >=20 > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete = it.=20 >=20 > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. >=20 > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. --Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Increasing the ring size requires patches to Xen's dom0 as = well, and may not be entirely trivial due to the increase from a single = page to multiple pages.  I know that these changes did happen for = the blkback (and Thomas Leonard added indirect block descriptor support = to our blkfront to take advantage), but I don't know if they are = supported on dom0's netback (which is much more latency sensitive).

Dave, any idea of the = status here?

-anil

On 24 Dec 2014, at 11:47, = Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:

=20 =20
Thanks.

What is the right way of increasing the size of allocated ring in netif? I found that in high packet rate, that would be a limiting factor.

On 20/12/14 17:31, Anil Madhavapeddy wrote:
This is an excellent point -- applying backpressure going back to dom0 would help balance out load once multiple netfronts come into play.

However, the issue with the ring handler being Lwt-aware is that it's not clear what to do if the function blocks.  All subsequent acks would also be blocked since = the ring has to be processed in order (although the responses on the ring themselves may be out of order).

I think we should take a look at the Ring API = itself once Dave's refactoring has landed and is released.  A more concurrent API could push the backpressure to the layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> wrote:

I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid. 

I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel.  if you = check https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.= ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory. 

=46rom a design point of view the = best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed   as a handler to = ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment.  Look in the xen/ subdirectory and = grep for the C file that contains it.

We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well.  The build hacks are = gradually being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit deallocator into
>>> Io_page.  You need to very careful that the page is not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>> I am wondering if the following issue is already addressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg0010= 4.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a collection more often.
>>>>> It should be harmless however, since (as the bug report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecting your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.  =  Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions = expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  = Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>
>
> = _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk
= 



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.=20=


Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

= --Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E-- --===============6005248481501305767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6005248481501305767==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 16:58:45 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 16:58:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pGg-0003R1-3F; Wed, 24 Dec 2014 16:58:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pGe-0003Qw-Di for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 16:58:36 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 59/79-19763-BB0FA945; Wed, 24 Dec 2014 16:58:35 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-14.tower-206.messagelabs.com!1419440313!9687993!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8801 invoked from network); 24 Dec 2014 16:58:33 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2014 16:58:33 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 42b6422d; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 24 Dec 2014 17:04:51 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <549AA7D6.7000906@nottingham.ac.uk> Date: Wed, 24 Dec 2014 16:58:30 +0000 Message-Id: References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> <549AA7D6.7000906@nottingham.ac.uk> To: Masoud Koleini X-Mailer: Apple Mail (2.1993) Cc: Haris Rotsos , mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6005248481501305767==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============6005248481501305767== Content-Type: multipart/alternative; boundary="Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E" --Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Increasing the ring size requires patches to Xen's dom0 as well, and may = not be entirely trivial due to the increase from a single page to = multiple pages. I know that these changes did happen for the blkback = (and Thomas Leonard added indirect block descriptor support to our = blkfront to take advantage), but I don't know if they are supported on = dom0's netback (which is much more latency sensitive). Dave, any idea of the status here? -anil > On 24 Dec 2014, at 11:47, Masoud Koleini = wrote: >=20 > Thanks. >=20 > What is the right way of increasing the size of allocated ring in = netif? I found that in high packet rate, that would be a limiting = factor. >=20 > On 20/12/14 17:31, Anil Madhavapeddy wrote: >> This is an excellent point -- applying backpressure going back to = dom0 would help balance out load once multiple netfronts come into play. >>=20 >> However, the issue with the ring handler being Lwt-aware is that it's = not clear what to do if the function blocks. All subsequent acks would = also be blocked since the ring has to be processed in order (although = the responses on the ring themselves may be out of order). >>=20 >> I think we should take a look at the Ring API itself once Dave's = refactoring has landed and is released. A more concurrent API could = push the backpressure to the layer immediately after the Ring ack. >>=20 >> -anil >>=20 >>> On 20 Dec 2014, at 09:06, Haris Rotsos > wrote: >>>=20 >>> I am following up to share some experience from when I was = experimenting with the original mirage switch. I also have a few design = suggestions, but maybe they are invalid.=20 >>>=20 >>> I think the problem mentioned in the original mail stems from the = way packets are handled by a xen unikernel. if you check = https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml = on = line 300, for each new packet arriving on a VIF, the code will start a = thread and ignore the result. As a result, if you start sending lots of = packets to a unikernel and the main processing pipeline cannot keep up = with the rate, then new packets are allocated and delegated to an = handling thread, but these threads will never return and they will = create a huge backlog, which at some point will exhaust memory.=20 >>>=20 >>> =46rom a design point of view the best approach to solve this = problem, I think, is to create a pool of threads with a fixed size. If = the pool doesn't have a free thread, then the packet is dropped. = Alternatively, the driver can be redesigned to create backpressure to = the netback and force packets to drop in the Dom0, instead of the = unikernel, and thus reduce a bit the cpu load. In the past I tried to = rewrite the rx_poll method, But the problem is that the function that is = passed as a handler to ack new pages from the netback is not lwt = aware, thus you cannot easily integrate some of the lwt asyncronicity in = the processing pipeline. >>>=20 >>> On 20 December 2014 at 00:11, Anil Madhavapeddy > wrote: >>> The actual definition of these functions is probably in the = mirage/mirage-platform repository at the moment. Look in the xen/ = subdirectory and grep for the C file that contains it. >>>=20 >>> We can migrate this library to use xen_cflags and avoid the need for = this repetition quite soon as well. The build hacks are gradually being = undone! >>>=20 >>> -anil >>>=20 >>> > On 19 Dec 2014, at 09:25, Anil Madhavapeddy > wrote: >>> > >>> > CCing the list. >>> > >>> >> On 19 Dec 2014, at 08:49, Masoud Koleini = > wrote: >>> >> >>> >> I have added the function to stub_alloc_pages.c and defined it as = external function in io_page.ml . No problem in = installing io_page, but when compiling the program, I receive the error: >>> >> >>> >> undefined reference to `caml_dealloc_page' >>> >> >>> >> how do you think I can fix it? >>> >> >>> >> Thanks. >>> >> >>> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >>> >>> Not at the moment, although we could easily add an explicit = deallocator into >>> >>> Io_page. You need to very careful that the page is not used = after its lifetime, >>> >>> so more pool-based abstractions are preferred (where the pages = are recycled into >>> >>> an OCaml-managed data structure and reused rather than GCed). >>> >>> >>> >>> You should be able to pump up the amount of RAM the VM gets = temporarily to 4GB >>> >>> or so -- if the page allocator still remains low, then it's = unlikely to be a GC >>> >>> issue and an actual leak somewhere due to holding onto = references and keeping >>> >>> the page live. >>> >>> >>> >>> -anil >>> >>> >>> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini = > wrote: >>> >>>> >>> >>>> Is it possible to deallocate an Io_page after packet is send, = not to wait for GC? >>> >>>> >>> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >>> >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini = > wrote: >>> >>>>>> I am wondering if the following issue is already addressed: >>> >>>>>> >>> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 = >>> >>>>>> >>> >>>>>> = https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html = >>> >>>>>> >>> >>>>> It probably still happens at 64MB of RAM -- it requires some = code to adjust >>> >>>>> the GC parameters in the OCaml runtime to trigger a collection = more often. >>> >>>>> It should be harmless however, since (as the bug report = observes), a failure >>> >>>>> to allocate an Io_page results in a GC compaction that frees = up memory so >>> >>>>> that the allocation eventually succeeds. >>> >>>>> >>> >>>>> Any particular reason for asking -- is the bug affecting your = switch somehow? >>> >>>>> >>> >>>>> -anil >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> This message and any attachment are intended solely for the = addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete = it. Please do not use, copy or disclose the information contained in = this message or in any attachment. Any views or opinions expressed by = the author of this email do not necessarily reflect the views of the = University of Nottingham. >>> >>>> >>> >>>> This message has been checked for viruses but the contents of = an attachment may still contain software viruses which could damage your = computer system, you are advised to perform = your own checks. Email communications with the University of Nottingham = may be monitored as permitted by UK legislation. >>> >>>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> This message and any attachment are intended solely for the = addressee >>> >> and may contain confidential information. If you have received = this >>> >> message in error, please send it back to me, and immediately = delete it. >>> >> Please do not use, copy or disclose the information contained in = this >>> >> message or in any attachment. Any views or opinions expressed by = the >>> >> author of this email do not necessarily reflect the views of the >>> >> University of Nottingham. >>> >> >>> >> This message has been checked for viruses but the contents of an >>> >> attachment may still contain software viruses which could damage = your >>> >> computer system, you are advised to perform your own checks. = Email >>> >> communications with the University of Nottingham may be monitored = as >>> >> permitted by UK legislation. >>> >> >>> > >>> > >>> > _______________________________________________ >>> > MirageOS-devel mailing list >>> > MirageOS-devel@lists.xenproject.org = >>> > = http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>> > >>>=20 >>>=20 >>> _______________________________________________ >>> MirageOS-devel mailing list >>> MirageOS-devel@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel = >>>=20 >>>=20 >>> --=20 >>> Charalampos Rotsos >>> PhD student >>> The University of Cambridge >>> Computer Laboratory >>> William Gates Building >>> JJ Thomson Avenue >>> Cambridge >>> CB3 0FD >>>=20 >>> Phone: +44-(0) 1223 767032 >>> Email: cr409@cl.cam.ac.uk >=20 >=20 >=20 > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete = it.=20 >=20 > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. >=20 > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. --Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Increasing the ring size requires patches to Xen's dom0 as = well, and may not be entirely trivial due to the increase from a single = page to multiple pages.  I know that these changes did happen for = the blkback (and Thomas Leonard added indirect block descriptor support = to our blkfront to take advantage), but I don't know if they are = supported on dom0's netback (which is much more latency sensitive).

Dave, any idea of the = status here?

-anil

On 24 Dec 2014, at 11:47, = Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:

=20 =20
Thanks.

What is the right way of increasing the size of allocated ring in netif? I found that in high packet rate, that would be a limiting factor.

On 20/12/14 17:31, Anil Madhavapeddy wrote:
This is an excellent point -- applying backpressure going back to dom0 would help balance out load once multiple netfronts come into play.

However, the issue with the ring handler being Lwt-aware is that it's not clear what to do if the function blocks.  All subsequent acks would also be blocked since = the ring has to be processed in order (although the responses on the ring themselves may be out of order).

I think we should take a look at the Ring API = itself once Dave's refactoring has landed and is released.  A more concurrent API could push the backpressure to the layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> wrote:

I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid. 

I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel.  if you = check https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.= ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory. 

=46rom a design point of view the = best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed   as a handler to = ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment.  Look in the xen/ subdirectory and = grep for the C file that contains it.

We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well.  The build hacks are = gradually being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit deallocator into
>>> Io_page.  You need to very careful that the page is not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>>> I am wondering if the following issue is already addressed:
>>>>>>
>>>>>> https://github.com/mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg0010= 4.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a collection more often.
>>>>> It should be harmless however, since (as the bug report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecting your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.  =  Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions = expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  = Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>
>
> = _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-d= evel


--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk
= 



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.=20=


Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

= --Apple-Mail=_FA35E730-BB71-4FDF-9C56-E01D4DB0312E-- --===============6005248481501305767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============6005248481501305767==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 17:12:01 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 17:12:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pTb-0003v3-QH; Wed, 24 Dec 2014 17:11:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pMt-0003ic-8B for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 17:05:04 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id C5/10-26652-E32FA945; Wed, 24 Dec 2014 17:05:02 +0000 X-Env-Sender: avsm2@cl.cam.ac.uk X-Msg-Ref: server-12.tower-206.messagelabs.com!1419440701!15094958!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12358 invoked from network); 24 Dec 2014 17:05:02 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2014 17:05:02 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 70c68dff; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 24 Dec 2014 17:11:20 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5499F549.1010607@cam.ac.uk> Date: Wed, 24 Dec 2014 17:04:58 +0000 Message-Id: <8DF3BE10-1D92-4283-A174-81AF75E9C721@cl.cam.ac.uk> References: <5499F549.1010607@cam.ac.uk> To: "J. Beleites" X-Mailer: Apple Mail (2.1993) X-Mailman-Approved-At: Wed, 24 Dec 2014 17:11:58 +0000 Cc: David Sheets , mirageos-devel Subject: Re: [MirageOS-devel] Installing tls - failing to install ctypes and conf-gmp X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgSm9oYW5uLCAoQ0NpbmcgdGhlIG1pcmFnZW9zLWRldmVsIGxpc3Qgd2hlcmUgc3VjaCBxdWVz dGlvbnMgY2FuIGhlbHAgb3RoZXJzIGFzIHdlbGwpCgpUaGUgZmlyc3QgZXJyb3Igd2l0aCBnbXAg aXMgZHVlIHRvIG5vdCBoYXZpbmcgdGhlIGxpYmdtcCBDIGxpYnJhcnkgaW5zdGFsbGVkLiAgWW91 IGNhbiBnZXQgdGhpcyBvbiBVYnVudHUgYnkgYGFwdC1nZXQgaW5zdGFsbCBsaWJnbXAtZGV2YCAo b3Igc2ltaWxhciwgSSBkb24ndCBoYXZlIGFuIFVidW50dSBib3ggaGFuZHkgdG8gZmluZCBvdXQg YXRtKS4KClRoZSBzZWNvbmQgZXJyb3IgaXMgZHVlIHRvIHlvdSB1c2luZyA0LjAzLjArdHJ1bmsg KHRoZSBibGVlZGluZyBlZGdlIHZlcnNpb24gb2YgT0NhbWwgdGhhdCBpcyB1bnJlbGVhc2VkKS4g IFlvdSBzaG91bGQgdXNlIDQuMDIuMSBvciA0LjAxLjAgaW5zdGVhZCwgYXMgeW91J3JlIG5vdCBk b2luZyBjb21waWxlciBoYWNraW5nIGFuZCBqdXN0IHdhbnQgdG8gdXNlIHRoZSBUTFMgbGlicmFy aWVzIHRoZW1zZWx2ZXMuCgotYW5pbAoKPiBPbiAyMyBEZWMgMjAxNCwgYXQgMjM6MDUsIEouIEJl bGVpdGVzIDxqY2I5OEBjYW0uYWMudWs+IHdyb3RlOgo+IAo+IC0tLS0tQkVHSU4gUEdQIFNJR05F RCBNRVNTQUdFLS0tLS0KPiBIYXNoOiBTSEExCj4gCj4gSGksCj4gCj4gSSd2ZSBiZWVuIHRyeWlu ZyB0byBpbnN0YWxsIG9jYW1sLXRscyB3aXRoICJvcGFtIGluc3RhbGwgdGxzIiBidXQgdGhlCj4g aW5zdGFsbGF0aW9uIGtlZXBzIG9uIGZhaWxpbmcgdG8gaW5zdGFsbCBjdHlwZXMuMC4zLjQgYW5k IGNvbmYtZ21wLjEKPiAodGhpcyBpcyBhbHNvIHRydWUgd2hlbiBJIHRyeSB0byBpbnN0YWxsIGVp dGhlciBvZiB0aGVtIG1hbnVhbGx5KS4KPiBJJ3ZlIHRyaWVkIHVzaW5nIHVzaW5nIG9jYW1sIHZl cnNpb25zIDQuMDEuMCwgNC4wMi4xIGFuZCA0LjAzLjArdHJ1bmsKPiBpZiB0aGF0IG1ha2VzIGFu eSBkaWZmZXJlbmNlLCBhbGwgd2l0aCB0aGUgc2FtZSByZXN1bHQuIEknbSB1c2luZyBvcGFtCj4g MS4yLjAgb24gVWJ1bnR1IDE0LjA0Lgo+IAo+IEZvciBjb25mLWdtcCBJIGtlZXAgb24gZ2V0dGlu ZyB0aGUgZm9sbG93aW5nIGVycm9yIHdoaWxlIHRyeWluZyB0bwo+IGluc3RhbGw6Cj4gCj4gIyB0 ZXN0LmM6MToxNzogZmF0YWwgZXJyb3I6IGdtcC5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 Cj4gIyAgI2luY2x1ZGUgPGdtcC5oPgo+ICMgICAgICAgICAgICAgICAgICBeCj4gIyBjb21waWxh dGlvbiB0ZXJtaW5hdGVkLgo+IAo+IAo+IFRyeWluZyB0byBpbnN0YWxsIGN0eXBlcyBnaXZlczoK PiAKPiAjIC4uLlt0cnVuY2F0ZWRdCj4gIyAgICAgY2FzZSBVaW50NjRfdDogYiA9IGN0eXBlc19j b3B5X3VpbnQ2NCgqKHVpbnQ2NCAqKWJ1Zik7IGJyZWFrOwo+ICMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4KPiAjCj4gL2hvbWUvam9jYmUvLm9w YW0vNC4wMy4wK3RydW5rL2J1aWxkL2N0eXBlcy4wLjMuNC9zcmMvY3R5cGVzL3R5cGVfaW5mb19z dHVicy5jOgo+IEluIGZ1bmN0aW9uIOKAmGN0eXBlc193cml0ZeKAmToKPiAjCj4gL2hvbWUvam9j YmUvLm9wYW0vNC4wMy4wK3RydW5rL2J1aWxkL2N0eXBlcy4wLjMuNC9zcmMvY3R5cGVzL3R5cGVf aW5mb19zdHVicy5jOjkyOjIxOgo+IGVycm9yOiDigJh1aW50NjTigJkgdW5kZWNsYXJlZCAoZmly c3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCj4gIyAgICAgY2FzZSBVaW50NjRfdDogKih1aW50NjQg KilidWYgPSBVaW50NjRfdmFsKHYpOyBicmVhazsKPiAjICAgICAgICAgICAgICAgICAgICAgIF4K PiAjCj4gL2hvbWUvam9jYmUvLm9wYW0vNC4wMy4wK3RydW5rL2J1aWxkL2N0eXBlcy4wLjMuNC9z cmMvY3R5cGVzL3R5cGVfaW5mb19zdHVicy5jOjkyOjI5Ogo+IGVycm9yOiBleHBlY3RlZCBleHBy ZXNzaW9uIGJlZm9yZSDigJgp4oCZIHRva2VuCj4gIyAgICAgY2FzZSBVaW50NjRfdDogKih1aW50 NjQgKilidWYgPSBVaW50NjRfdmFsKHYpOyBicmVhazsKPiAjICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgXgo+ICMgbWFrZTogKioqIFtfYnVpbGQvc3JjL2N0eXBlcy90eXBlX2luZm9fc3R1 YnMub10gRXJyb3IgMgo+IAo+IAo+IEkgYW0gbm90IHN1cmUgd2hhdCBJIGFtIGRvaW5nIHdyb25n LiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nIG9idmlvdXMgaGVyZT8KPiAKPiBUaGFuayB5b3UhIChB bmQgc29ycnkgZm9yIGJvdGhlcmluZyB5b3UgZHVyaW5nIHRoZSBDaHJpc3RtYXMgdGltZSkuCj4g Cj4gSm9oYW5uCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KPiBWZXJzaW9uOiBHbnVQ RyB2MQo+IAo+IGlRRWNCQUVCQWdBR0JRSlVtZlZEQUFvSkVPdVgwd3Y1UGYwSVM4VUgvUkR5RFlu b3hiejdUQTRtZUhFOWhJdTYKPiBwWjVJbVdQekFnZklyNGdodURKUFE0QVpJbXNBcVRHbG92RDc2 R0FubUkweHl6SlFJcmFNblp3bUFBNHBlK29ECj4gKzd5M0hvRkZXTFVtTndYSVczREhJWlljeFdj SllLSG9tRUJMVmpVbDJIT2lzR1JoN2NqK1psZ0lrRTJkS1V0Ngo+IGlpZ045cU8zVE43M25SRjJU R1JLWlp0aHhnbk1pamc5TEhMUEVYUVhDSjJwUE5RS3JaNzU1RUVic3pkaDFsaUcKPiB6c1NTYktE dTNKTHB3YmpsSXpqQnVjQmZxZklBRlBvNGg1QWxkcEhYSHdpSDdMOTNKQmdWRWc5REpsS1JUZ1p5 Cj4gdTBhNmV0N3l4N09YYU5qVTRndVZBYlc5bHU1NG5lUzdkSTJoeFNOL1dkWStWTUpJWWw1NG5z WVRENEZ5M0xVPQo+ID1nZCt2Cj4gLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tCj4gCgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2 ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6 Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3Mt ZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 17:12:01 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 17:12:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pTb-0003v3-QH; Wed, 24 Dec 2014 17:11:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pMt-0003ic-8B for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 17:05:04 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id C5/10-26652-E32FA945; Wed, 24 Dec 2014 17:05:02 +0000 X-Env-Sender: avsm2@cl.cam.ac.uk X-Msg-Ref: server-12.tower-206.messagelabs.com!1419440701!15094958!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=1.0 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12358 invoked from network); 24 Dec 2014 17:05:02 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2014 17:05:02 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 70c68dff; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 24 Dec 2014 17:11:20 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: <5499F549.1010607@cam.ac.uk> Date: Wed, 24 Dec 2014 17:04:58 +0000 Message-Id: <8DF3BE10-1D92-4283-A174-81AF75E9C721@cl.cam.ac.uk> References: <5499F549.1010607@cam.ac.uk> To: "J. Beleites" X-Mailer: Apple Mail (2.1993) X-Mailman-Approved-At: Wed, 24 Dec 2014 17:11:58 +0000 Cc: David Sheets , mirageos-devel Subject: Re: [MirageOS-devel] Installing tls - failing to install ctypes and conf-gmp X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgSm9oYW5uLCAoQ0NpbmcgdGhlIG1pcmFnZW9zLWRldmVsIGxpc3Qgd2hlcmUgc3VjaCBxdWVz dGlvbnMgY2FuIGhlbHAgb3RoZXJzIGFzIHdlbGwpCgpUaGUgZmlyc3QgZXJyb3Igd2l0aCBnbXAg aXMgZHVlIHRvIG5vdCBoYXZpbmcgdGhlIGxpYmdtcCBDIGxpYnJhcnkgaW5zdGFsbGVkLiAgWW91 IGNhbiBnZXQgdGhpcyBvbiBVYnVudHUgYnkgYGFwdC1nZXQgaW5zdGFsbCBsaWJnbXAtZGV2YCAo b3Igc2ltaWxhciwgSSBkb24ndCBoYXZlIGFuIFVidW50dSBib3ggaGFuZHkgdG8gZmluZCBvdXQg YXRtKS4KClRoZSBzZWNvbmQgZXJyb3IgaXMgZHVlIHRvIHlvdSB1c2luZyA0LjAzLjArdHJ1bmsg KHRoZSBibGVlZGluZyBlZGdlIHZlcnNpb24gb2YgT0NhbWwgdGhhdCBpcyB1bnJlbGVhc2VkKS4g IFlvdSBzaG91bGQgdXNlIDQuMDIuMSBvciA0LjAxLjAgaW5zdGVhZCwgYXMgeW91J3JlIG5vdCBk b2luZyBjb21waWxlciBoYWNraW5nIGFuZCBqdXN0IHdhbnQgdG8gdXNlIHRoZSBUTFMgbGlicmFy aWVzIHRoZW1zZWx2ZXMuCgotYW5pbAoKPiBPbiAyMyBEZWMgMjAxNCwgYXQgMjM6MDUsIEouIEJl bGVpdGVzIDxqY2I5OEBjYW0uYWMudWs+IHdyb3RlOgo+IAo+IC0tLS0tQkVHSU4gUEdQIFNJR05F RCBNRVNTQUdFLS0tLS0KPiBIYXNoOiBTSEExCj4gCj4gSGksCj4gCj4gSSd2ZSBiZWVuIHRyeWlu ZyB0byBpbnN0YWxsIG9jYW1sLXRscyB3aXRoICJvcGFtIGluc3RhbGwgdGxzIiBidXQgdGhlCj4g aW5zdGFsbGF0aW9uIGtlZXBzIG9uIGZhaWxpbmcgdG8gaW5zdGFsbCBjdHlwZXMuMC4zLjQgYW5k IGNvbmYtZ21wLjEKPiAodGhpcyBpcyBhbHNvIHRydWUgd2hlbiBJIHRyeSB0byBpbnN0YWxsIGVp dGhlciBvZiB0aGVtIG1hbnVhbGx5KS4KPiBJJ3ZlIHRyaWVkIHVzaW5nIHVzaW5nIG9jYW1sIHZl cnNpb25zIDQuMDEuMCwgNC4wMi4xIGFuZCA0LjAzLjArdHJ1bmsKPiBpZiB0aGF0IG1ha2VzIGFu eSBkaWZmZXJlbmNlLCBhbGwgd2l0aCB0aGUgc2FtZSByZXN1bHQuIEknbSB1c2luZyBvcGFtCj4g MS4yLjAgb24gVWJ1bnR1IDE0LjA0Lgo+IAo+IEZvciBjb25mLWdtcCBJIGtlZXAgb24gZ2V0dGlu ZyB0aGUgZm9sbG93aW5nIGVycm9yIHdoaWxlIHRyeWluZyB0bwo+IGluc3RhbGw6Cj4gCj4gIyB0 ZXN0LmM6MToxNzogZmF0YWwgZXJyb3I6IGdtcC5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 Cj4gIyAgI2luY2x1ZGUgPGdtcC5oPgo+ICMgICAgICAgICAgICAgICAgICBeCj4gIyBjb21waWxh dGlvbiB0ZXJtaW5hdGVkLgo+IAo+IAo+IFRyeWluZyB0byBpbnN0YWxsIGN0eXBlcyBnaXZlczoK PiAKPiAjIC4uLlt0cnVuY2F0ZWRdCj4gIyAgICAgY2FzZSBVaW50NjRfdDogYiA9IGN0eXBlc19j b3B5X3VpbnQ2NCgqKHVpbnQ2NCAqKWJ1Zik7IGJyZWFrOwo+ICMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4KPiAjCj4gL2hvbWUvam9jYmUvLm9w YW0vNC4wMy4wK3RydW5rL2J1aWxkL2N0eXBlcy4wLjMuNC9zcmMvY3R5cGVzL3R5cGVfaW5mb19z dHVicy5jOgo+IEluIGZ1bmN0aW9uIOKAmGN0eXBlc193cml0ZeKAmToKPiAjCj4gL2hvbWUvam9j YmUvLm9wYW0vNC4wMy4wK3RydW5rL2J1aWxkL2N0eXBlcy4wLjMuNC9zcmMvY3R5cGVzL3R5cGVf aW5mb19zdHVicy5jOjkyOjIxOgo+IGVycm9yOiDigJh1aW50NjTigJkgdW5kZWNsYXJlZCAoZmly c3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCj4gIyAgICAgY2FzZSBVaW50NjRfdDogKih1aW50NjQg KilidWYgPSBVaW50NjRfdmFsKHYpOyBicmVhazsKPiAjICAgICAgICAgICAgICAgICAgICAgIF4K PiAjCj4gL2hvbWUvam9jYmUvLm9wYW0vNC4wMy4wK3RydW5rL2J1aWxkL2N0eXBlcy4wLjMuNC9z cmMvY3R5cGVzL3R5cGVfaW5mb19zdHVicy5jOjkyOjI5Ogo+IGVycm9yOiBleHBlY3RlZCBleHBy ZXNzaW9uIGJlZm9yZSDigJgp4oCZIHRva2VuCj4gIyAgICAgY2FzZSBVaW50NjRfdDogKih1aW50 NjQgKilidWYgPSBVaW50NjRfdmFsKHYpOyBicmVhazsKPiAjICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgXgo+ICMgbWFrZTogKioqIFtfYnVpbGQvc3JjL2N0eXBlcy90eXBlX2luZm9fc3R1 YnMub10gRXJyb3IgMgo+IAo+IAo+IEkgYW0gbm90IHN1cmUgd2hhdCBJIGFtIGRvaW5nIHdyb25n LiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nIG9idmlvdXMgaGVyZT8KPiAKPiBUaGFuayB5b3UhIChB bmQgc29ycnkgZm9yIGJvdGhlcmluZyB5b3UgZHVyaW5nIHRoZSBDaHJpc3RtYXMgdGltZSkuCj4g Cj4gSm9oYW5uCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KPiBWZXJzaW9uOiBHbnVQ RyB2MQo+IAo+IGlRRWNCQUVCQWdBR0JRSlVtZlZEQUFvSkVPdVgwd3Y1UGYwSVM4VUgvUkR5RFlu b3hiejdUQTRtZUhFOWhJdTYKPiBwWjVJbVdQekFnZklyNGdodURKUFE0QVpJbXNBcVRHbG92RDc2 R0FubUkweHl6SlFJcmFNblp3bUFBNHBlK29ECj4gKzd5M0hvRkZXTFVtTndYSVczREhJWlljeFdj SllLSG9tRUJMVmpVbDJIT2lzR1JoN2NqK1psZ0lrRTJkS1V0Ngo+IGlpZ045cU8zVE43M25SRjJU R1JLWlp0aHhnbk1pamc5TEhMUEVYUVhDSjJwUE5RS3JaNzU1RUVic3pkaDFsaUcKPiB6c1NTYktE dTNKTHB3YmpsSXpqQnVjQmZxZklBRlBvNGg1QWxkcEhYSHdpSDdMOTNKQmdWRWc5REpsS1JUZ1p5 Cj4gdTBhNmV0N3l4N09YYU5qVTRndVZBYlc5bHU1NG5lUzdkSTJoeFNOL1dkWStWTUpJWWw1NG5z WVRENEZ5M0xVPQo+ID1nZCt2Cj4gLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tCj4gCgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2 ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6 Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3Mt ZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 17:41:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 17:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pvz-0004XN-Ek; Wed, 24 Dec 2014 17:41:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pvy-0004XI-8D for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 17:41:18 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id D8/40-19763-DBAFA945; Wed, 24 Dec 2014 17:41:17 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1419442874!9805141!1 X-Originating-IP: [209.85.192.179] X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3082 invoked from network); 24 Dec 2014 17:41:15 -0000 Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com) (209.85.192.179) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 24 Dec 2014 17:41:15 -0000 Received: by mail-pd0-f179.google.com with SMTP id fp1so10272992pdb.38 for ; Wed, 24 Dec 2014 09:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mpsw/8J5PEQ4DPSTEG4K0WzytvaoGwNB5bqCZWxDgqU=; b=Kd197nXkk6ch78r9mGZDmjcOC+ykT3taekB7m20Tc4qU4El69iRRnYwjrrI2XrS4s/ LcdJWVC++nt75OEFQk9FO3Jd7lNA6xoNU/8XOppodAZY9nI4yMdoS33KirljmcAek/XR wRS9IpnmOhw/9UhWaA6FYNlgdW9uby8rQHxJPPykhuqNDD9/slh5wy0rd7D41U/hNQyx v7gTr1bl0MZEld/sIa3FGqtv66SeljxjPTl3cTVfgaGhpUwZT59E8rLWXa+uS1acpu/r AdCzJ86ksal+MjyoxegyG6B8HxhF7p+KvdBs9VlkoP4IagChfPwfmYv9OMu+lzdSatos dLIw== MIME-Version: 1.0 X-Received: by 10.68.131.163 with SMTP id on3mr54934636pbb.169.1419442873805; Wed, 24 Dec 2014 09:41:13 -0800 (PST) Received: by 10.70.130.193 with HTTP; Wed, 24 Dec 2014 09:41:13 -0800 (PST) In-Reply-To: References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> <549AA7D6.7000906@nottingham.ac.uk> Date: Wed, 24 Dec 2014 17:41:13 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy Cc: Haris Rotsos , mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4160259913253972000==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4160259913253972000== Content-Type: multipart/alternative; boundary=001a11c35b8845b463050af9cc1d --001a11c35b8845b463050af9cc1d Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 4:58 PM, Anil Madhavapeddy wrote: > Increasing the ring size requires patches to Xen's dom0 as well, and may > not be entirely trivial due to the increase from a single page to multiple > pages. I know that these changes did happen for the blkback (and Thomas > Leonard added indirect block descriptor support to our blkfront to take > advantage), but I don't know if they are supported on dom0's netback (which > is much more latency sensitive). > > Dave, any idea of the status here? > It looks like dom0 netback in 3.18 still expects one grant ref for each ring: http://lxr.free-electrons.com/source/drivers/net/xen-netback/netback.c#L1951 Some prototype patches were posted: http://lists.xen.org/archives/html/xen-devel/2012-01/msg02661.html but not merged yet http://lists.xen.org/archives/html/xen-devel/2012-01/msg02709.html Perhaps we should implement netback and experiment with this Mirage<->Mirage. At the moment we have blkback, blkfront, netfront but no netback. If we had a netback then you could make a Mirage switch which didn't have to bounce all traffic through dom0 (twice) Cheers, Dave > -anil > > On 24 Dec 2014, at 11:47, Masoud Koleini > wrote: > > Thanks. > > What is the right way of increasing the size of allocated ring in netif? I > found that in high packet rate, that would be a limiting factor. > > On 20/12/14 17:31, Anil Madhavapeddy wrote: > > This is an excellent point -- applying backpressure going back to dom0 > would help balance out load once multiple netfronts come into play. > > However, the issue with the ring handler being Lwt-aware is that it's > not clear what to do if the function blocks. All subsequent acks would > also be blocked since the ring has to be processed in order (although the > responses on the ring themselves may be out of order). > > I think we should take a look at the Ring API itself once Dave's > refactoring has landed and is released. A more concurrent API could push > the backpressure to the layer immediately after the Ring ack. > > -anil > > On 20 Dec 2014, at 09:06, Haris Rotsos wrote: > > I am following up to share some experience from when I was experimenting > with the original mirage switch. I also have a few design suggestions, but > maybe they are invalid. > > I think the problem mentioned in the original mail stems from the way > packets are handled by a xen unikernel. if you check > https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on line > 300, for each new packet arriving on a VIF, the code will start a thread > and ignore the result. As a result, if you start sending lots of packets to > a unikernel and the main processing pipeline cannot keep up with the rate, > then new packets are allocated and delegated to an handling thread, but > these threads will never return and they will create a huge backlog, which > at some point will exhaust memory. > > From a design point of view the best approach to solve this problem, I > think, is to create a pool of threads with a fixed size. If the pool > doesn't have a free thread, then the packet is dropped. Alternatively, the > driver can be redesigned to create backpressure to the netback and force > packets to drop in the Dom0, instead of the unikernel, and thus reduce a > bit the cpu load. In the past I tried to rewrite the rx_poll method, But > the problem is that the function that is passed as a handler to ack new > pages from the netback is not lwt aware, thus you cannot easily integrate > some of the lwt asyncronicity in the processing pipeline. > > On 20 December 2014 at 00:11, Anil Madhavapeddy wrote: >> >> The actual definition of these functions is probably in the >> mirage/mirage-platform repository at the moment. Look in the xen/ >> subdirectory and grep for the C file that contains it. >> >> We can migrate this library to use xen_cflags and avoid the need for this >> repetition quite soon as well. The build hacks are gradually being undone! >> >> -anil >> >> > On 19 Dec 2014, at 09:25, Anil Madhavapeddy wrote: >> > >> > CCing the list. >> > >> >> On 19 Dec 2014, at 08:49, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >> >> >> I have added the function to stub_alloc_pages.c and defined it as >> external function in io_page.ml. No problem in installing io_page, but >> when compiling the program, I receive the error: >> >> >> >> undefined reference to `caml_dealloc_page' >> >> >> >> how do you think I can fix it? >> >> >> >> Thanks. >> >> >> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >> >>> Not at the moment, although we could easily add an explicit >> deallocator into >> >>> Io_page. You need to very careful that the page is not used after >> its lifetime, >> >>> so more pool-based abstractions are preferred (where the pages are >> recycled into >> >>> an OCaml-managed data structure and reused rather than GCed). >> >>> >> >>> You should be able to pump up the amount of RAM the VM gets >> temporarily to 4GB >> >>> or so -- if the page allocator still remains low, then it's unlikely >> to be a GC >> >>> issue and an actual leak somewhere due to holding onto references and >> keeping >> >>> the page live. >> >>> >> >>> -anil >> >>> >> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >>>> >> >>>> Is it possible to deallocate an Io_page after packet is send, not to >> wait for GC? >> >>>> >> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >> >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >>>>>> I am wondering if the following issue is already addressed: >> >>>>>> >> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >> >>>>>> >> >>>>>> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> >>>>>> >> >>>>> It probably still happens at 64MB of RAM -- it requires some code >> to adjust >> >>>>> the GC parameters in the OCaml runtime to trigger a collection more >> often. >> >>>>> It should be harmless however, since (as the bug report observes), >> a failure >> >>>>> to allocate an Io_page results in a GC compaction that frees up >> memory so >> >>>>> that the allocation eventually succeeds. >> >>>>> >> >>>>> Any particular reason for asking -- is the bug affecting your >> switch somehow? >> >>>>> >> >>>>> -anil >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This message and any attachment are intended solely for the >> addressee and may contain confidential information. If you have received >> this message in error, please send it back to me, and immediately delete >> it. Please do not use, copy or disclose the information contained in this >> message or in any attachment. Any views or opinions expressed by the >> author of this email do not necessarily reflect the views of the University >> of Nottingham. >> >>>> >> >>>> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> >> and may contain confidential information. If you have received this >> >> message in error, please send it back to me, and immediately delete it. >> >> Please do not use, copy or disclose the information contained in this >> >> message or in any attachment. Any views or opinions expressed by the >> >> author of this email do not necessarily reflect the views of the >> >> University of Nottingham. >> >> >> >> This message has been checked for viruses but the contents of an >> >> attachment may still contain software viruses which could damage your >> >> computer system, you are advised to perform your own checks. Email >> >> communications with the University of Nottingham may be monitored as >> >> permitted by UK legislation. >> >> >> > >> > >> > _______________________________________________ >> > MirageOS-devel mailing list >> > MirageOS-devel@lists.xenproject.org >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > > > -- > Charalampos Rotsos > PhD student > The University of Cambridge > Computer Laboratory > William Gates Building > JJ Thomson Avenue > Cambridge > CB3 0FD > > Phone: +44-(0) 1223 767032 > Email: cr409@cl.cam.ac.uk > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > -- Dave Scott --001a11c35b8845b463050af9cc1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 24, 2014 at 4:58 PM, Anil Madhavapeddy &l= t;anil@recoil.org&= gt; wrote:
I= ncreasing the ring size requires patches to Xen's dom0 as well, and may= not be entirely trivial due to the increase from a single page to multiple= pages.=C2=A0 I know that these changes did happen for the blkback (and Tho= mas Leonard added indirect block descriptor support to our blkfront to take= advantage), but I don't know if they are supported on dom0's netba= ck (which is much more latency sensitive).

Dave, any ide= a of the status here?

It looks = like dom0 netback in 3.18 still expects one grant ref for each ring:
<= div>

Some pr= ototype patches were posted:


but not merged yet


Perhaps we should implement netback and experiment with this Mirage&l= t;->Mirage. At the moment we have blkback, blkfront, netfront but no net= back. If we had a netback then you could make a Mirage switch which didn= 9;t have to bounce all traffic through dom0 (twice)

Cheers,
Dave


-anil

On 24 Dec 2014, at 11:47, Masoud Koleini <masoud.ko= leini@nottingham.ac.uk> wrote:

=20 =20 =20
Thanks.

What is the right way of increasing the size of allocated ring in netif? I found that in high packet rate, that would be a limiting factor.

On 20/12/14 17:31, Anil Madhavapeddy wrote:
=20 This is an excellent point -- applying backpressure going back to dom0 would help balance out load once multiple netfronts come into play.

However, the issue with the ring handler being Lwt-aware is that it's not clear what to do if the function blocks.=C2=A0 All subsequent acks would also be blocked since the ring has to be processed in order (although the responses on the ring themselves may be out of order).

I think we should take a look at the Ring API itself once Dave's refactoring has landed and is released.=C2=A0 A mor= e concurrent API could push the backpressure to the layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> wrote:

I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid.=C2=A0

I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel. =C2=A0if you check=C2=A0<= a href=3D"https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml= " target=3D"_blank">https://github.com/mirage/mirage-net-xen/blob/master/li= b/netif.ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory.=C2=A0

From a design point of view the best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed =C2=A0 as a handler to ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment.=C2=A0 Look in the xen/ subdirectory and gre= p for the C file that contains it.

We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well.=C2=A0 The build hacks are gradually being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit deallocator into
>>> Io_page.=C2=A0 You need to very careful that the page is not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.a= c.uk> wrote:
>>>>>> I am wondering if the following issue is already addressed:
>>>>>>
>>>>>> https://github.com= /mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a collection more often.
>>>>> It should be harmless however, since (as the bug report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecting your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.=C2=A0 =C2=A0Please d= o not use, copy or disclose the information contained in this message or in any attachment.=C2=A0 Any views or opinions express= ed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.=C2=A0 An= y views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________=
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenpro= ject.org/cgi-bin/mailman/listinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/mirageos-devel


--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk


This message and any attachment are intended solely for the addresse=
e
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.=20

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


__________________= _____________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel




--
Dave Scott
--001a11c35b8845b463050af9cc1d-- --===============4160259913253972000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4160259913253972000==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 17:41:21 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 17:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pvz-0004XN-Ek; Wed, 24 Dec 2014 17:41:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3pvy-0004XI-8D for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 17:41:18 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id D8/40-19763-DBAFA945; Wed, 24 Dec 2014 17:41:17 +0000 X-Env-Sender: scott.dj@gmail.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1419442874!9805141!1 X-Originating-IP: [209.85.192.179] X-SpamReason: No, hits=1.2 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3082 invoked from network); 24 Dec 2014 17:41:15 -0000 Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com) (209.85.192.179) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 24 Dec 2014 17:41:15 -0000 Received: by mail-pd0-f179.google.com with SMTP id fp1so10272992pdb.38 for ; Wed, 24 Dec 2014 09:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mpsw/8J5PEQ4DPSTEG4K0WzytvaoGwNB5bqCZWxDgqU=; b=Kd197nXkk6ch78r9mGZDmjcOC+ykT3taekB7m20Tc4qU4El69iRRnYwjrrI2XrS4s/ LcdJWVC++nt75OEFQk9FO3Jd7lNA6xoNU/8XOppodAZY9nI4yMdoS33KirljmcAek/XR wRS9IpnmOhw/9UhWaA6FYNlgdW9uby8rQHxJPPykhuqNDD9/slh5wy0rd7D41U/hNQyx v7gTr1bl0MZEld/sIa3FGqtv66SeljxjPTl3cTVfgaGhpUwZT59E8rLWXa+uS1acpu/r AdCzJ86ksal+MjyoxegyG6B8HxhF7p+KvdBs9VlkoP4IagChfPwfmYv9OMu+lzdSatos dLIw== MIME-Version: 1.0 X-Received: by 10.68.131.163 with SMTP id on3mr54934636pbb.169.1419442873805; Wed, 24 Dec 2014 09:41:13 -0800 (PST) Received: by 10.70.130.193 with HTTP; Wed, 24 Dec 2014 09:41:13 -0800 (PST) In-Reply-To: References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> <549AA7D6.7000906@nottingham.ac.uk> Date: Wed, 24 Dec 2014 17:41:13 +0000 Message-ID: From: David Scott To: Anil Madhavapeddy Cc: Haris Rotsos , mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4160259913253972000==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============4160259913253972000== Content-Type: multipart/alternative; boundary=001a11c35b8845b463050af9cc1d --001a11c35b8845b463050af9cc1d Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 4:58 PM, Anil Madhavapeddy wrote: > Increasing the ring size requires patches to Xen's dom0 as well, and may > not be entirely trivial due to the increase from a single page to multiple > pages. I know that these changes did happen for the blkback (and Thomas > Leonard added indirect block descriptor support to our blkfront to take > advantage), but I don't know if they are supported on dom0's netback (which > is much more latency sensitive). > > Dave, any idea of the status here? > It looks like dom0 netback in 3.18 still expects one grant ref for each ring: http://lxr.free-electrons.com/source/drivers/net/xen-netback/netback.c#L1951 Some prototype patches were posted: http://lists.xen.org/archives/html/xen-devel/2012-01/msg02661.html but not merged yet http://lists.xen.org/archives/html/xen-devel/2012-01/msg02709.html Perhaps we should implement netback and experiment with this Mirage<->Mirage. At the moment we have blkback, blkfront, netfront but no netback. If we had a netback then you could make a Mirage switch which didn't have to bounce all traffic through dom0 (twice) Cheers, Dave > -anil > > On 24 Dec 2014, at 11:47, Masoud Koleini > wrote: > > Thanks. > > What is the right way of increasing the size of allocated ring in netif? I > found that in high packet rate, that would be a limiting factor. > > On 20/12/14 17:31, Anil Madhavapeddy wrote: > > This is an excellent point -- applying backpressure going back to dom0 > would help balance out load once multiple netfronts come into play. > > However, the issue with the ring handler being Lwt-aware is that it's > not clear what to do if the function blocks. All subsequent acks would > also be blocked since the ring has to be processed in order (although the > responses on the ring themselves may be out of order). > > I think we should take a look at the Ring API itself once Dave's > refactoring has landed and is released. A more concurrent API could push > the backpressure to the layer immediately after the Ring ack. > > -anil > > On 20 Dec 2014, at 09:06, Haris Rotsos wrote: > > I am following up to share some experience from when I was experimenting > with the original mirage switch. I also have a few design suggestions, but > maybe they are invalid. > > I think the problem mentioned in the original mail stems from the way > packets are handled by a xen unikernel. if you check > https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml on line > 300, for each new packet arriving on a VIF, the code will start a thread > and ignore the result. As a result, if you start sending lots of packets to > a unikernel and the main processing pipeline cannot keep up with the rate, > then new packets are allocated and delegated to an handling thread, but > these threads will never return and they will create a huge backlog, which > at some point will exhaust memory. > > From a design point of view the best approach to solve this problem, I > think, is to create a pool of threads with a fixed size. If the pool > doesn't have a free thread, then the packet is dropped. Alternatively, the > driver can be redesigned to create backpressure to the netback and force > packets to drop in the Dom0, instead of the unikernel, and thus reduce a > bit the cpu load. In the past I tried to rewrite the rx_poll method, But > the problem is that the function that is passed as a handler to ack new > pages from the netback is not lwt aware, thus you cannot easily integrate > some of the lwt asyncronicity in the processing pipeline. > > On 20 December 2014 at 00:11, Anil Madhavapeddy wrote: >> >> The actual definition of these functions is probably in the >> mirage/mirage-platform repository at the moment. Look in the xen/ >> subdirectory and grep for the C file that contains it. >> >> We can migrate this library to use xen_cflags and avoid the need for this >> repetition quite soon as well. The build hacks are gradually being undone! >> >> -anil >> >> > On 19 Dec 2014, at 09:25, Anil Madhavapeddy wrote: >> > >> > CCing the list. >> > >> >> On 19 Dec 2014, at 08:49, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >> >> >> I have added the function to stub_alloc_pages.c and defined it as >> external function in io_page.ml. No problem in installing io_page, but >> when compiling the program, I receive the error: >> >> >> >> undefined reference to `caml_dealloc_page' >> >> >> >> how do you think I can fix it? >> >> >> >> Thanks. >> >> >> >> On 18/12/14 13:46, Anil Madhavapeddy wrote: >> >>> Not at the moment, although we could easily add an explicit >> deallocator into >> >>> Io_page. You need to very careful that the page is not used after >> its lifetime, >> >>> so more pool-based abstractions are preferred (where the pages are >> recycled into >> >>> an OCaml-managed data structure and reused rather than GCed). >> >>> >> >>> You should be able to pump up the amount of RAM the VM gets >> temporarily to 4GB >> >>> or so -- if the page allocator still remains low, then it's unlikely >> to be a GC >> >>> issue and an actual leak somewhere due to holding onto references and >> keeping >> >>> the page live. >> >>> >> >>> -anil >> >>> >> >>>> On 18 Dec 2014, at 05:41, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >>>> >> >>>> Is it possible to deallocate an Io_page after packet is send, not to >> wait for GC? >> >>>> >> >>>> On 16/12/14 23:45, Anil Madhavapeddy wrote: >> >>>>> On 16 Dec 2014, at 15:23, Masoud Koleini < >> masoud.koleini@nottingham.ac.uk> wrote: >> >>>>>> I am wondering if the following issue is already addressed: >> >>>>>> >> >>>>>> https://github.com/mirage/mirage-tcpip/issues/33 >> >>>>>> >> >>>>>> >> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html >> >>>>>> >> >>>>> It probably still happens at 64MB of RAM -- it requires some code >> to adjust >> >>>>> the GC parameters in the OCaml runtime to trigger a collection more >> often. >> >>>>> It should be harmless however, since (as the bug report observes), >> a failure >> >>>>> to allocate an Io_page results in a GC compaction that frees up >> memory so >> >>>>> that the allocation eventually succeeds. >> >>>>> >> >>>>> Any particular reason for asking -- is the bug affecting your >> switch somehow? >> >>>>> >> >>>>> -anil >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> This message and any attachment are intended solely for the >> addressee and may contain confidential information. If you have received >> this message in error, please send it back to me, and immediately delete >> it. Please do not use, copy or disclose the information contained in this >> message or in any attachment. Any views or opinions expressed by the >> author of this email do not necessarily reflect the views of the University >> of Nottingham. >> >>>> >> >>>> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> This message and any attachment are intended solely for the addressee >> >> and may contain confidential information. If you have received this >> >> message in error, please send it back to me, and immediately delete it. >> >> Please do not use, copy or disclose the information contained in this >> >> message or in any attachment. Any views or opinions expressed by the >> >> author of this email do not necessarily reflect the views of the >> >> University of Nottingham. >> >> >> >> This message has been checked for viruses but the contents of an >> >> attachment may still contain software viruses which could damage your >> >> computer system, you are advised to perform your own checks. Email >> >> communications with the University of Nottingham may be monitored as >> >> permitted by UK legislation. >> >> >> > >> > >> > _______________________________________________ >> > MirageOS-devel mailing list >> > MirageOS-devel@lists.xenproject.org >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> MirageOS-devel@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >> > > > -- > Charalampos Rotsos > PhD student > The University of Cambridge > Computer Laboratory > William Gates Building > JJ Thomson Avenue > Cambridge > CB3 0FD > > Phone: +44-(0) 1223 767032 > Email: cr409@cl.cam.ac.uk > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > -- Dave Scott --001a11c35b8845b463050af9cc1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 24, 2014 at 4:58 PM, Anil Madhavapeddy &l= t;anil@recoil.org&= gt; wrote:
I= ncreasing the ring size requires patches to Xen's dom0 as well, and may= not be entirely trivial due to the increase from a single page to multiple= pages.=C2=A0 I know that these changes did happen for the blkback (and Tho= mas Leonard added indirect block descriptor support to our blkfront to take= advantage), but I don't know if they are supported on dom0's netba= ck (which is much more latency sensitive).

Dave, any ide= a of the status here?

It looks = like dom0 netback in 3.18 still expects one grant ref for each ring:
<= div>

Some pr= ototype patches were posted:


but not merged yet


Perhaps we should implement netback and experiment with this Mirage&l= t;->Mirage. At the moment we have blkback, blkfront, netfront but no net= back. If we had a netback then you could make a Mirage switch which didn= 9;t have to bounce all traffic through dom0 (twice)

Cheers,
Dave


-anil

On 24 Dec 2014, at 11:47, Masoud Koleini <masoud.ko= leini@nottingham.ac.uk> wrote:

=20 =20 =20
Thanks.

What is the right way of increasing the size of allocated ring in netif? I found that in high packet rate, that would be a limiting factor.

On 20/12/14 17:31, Anil Madhavapeddy wrote:
=20 This is an excellent point -- applying backpressure going back to dom0 would help balance out load once multiple netfronts come into play.

However, the issue with the ring handler being Lwt-aware is that it's not clear what to do if the function blocks.=C2=A0 All subsequent acks would also be blocked since the ring has to be processed in order (although the responses on the ring themselves may be out of order).

I think we should take a look at the Ring API itself once Dave's refactoring has landed and is released.=C2=A0 A mor= e concurrent API could push the backpressure to the layer immediately after the Ring ack.

-anil

On 20 Dec 2014, at 09:06, Haris Rotsos <cr409@cl.cam.ac.uk> wrote:

I am following up to share some experience from when I was experimenting with the original mirage switch. I also have a few design suggestions, but maybe they are invalid.=C2=A0

I think the problem mentioned in the original mail stems from the way packets are handled by a xen unikernel. =C2=A0if you check=C2=A0<= a href=3D"https://github.com/mirage/mirage-net-xen/blob/master/lib/netif.ml= " target=3D"_blank">https://github.com/mirage/mirage-net-xen/blob/master/li= b/netif.ml on line 300, for each new packet arriving on a VIF, the code will start a thread and ignore the result. As a result, if you start sending lots of packets to a unikernel and the main processing pipeline cannot keep up with the rate, then new packets are allocated and delegated to an handling thread, but these threads will never return and they will create a huge backlog, which at some point will exhaust memory.=C2=A0

From a design point of view the best approach to solve this problem, I think, is to create a pool of threads with a fixed size. If the pool doesn't have a free thread, then the packet is dropped. Alternatively, the driver can be redesigned to create backpressure to the netback and force packets to drop in the Dom0, instead of the unikernel, and thus reduce a bit the cpu load. In the past I tried to rewrite the rx_poll method, But the problem is that the function that is passed =C2=A0 as a handler to ack new pages from the netback is not lwt aware, thus you cannot easily integrate some of the lwt asyncronicity in the processing pipeline.

On 20 December 2014 at 00:11, Anil Madhavapeddy <anil@recoil.org> wrote:
The actual definition of these functions is probably in the mirage/mirage-platform repository at the moment.=C2=A0 Look in the xen/ subdirectory and gre= p for the C file that contains it.

We can migrate this library to use xen_cflags and avoid the need for this repetition quite soon as well.=C2=A0 The build hacks are gradually being undone!

-anil

> On 19 Dec 2014, at 09:25, Anil Madhavapeddy <anil@recoil.org> wrote:
>
> CCing the list.
>
>> On 19 Dec 2014, at 08:49, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>
>> I have added the function to stub_alloc_pages.c and defined it as external function in io_page.ml. No problem in installing io_page, but when compiling the program, I receive the error:
>>
>> undefined reference to `caml_dealloc_page'
>>
>> how do you think I can fix it?
>>
>> Thanks.
>>
>> On 18/12/14 13:46, Anil Madhavapeddy wrote:
>>> Not at the moment, although we could easily add an explicit deallocator into
>>> Io_page.=C2=A0 You need to very careful that the page is not used after its lifetime,
>>> so more pool-based abstractions are preferred (where the pages are recycled into
>>> an OCaml-managed data structure and reused rather than GCed).
>>>
>>> You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
>>> or so -- if the page allocator still remains low, then it's unlikely to be a GC
>>> issue and an actual leak somewhere due to holding onto references and keeping
>>> the page live.
>>>
>>> -anil
>>>
>>>> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@nottingham.ac.uk> wrote:
>>>>
>>>> Is it possible to deallocate an Io_page after packet is send, not to wait for GC?
>>>>
>>>> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>>>>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@nottingham.a= c.uk> wrote:
>>>>>> I am wondering if the following issue is already addressed:
>>>>>>
>>>>>> https://github.com= /mirage/mirage-tcpip/issues/33
>>>>>>
>>>>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html
>>>>>>
>>>>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>>>>> the GC parameters in the OCaml runtime to trigger a collection more often.
>>>>> It should be harmless however, since (as the bug report observes), a failure
>>>>> to allocate an Io_page results in a GC compaction that frees up memory so
>>>>> that the allocation eventually succeeds.
>>>>>
>>>>> Any particular reason for asking -- is the bug affecting your switch somehow?
>>>>>
>>>>> -anil
>>>>
>>>>
>>>>
>>>>
>>>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.=C2=A0 =C2=A0Please d= o not use, copy or disclose the information contained in this message or in any attachment.=C2=A0 Any views or opinions express= ed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>>>
>>>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>>>
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.=C2=A0 An= y views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>
>
> _______________________________________________=
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> http://lists.xenpro= ject.org/cgi-bin/mailman/listinfo/mirageos-devel
>


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/mirageos-devel


--
Charalampos Rotsos
PhD student
The University of Cambridge
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge
CB3 0FD

Phone: +44-(0) 1223 767032
Email: cr409@cl.cam.ac.uk


This message and any attachment are intended solely for the addresse=
e
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.=20

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


__________________= _____________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel




--
Dave Scott
--001a11c35b8845b463050af9cc1d-- --===============4160259913253972000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============4160259913253972000==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 17:46:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 17:46:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3q1R-0004kM-1j; Wed, 24 Dec 2014 17:46:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3q1P-0004kH-Kb for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 17:46:55 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 9E/C4-26652-E0CFA945; Wed, 24 Dec 2014 17:46:54 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-206.messagelabs.com!1419443213!15139129!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24880 invoked from network); 24 Dec 2014 17:46:53 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2014 17:46:53 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id a37054e8; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 24 Dec 2014 17:53:12 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 24 Dec 2014 17:46:02 +0000 Message-Id: <6B1944C8-34C7-4D83-A251-1B5CC9F189B9@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> <549AA7D6.7000906@nottingham.ac.uk> To: David Scott X-Mailer: Apple Mail (2.1993) Cc: Haris Rotsos , mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1247796924351326788==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1247796924351326788== Content-Type: multipart/alternative; boundary="Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D" --Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Dec 2014, at 17:41, David Scott > wrote: >=20 >=20 >=20 > On Wed, Dec 24, 2014 at 4:58 PM, Anil Madhavapeddy > wrote: > Increasing the ring size requires patches to Xen's dom0 as well, and = may not be entirely trivial due to the increase from a single page to = multiple pages. I know that these changes did happen for the blkback = (and Thomas Leonard added indirect block descriptor support to our = blkfront to take advantage), but I don't know if they are supported on = dom0's netback (which is much more latency sensitive). >=20 > Dave, any idea of the status here? >=20 > It looks like dom0 netback in 3.18 still expects one grant ref for = each ring: >=20 > = http://lxr.free-electrons.com/source/drivers/net/xen-netback/netback.c#L19= 51 = >=20 > Some prototype patches were posted: >=20 > http://lists.xen.org/archives/html/xen-devel/2012-01/msg02661.html = >=20 > but not merged yet >=20 > http://lists.xen.org/archives/html/xen-devel/2012-01/msg02709.html = >=20 > Perhaps we should implement netback and experiment with this = Mirage<->Mirage. At the moment we have blkback, blkfront, netfront but = no netback. If we had a netback then you could make a Mirage switch = which didn't have to bounce all traffic through dom0 (twice) Doing this over netmap in dom0 might make sense... at the cost of some = isolation, but we could assign a 1:1 mapping between netfront/netback = which is sufficient for an openflow switch. -anil --Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 24 Dec 2014, at 17:41, David Scott <scott.dj@gmail.com> = wrote:



On Wed, Dec 24, 2014 at 4:58 PM, = Anil Madhavapeddy <anil@recoil.org> wrote:
Increasing the ring size requires patches to Xen's dom0 as = well, and may not be entirely trivial due to the increase from a single = page to multiple pages.  I know that these changes did happen for = the blkback (and Thomas Leonard added indirect block descriptor support = to our blkfront to take advantage), but I don't know if they are = supported on dom0's netback (which is much more latency sensitive).

Dave, any idea of the = status here?

It looks like dom0 netback in 3.18 = still expects one grant ref for each ring:

http://lxr.free-electrons.com/source/drivers/net/xen-netback/ne= tback.c#L1951

Some prototype patches were = posted:

http://lists.xen.org/archives/html/xen-devel/2012-01/msg02661.h= tml

but not merged yet

http://lists.xen.org/archives/html/xen-devel/2012-01/msg02709.h= tml

Perhaps we should implement netback and experiment with this = Mirage<->Mirage. At the moment we have blkback, blkfront, netfront = but no netback. If we had a netback then you could make a Mirage switch = which didn't have to bounce all traffic through dom0 = (twice)

Doing this over netmap in dom0 might make sense... at = the cost of some isolation, but we could assign a 1:1 mapping between = netfront/netback which is sufficient for an openflow switch.

-anil

= --Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D-- --===============1247796924351326788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1247796924351326788==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 24 17:46:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 24 Dec 2014 17:46:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3q1R-0004kM-1j; Wed, 24 Dec 2014 17:46:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y3q1P-0004kH-Kb for mirageos-devel@lists.xenproject.org; Wed, 24 Dec 2014 17:46:55 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 9E/C4-26652-E0CFA945; Wed, 24 Dec 2014 17:46:54 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-7.tower-206.messagelabs.com!1419443213!15139129!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24880 invoked from network); 24 Dec 2014 17:46:53 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2014 17:46:53 -0000 Received: from [10.0.0.94] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id a37054e8; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 24 Dec 2014 17:53:12 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 24 Dec 2014 17:46:02 +0000 Message-Id: <6B1944C8-34C7-4D83-A251-1B5CC9F189B9@recoil.org> References: <5490BEED.5050509@nottingham.ac.uk> <5492D996.4020605@nottingham.ac.uk> <39F9002D-4934-421A-9458-158D1696EDF4@recoil.org> <54945722.4010703@nottingham.ac.uk> <4F83AD06-91FB-4ED0-B374-E1871971C8C3@recoil.org> <8A2D7E63-E7F6-44D3-8A48-A65B7313EB8B@recoil.org> <549AA7D6.7000906@nottingham.ac.uk> To: David Scott X-Mailer: Apple Mail (2.1993) Cc: Haris Rotsos , mirageos-devel Subject: Re: [MirageOS-devel] Memory exhaustion in Mirage X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1247796924351326788==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============1247796924351326788== Content-Type: multipart/alternative; boundary="Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D" --Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Dec 2014, at 17:41, David Scott > wrote: >=20 >=20 >=20 > On Wed, Dec 24, 2014 at 4:58 PM, Anil Madhavapeddy > wrote: > Increasing the ring size requires patches to Xen's dom0 as well, and = may not be entirely trivial due to the increase from a single page to = multiple pages. I know that these changes did happen for the blkback = (and Thomas Leonard added indirect block descriptor support to our = blkfront to take advantage), but I don't know if they are supported on = dom0's netback (which is much more latency sensitive). >=20 > Dave, any idea of the status here? >=20 > It looks like dom0 netback in 3.18 still expects one grant ref for = each ring: >=20 > = http://lxr.free-electrons.com/source/drivers/net/xen-netback/netback.c#L19= 51 = >=20 > Some prototype patches were posted: >=20 > http://lists.xen.org/archives/html/xen-devel/2012-01/msg02661.html = >=20 > but not merged yet >=20 > http://lists.xen.org/archives/html/xen-devel/2012-01/msg02709.html = >=20 > Perhaps we should implement netback and experiment with this = Mirage<->Mirage. At the moment we have blkback, blkfront, netfront but = no netback. If we had a netback then you could make a Mirage switch = which didn't have to bounce all traffic through dom0 (twice) Doing this over netmap in dom0 might make sense... at the cost of some = isolation, but we could assign a 1:1 mapping between netfront/netback = which is sufficient for an openflow switch. -anil --Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 24 Dec 2014, at 17:41, David Scott <scott.dj@gmail.com> = wrote:



On Wed, Dec 24, 2014 at 4:58 PM, = Anil Madhavapeddy <anil@recoil.org> wrote:
Increasing the ring size requires patches to Xen's dom0 as = well, and may not be entirely trivial due to the increase from a single = page to multiple pages.  I know that these changes did happen for = the blkback (and Thomas Leonard added indirect block descriptor support = to our blkfront to take advantage), but I don't know if they are = supported on dom0's netback (which is much more latency sensitive).

Dave, any idea of the = status here?

It looks like dom0 netback in 3.18 = still expects one grant ref for each ring:

http://lxr.free-electrons.com/source/drivers/net/xen-netback/ne= tback.c#L1951

Some prototype patches were = posted:

http://lists.xen.org/archives/html/xen-devel/2012-01/msg02661.h= tml

but not merged yet

http://lists.xen.org/archives/html/xen-devel/2012-01/msg02709.h= tml

Perhaps we should implement netback and experiment with this = Mirage<->Mirage. At the moment we have blkback, blkfront, netfront = but no netback. If we had a netback then you could make a Mirage switch = which didn't have to bounce all traffic through dom0 = (twice)

Doing this over netmap in dom0 might make sense... at = the cost of some isolation, but we could assign a 1:1 mapping between = netfront/netback which is sufficient for an openflow switch.

-anil

= --Apple-Mail=_4A5FCBAD-9BFC-4B2C-9A8F-82388676114D-- --===============1247796924351326788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============1247796924351326788==-- From mirageos-devel-bounces@lists.xenproject.org Sun Dec 28 20:44:31 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 28 Dec 2014 20:44:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5KhM-0008VK-7A; Sun, 28 Dec 2014 20:44:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5KhK-0008VF-Hr for MirageOS-devel@lists.xenproject.org; Sun, 28 Dec 2014 20:44:22 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 71/30-31453-5AB60A45; Sun, 28 Dec 2014 20:44:21 +0000 X-Env-Sender: jeremias@blendin.org X-Msg-Ref: server-16.tower-206.messagelabs.com!1419799460!12532204!1 X-Originating-IP: [209.85.192.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27400 invoked from network); 28 Dec 2014 20:44:21 -0000 Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Dec 2014 20:44:21 -0000 Received: by mail-qg0-f43.google.com with SMTP id z107so8879198qgd.30 for ; Sun, 28 Dec 2014 12:44:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Oyw6UgM8fGr4WhRhgiJVIPgYHDGPSDCjyX6WGsQd+8g=; b=MgzGyaDAErzPEiHZYjrdKUaLUnYTyYNUQD/bB1v2/4iCzPvwoBkEFz5ONWslpBPKVb FWC61Nrbb0LgUGOm1xBNqCA/mtJam1kteA6qPt0CuDH1xux7tQSOOLNeO6en0Futexh0 A4+qSgag/QrV0bjfrgSoL2jdL2CBrTDTbYrIEwgIZmPG8c73Lkm/MbL58zDDO/EpSJA5 TPhUxci6zeby4oYKyG7fpnJgodrDsRmJoJLVdoiYTap/j1Hb023mIvkA9XDO7+CuS96D /UEZwPpI95a+858vA0vepL1paLC3lz7TcDmqltoyEgPH3gGzwy84XGa+jokel3Wj/vTI bxcA== X-Gm-Message-State: ALoCoQnDstS+uwML/qUIl2ihtN9Lzr3uMn/Vxm5nW92BZ+bc/TDNlqVs1M9m3eROmDxCEqHaFNbt MIME-Version: 1.0 X-Received: by 10.140.89.202 with SMTP id v68mr81267531qgd.96.1419799460032; Sun, 28 Dec 2014 12:44:20 -0800 (PST) Received: by 10.96.132.40 with HTTP; Sun, 28 Dec 2014 12:44:20 -0800 (PST) Date: Sun, 28 Dec 2014 21:44:20 +0100 Message-ID: From: Jeremias Blendin To: MirageOS-devel@lists.xenproject.org Subject: [MirageOS-devel] Example with multiple interfaces X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8753768526361320465==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8753768526361320465== Content-Type: multipart/alternative; boundary=001a11c1182e77c98c050b4cd256 --001a11c1182e77c98c050b4cd256 Content-Type: text/plain; charset=UTF-8 Hi, I recently started with MirageOS and would like to configure multiple interfaces with a unikernel. I experimented with the "ping" example from mirage-skeleton repository, but could not get it to work. Are there any examples with multiple interfaces available for beginners like me? Thanks you Jeremias --001a11c1182e77c98c050b4cd256 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I recently started with MirageOS an= d would like to configure multiple interfaces with a unikernel. I experimen= ted with the "ping" example from=C2=A0mirage-skeleton repository,= but could not get it to work. Are there any examples with multiple interfa= ces available for beginners like me?

Thanks you

Jeremias
--001a11c1182e77c98c050b4cd256-- --===============8753768526361320465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8753768526361320465==-- From mirageos-devel-bounces@lists.xenproject.org Sun Dec 28 20:44:31 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 28 Dec 2014 20:44:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5KhM-0008VK-7A; Sun, 28 Dec 2014 20:44:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5KhK-0008VF-Hr for MirageOS-devel@lists.xenproject.org; Sun, 28 Dec 2014 20:44:22 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 71/30-31453-5AB60A45; Sun, 28 Dec 2014 20:44:21 +0000 X-Env-Sender: jeremias@blendin.org X-Msg-Ref: server-16.tower-206.messagelabs.com!1419799460!12532204!1 X-Originating-IP: [209.85.192.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27400 invoked from network); 28 Dec 2014 20:44:21 -0000 Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Dec 2014 20:44:21 -0000 Received: by mail-qg0-f43.google.com with SMTP id z107so8879198qgd.30 for ; Sun, 28 Dec 2014 12:44:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Oyw6UgM8fGr4WhRhgiJVIPgYHDGPSDCjyX6WGsQd+8g=; b=MgzGyaDAErzPEiHZYjrdKUaLUnYTyYNUQD/bB1v2/4iCzPvwoBkEFz5ONWslpBPKVb FWC61Nrbb0LgUGOm1xBNqCA/mtJam1kteA6qPt0CuDH1xux7tQSOOLNeO6en0Futexh0 A4+qSgag/QrV0bjfrgSoL2jdL2CBrTDTbYrIEwgIZmPG8c73Lkm/MbL58zDDO/EpSJA5 TPhUxci6zeby4oYKyG7fpnJgodrDsRmJoJLVdoiYTap/j1Hb023mIvkA9XDO7+CuS96D /UEZwPpI95a+858vA0vepL1paLC3lz7TcDmqltoyEgPH3gGzwy84XGa+jokel3Wj/vTI bxcA== X-Gm-Message-State: ALoCoQnDstS+uwML/qUIl2ihtN9Lzr3uMn/Vxm5nW92BZ+bc/TDNlqVs1M9m3eROmDxCEqHaFNbt MIME-Version: 1.0 X-Received: by 10.140.89.202 with SMTP id v68mr81267531qgd.96.1419799460032; Sun, 28 Dec 2014 12:44:20 -0800 (PST) Received: by 10.96.132.40 with HTTP; Sun, 28 Dec 2014 12:44:20 -0800 (PST) Date: Sun, 28 Dec 2014 21:44:20 +0100 Message-ID: From: Jeremias Blendin To: MirageOS-devel@lists.xenproject.org Subject: [MirageOS-devel] Example with multiple interfaces X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8753768526361320465==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============8753768526361320465== Content-Type: multipart/alternative; boundary=001a11c1182e77c98c050b4cd256 --001a11c1182e77c98c050b4cd256 Content-Type: text/plain; charset=UTF-8 Hi, I recently started with MirageOS and would like to configure multiple interfaces with a unikernel. I experimented with the "ping" example from mirage-skeleton repository, but could not get it to work. Are there any examples with multiple interfaces available for beginners like me? Thanks you Jeremias --001a11c1182e77c98c050b4cd256 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I recently started with MirageOS an= d would like to configure multiple interfaces with a unikernel. I experimen= ted with the "ping" example from=C2=A0mirage-skeleton repository,= but could not get it to work. Are there any examples with multiple interfa= ces available for beginners like me?

Thanks you

Jeremias
--001a11c1182e77c98c050b4cd256-- --===============8753768526361320465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============8753768526361320465==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 30 11:43:20 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 30 Dec 2014 11:43:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5vCi-0006MF-8I; Tue, 30 Dec 2014 11:43:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5vCg-0006MA-UV for MirageOS-devel@lists.xenproject.org; Tue, 30 Dec 2014 11:43:11 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 15/CD-07724-ECF82A45; Tue, 30 Dec 2014 11:43:10 +0000 X-Env-Sender: michaelmoon.pr@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1419939788!16380519!1 X-Originating-IP: [209.85.215.53] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21127 invoked from network); 30 Dec 2014 11:43:09 -0000 Received: from mail-la0-f53.google.com (HELO mail-la0-f53.google.com) (209.85.215.53) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 30 Dec 2014 11:43:09 -0000 Received: by mail-la0-f53.google.com with SMTP id gm9so12362020lab.26 for ; Tue, 30 Dec 2014 03:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZLjDDaWwYybYXYBeOzz9q5vEfM4iIfQjv70jLIi4WsE=; b=ud8UOlbLNEqjOgj5tDZa+IYwMFWDqImYUeihpBHi8pWQjxSqbOUrknzffnnaYBadxS 18Pw9jOU0cZtqC1RIL582fW+xOCnK+IkkewcsI7ymeXhLCDYUcTrFgH6UcgMB0ZjUSmH dM8sXYCQuKlfWi6TiFj4KLEerZZzZQ/wCS2K6PgRcyqDXfuSKuGIRiPLr8VVgfG90ozh 8ys4W2ZccDRYR8elOimhBpLFCBqpzg3vzVjTbIjssoCHW8N7EFwPZJiKsdIcvZ5oXQnH cEi9JmfX8mQL3l++Ozfi+IAGZT8zlcHSmb5QJtTB2+2j84mMHTeVQsB3ccuLlA+vUIz5 yulg== MIME-Version: 1.0 X-Received: by 10.112.125.41 with SMTP id mn9mr47247173lbb.80.1419939788289; Tue, 30 Dec 2014 03:43:08 -0800 (PST) Received: by 10.112.118.102 with HTTP; Tue, 30 Dec 2014 03:43:08 -0800 (PST) In-Reply-To: References: Date: Tue, 30 Dec 2014 11:43:08 +0000 Message-ID: From: Michael Moon To: Jeremias Blendin Cc: MirageOS-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Example with multiple interfaces X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207472189309013463==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0207472189309013463== Content-Type: multipart/alternative; boundary=089e0112c200aefbd9050b6d7ea4 --089e0112c200aefbd9050b6d7ea4 Content-Type: text/plain; charset=UTF-8 What was the problem in making ping example work? First of all, make sure that your opam is up to date (run "opam update" and "opam upgrade") Second, you may need root privilege in running mir-ping. Third, manually assign ip address 10.0.0.1 to your tap0 device. On Sun, Dec 28, 2014 at 8:44 PM, Jeremias Blendin wrote: > Hi, > > I recently started with MirageOS and would like to configure multiple > interfaces with a unikernel. I experimented with the "ping" example > from mirage-skeleton repository, but could not get it to work. Are there > any examples with multiple interfaces available for beginners like me? > > Thanks you > > Jeremias > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --089e0112c200aefbd9050b6d7ea4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What was the problem in making ping example= work?

First of all, make sure that your opam is up to date (r= un "opam update" and "opam upgrade")

Secon= d, you may need root privilege in running mir-ping.

Third, man= ually assign ip address 10.0.0.1 to your tap0 device.


On Sun, Dec 28, 2014 at 8= :44 PM, Jeremias Blendin <jeremias@blendin.org> wrote:
Hi,

I r= ecently started with MirageOS and would like to configure multiple interfac= es with a unikernel. I experimented with the "ping" example from= =C2=A0mirage-skeleton repository, but could not get it to work. Are there a= ny examples with multiple interfaces available for beginners like me?
=

Thanks you

Jeremias

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--089e0112c200aefbd9050b6d7ea4-- --===============0207472189309013463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0207472189309013463==-- From mirageos-devel-bounces@lists.xenproject.org Tue Dec 30 11:43:20 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 30 Dec 2014 11:43:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5vCi-0006MF-8I; Tue, 30 Dec 2014 11:43:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y5vCg-0006MA-UV for MirageOS-devel@lists.xenproject.org; Tue, 30 Dec 2014 11:43:11 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 15/CD-07724-ECF82A45; Tue, 30 Dec 2014 11:43:10 +0000 X-Env-Sender: michaelmoon.pr@gmail.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1419939788!16380519!1 X-Originating-IP: [209.85.215.53] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21127 invoked from network); 30 Dec 2014 11:43:09 -0000 Received: from mail-la0-f53.google.com (HELO mail-la0-f53.google.com) (209.85.215.53) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 30 Dec 2014 11:43:09 -0000 Received: by mail-la0-f53.google.com with SMTP id gm9so12362020lab.26 for ; Tue, 30 Dec 2014 03:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZLjDDaWwYybYXYBeOzz9q5vEfM4iIfQjv70jLIi4WsE=; b=ud8UOlbLNEqjOgj5tDZa+IYwMFWDqImYUeihpBHi8pWQjxSqbOUrknzffnnaYBadxS 18Pw9jOU0cZtqC1RIL582fW+xOCnK+IkkewcsI7ymeXhLCDYUcTrFgH6UcgMB0ZjUSmH dM8sXYCQuKlfWi6TiFj4KLEerZZzZQ/wCS2K6PgRcyqDXfuSKuGIRiPLr8VVgfG90ozh 8ys4W2ZccDRYR8elOimhBpLFCBqpzg3vzVjTbIjssoCHW8N7EFwPZJiKsdIcvZ5oXQnH cEi9JmfX8mQL3l++Ozfi+IAGZT8zlcHSmb5QJtTB2+2j84mMHTeVQsB3ccuLlA+vUIz5 yulg== MIME-Version: 1.0 X-Received: by 10.112.125.41 with SMTP id mn9mr47247173lbb.80.1419939788289; Tue, 30 Dec 2014 03:43:08 -0800 (PST) Received: by 10.112.118.102 with HTTP; Tue, 30 Dec 2014 03:43:08 -0800 (PST) In-Reply-To: References: Date: Tue, 30 Dec 2014 11:43:08 +0000 Message-ID: From: Michael Moon To: Jeremias Blendin Cc: MirageOS-devel@lists.xenproject.org Subject: Re: [MirageOS-devel] Example with multiple interfaces X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207472189309013463==" Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org --===============0207472189309013463== Content-Type: multipart/alternative; boundary=089e0112c200aefbd9050b6d7ea4 --089e0112c200aefbd9050b6d7ea4 Content-Type: text/plain; charset=UTF-8 What was the problem in making ping example work? First of all, make sure that your opam is up to date (run "opam update" and "opam upgrade") Second, you may need root privilege in running mir-ping. Third, manually assign ip address 10.0.0.1 to your tap0 device. On Sun, Dec 28, 2014 at 8:44 PM, Jeremias Blendin wrote: > Hi, > > I recently started with MirageOS and would like to configure multiple > interfaces with a unikernel. I experimented with the "ping" example > from mirage-skeleton repository, but could not get it to work. Are there > any examples with multiple interfaces available for beginners like me? > > Thanks you > > Jeremias > > _______________________________________________ > MirageOS-devel mailing list > MirageOS-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > --089e0112c200aefbd9050b6d7ea4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What was the problem in making ping example= work?

First of all, make sure that your opam is up to date (r= un "opam update" and "opam upgrade")

Secon= d, you may need root privilege in running mir-ping.

Third, man= ually assign ip address 10.0.0.1 to your tap0 device.


On Sun, Dec 28, 2014 at 8= :44 PM, Jeremias Blendin <jeremias@blendin.org> wrote:
Hi,

I r= ecently started with MirageOS and would like to configure multiple interfac= es with a unikernel. I experimented with the "ping" example from= =C2=A0mirage-skeleton repository, but could not get it to work. Are there a= ny examples with multiple interfaces available for beginners like me?
=

Thanks you

Jeremias

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists= .xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo= /mirageos-devel


--089e0112c200aefbd9050b6d7ea4-- --===============0207472189309013463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel --===============0207472189309013463==-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 00:08:23 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 00:08:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y66pl-0002AP-LB; Wed, 31 Dec 2014 00:08:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y66pk-0002AJ-Ao for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 00:08:16 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 2F/AA-03145-04E33A45; Wed, 31 Dec 2014 00:07:28 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-7.tower-27.messagelabs.com!1419984447!17828607!1 X-Originating-IP: [131.111.8.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17118 invoked from network); 31 Dec 2014 00:07:27 -0000 Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk) (131.111.8.152) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 00:07:27 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:61657 helo=[192.168.0.6]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y66ow-0005fI-EN (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 00:07:26 +0000 From: Gregory Tsipenyuk Message-Id: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> Date: Tue, 30 Dec 2014 19:07:24 -0500 To: Thomas Gazagnaire , mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgVGhvbWFzLAoKSeKAmW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0b3Jh Z2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGluIElybWluLiBGaXJzdCBJIHRyaWVkIHRvIGNv bnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZlICgyLjRHKSB0byB0aGUgSU1BUCBzZXJ2ZXIg SXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lvbiB0aGUgc2l6ZSBvZiB0aGUgZ2l0IHJlcG9z aXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBhcmNoaXZlLiBJIGRvIGhh dmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMgdGhhdCBJIGNyZWF0ZSwgbGlrZSBwZXIgbWFp bGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0aWNzIGFuZCBwZXIgZW1haWwgbWVzc2FnZSBm bGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXplIGlzIGNvbWluZyBmcm9tIHRob3NlIHN0cnVj dHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhpZ2guIEkgd2lsbCBoYXZlIHRvIGVzdGltYXRl IHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRpb25hbCBzdHJ1Y3R1cmVzIHRvIHVuZGVyc3Rh bmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQgaW50byBpcm1pbiAyLDAwMCBvZiAxTSBmaWxl cyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdoaWNoIHJlc3VsdGVkIGluIHRoZSBnaXQgcmVw b3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJlIElybWluIGNvbXByZXNzZXMgdGhlIGNvbnRl bnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1bXBlZCAyLDAwMCBvZiAyLjRNIGltYWdlIGZp bGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIgdG8gbWFrZSB0aGUgY29udGVudCB1bmlxdWUu IFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRoaXMgd2FzIDQuNkcsIHdoaWNoIGlzIGV4cGVj dGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3QgdGVzdCBidXQgd2l0aCBpZGVudGljYWwgaW1h Z2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2FzIDI3TSwgd2hpY2ggd2FzIGNsZWFybHkgYSBu aWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJcm1pbi4gTXkgcXVlc3Rpb24gaXMgd2hldGhl ciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMgY29uZmlndXJhYmxlPyBDYW4gaXQgYmUgY29u ZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRlbnQ/IEZvciBpbnN0YW5jZSwgSSBkb27igJl0 IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRoZXJlIGlzIG5vdGhpbmcgdG8gZ2FpbiBmcm9t IHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVlbnRseSB0aGVyZSBpcyB1bm5lY2Vzc2FyeSBy ZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRvIGNvbXByZXNzIHRoZSB0ZXh0IGlmIHRoZSBj b21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25hYmxlLiBJIGNhbiBmaWd1cmUgb3V0IHRoZSB0 eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUgaW4gSU1BUCBzZXJ2ZXIuCgpUaGFua3MgCkdy ZWdvcnkKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWly YWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qu b3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8v bWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 00:08:23 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 00:08:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y66pl-0002AP-LB; Wed, 31 Dec 2014 00:08:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y66pk-0002AJ-Ao for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 00:08:16 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 2F/AA-03145-04E33A45; Wed, 31 Dec 2014 00:07:28 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-7.tower-27.messagelabs.com!1419984447!17828607!1 X-Originating-IP: [131.111.8.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MiA9PiA4MDU1Mw==\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17118 invoked from network); 31 Dec 2014 00:07:27 -0000 Received: from ppsw-52.csi.cam.ac.uk (HELO ppsw-52.csi.cam.ac.uk) (131.111.8.152) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 00:07:27 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:61657 helo=[192.168.0.6]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y66ow-0005fI-EN (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 00:07:26 +0000 From: Gregory Tsipenyuk Message-Id: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> Date: Tue, 30 Dec 2014 19:07:24 -0500 To: Thomas Gazagnaire , mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Subject: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgVGhvbWFzLAoKSeKAmW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0b3Jh Z2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGluIElybWluLiBGaXJzdCBJIHRyaWVkIHRvIGNv bnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZlICgyLjRHKSB0byB0aGUgSU1BUCBzZXJ2ZXIg SXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lvbiB0aGUgc2l6ZSBvZiB0aGUgZ2l0IHJlcG9z aXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBhcmNoaXZlLiBJIGRvIGhh dmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMgdGhhdCBJIGNyZWF0ZSwgbGlrZSBwZXIgbWFp bGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0aWNzIGFuZCBwZXIgZW1haWwgbWVzc2FnZSBm bGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXplIGlzIGNvbWluZyBmcm9tIHRob3NlIHN0cnVj dHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhpZ2guIEkgd2lsbCBoYXZlIHRvIGVzdGltYXRl IHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRpb25hbCBzdHJ1Y3R1cmVzIHRvIHVuZGVyc3Rh bmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQgaW50byBpcm1pbiAyLDAwMCBvZiAxTSBmaWxl cyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdoaWNoIHJlc3VsdGVkIGluIHRoZSBnaXQgcmVw b3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJlIElybWluIGNvbXByZXNzZXMgdGhlIGNvbnRl bnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1bXBlZCAyLDAwMCBvZiAyLjRNIGltYWdlIGZp bGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIgdG8gbWFrZSB0aGUgY29udGVudCB1bmlxdWUu IFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRoaXMgd2FzIDQuNkcsIHdoaWNoIGlzIGV4cGVj dGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3QgdGVzdCBidXQgd2l0aCBpZGVudGljYWwgaW1h Z2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2FzIDI3TSwgd2hpY2ggd2FzIGNsZWFybHkgYSBu aWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJcm1pbi4gTXkgcXVlc3Rpb24gaXMgd2hldGhl ciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMgY29uZmlndXJhYmxlPyBDYW4gaXQgYmUgY29u ZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRlbnQ/IEZvciBpbnN0YW5jZSwgSSBkb27igJl0 IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRoZXJlIGlzIG5vdGhpbmcgdG8gZ2FpbiBmcm9t IHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVlbnRseSB0aGVyZSBpcyB1bm5lY2Vzc2FyeSBy ZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRvIGNvbXByZXNzIHRoZSB0ZXh0IGlmIHRoZSBj b21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25hYmxlLiBJIGNhbiBmaWd1cmUgb3V0IHRoZSB0 eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUgaW4gSU1BUCBzZXJ2ZXIuCgpUaGFua3MgCkdy ZWdvcnkKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWly YWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qu b3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8v bWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 05:39:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 05:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6C0f-0004NA-1K; Wed, 31 Dec 2014 05:39:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6C0c-0004N5-8T for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 05:39:50 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 92/DE-25276-52C83A45; Wed, 31 Dec 2014 05:39:49 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-5.tower-21.messagelabs.com!1420004388!18561418!1 X-Originating-IP: [131.111.8.140] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5154 invoked from network); 31 Dec 2014 05:39:48 -0000 Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk) (131.111.8.140) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 05:39:48 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62435 helo=[192.168.0.6]) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6C0Z-0008Gg-lv (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 05:39:48 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> Date: Wed, 31 Dec 2014 00:39:45 -0500 Message-Id: <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> To: Thomas Gazagnaire , mirageos-devel X-Mailer: Apple Mail (2.1993) Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgVGhvbWFzLAoKSSBsb29rZWQgYXQgdGhlIG1ldGFkYXRhIHRoYXQgZ2V0cyBjcmVhdGVkIGZv ciBldmVyeSBlbWFpbCBtZXNzYWdlIGFuZCBpdOKAmXMgc21hbGwgLSBsZXNzIHRoYW4gMTAwIGJ5 dGVzLiBTbyBJIHJhbiBhIHNpbXBsZSB0ZXN0IG9mIGFwcGVuZGluZyAyMCwwMDAgdW5pcXVlIDEw MCBieXRlcyBhc2NpaSBtZXNzYWdlcy4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSByZXBvc2l0 b3J5IHNpemUgdG8gYmUgb24gdGhlIG9yZGVyIG9mIGEgZmV3IG1lZ2FieXRlcywgaW5zdGVhZCBp dCB3YXMgNC43Ry4gVGhpcyBpcyByb3VnaGx5IDIzNEsgb3ZlcmhlYWQgcGVyIDEwMCBieXRlcyBt ZXNzYWdlLCB3aGljaCB3b3VsZCBiZSBxdWl0ZSBpbXByYWN0aWNhbCBmb3IgdGhlIGVtYWlsIHN0 b3JhZ2Ugd2l0aCB0aGUgbWV0YWRhdGEgZXNzZW50aWFsbHkgZXhjZWVkaW5nIHRoZSBtZXNzYWdl IHN0b3JhZ2UuCgpHcmVnb3J5Cgo+IE9uIERlYyAzMCwgMjAxNCwgYXQgNzowNyBQTSwgR3JlZ29y eSBUc2lwZW55dWsgPGd0MzAzQGNhbS5hYy51az4gd3JvdGU6Cj4gCj4gSGkgVGhvbWFzLAo+IAo+ IEnigJltIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQga2luZCBvZiBzdG9yYWdlIG92ZXJoZWFk IGFuZCBkZWR1cCBJIGdldCBpbiBJcm1pbi4gRmlyc3QgSSB0cmllZCB0byBjb252ZXJ0IHRoZSBn b29nbGUgZW1haWwgYXJjaGl2ZSAoMi40RykgdG8gdGhlIElNQVAgc2VydmVyIElybWluIGZvcm1h dCAuIEFmdGVyIGNvbnZlcnNpb24gdGhlIHNpemUgb2YgdGhlIGdpdCByZXBvc2l0b3J5IHdhcyB0 d2ljZSB0aGUgc2l6ZSBvZiB0aGUgb3JpZ2luYWwgYXJjaGl2ZS4gSSBkbyBoYXZlIHNvbWUgYWRk aXRpb25hbCBzdHJ1Y3R1cmVzIHRoYXQgSSBjcmVhdGUsIGxpa2UgcGVyIG1haWxib3ggaW5kZXgg YW5kIHN1bW1hcnkgc3RhdGlzdGljcyBhbmQgcGVyIGVtYWlsIG1lc3NhZ2UgZmxhZ3Mgc28gcGVy aGFwcyB0aGUgZXh0cmEgc2l6ZSBpcyBjb21pbmcgZnJvbSB0aG9zZSBzdHJ1Y3R1cmVzIHRob3Vn aCBpdCBzZWVtcyBhIGJpdCBoaWdoLiBJIHdpbGwgaGF2ZSB0byBlc3RpbWF0ZSB0aGUgZXhwZWN0 ZWQgc2l6ZSBmcm9tIGFkZGl0aW9uYWwgc3RydWN0dXJlcyB0byB1bmRlcnN0YW5kIHRoaXMgcmVz dWx0LiBOZXh0IEkgZHVtcGVkIGludG8gaXJtaW4gMiwwMDAgb2YgMU0gZmlsZXMgd2l0aCByYW5k b20gYXNjaWkgY29udGVudCB3aGljaCByZXN1bHRlZCBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgc2l6 ZSBvZiA5NTBNLiBJIGZpZ3VyZSBJcm1pbiBjb21wcmVzc2VzIHRoZSBjb250ZW50LCByaWdodD8g VG8gdmVyaWZ5IHRoaXMgSSBkdW1wZWQgMiwwMDAgb2YgMi40TSBpbWFnZSBmaWxlcyB3aXRoIGNv bmNhdGVuYXRlZCBjb3VudGVyIHRvIG1ha2UgdGhlIGNvbnRlbnQgdW5pcXVlLiBUaGUgc2l6ZSBv ZiByZXBvc2l0b3J5IGZvciB0aGlzIHdhcyA0LjZHLCB3aGljaCBpcyBleHBlY3RlZC4gVGhlbiBJ IHJlcGVhdGVkIHRoZSBsYXN0IHRlc3QgYnV0IHdpdGggaWRlbnRpY2FsIGltYWdlcyBhbmQgdGhp cyB0aW1lIHRoZSBzaXplIHdhcyAyN00sIHdoaWNoIHdhcyBjbGVhcmx5IGEgbmljZSBwcm9vZiBv ZiB0aGUgZGVkdXBpbmcgYnkgSXJtaW4uIE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGNvbXBy ZXNzaW9uIGluIElybWluIGlzIGNvbmZpZ3VyYWJsZT8gQ2FuIGl0IGJlIGNvbmZpZ3VyYWJsZSBw ZXIgaW5kaXZpZHVhbCBjb250ZW50PyBGb3IgaW5zdGFuY2UsIEkgZG9u4oCZdCB3YW50IHRvIGNv bXByZXNzIGltYWdlcyBhcyB0aGVyZSBpcyBub3RoaW5nIHRvIGdhaW4gZnJvbSB0aGUgc3BhY2Ug c2F2aW5nIGFuZCBjb25zZXF1ZW50bHkgdGhlcmUgaXMgdW5uZWNlc3NhcnkgcmVzb3VyY2UgdXNh Z2UgYnV0IEkgZG8gd2FudCB0byBjb21wcmVzcyB0aGUgdGV4dCBpZiB0aGUgY29tcHJlc3Npb24g b3ZlcmhlYWQgaXMgcmVhc29uYWJsZS4gSSBjYW4gZmlndXJlIG91dCB0aGUgdHlwZSBvZiBjb250 ZW50IGZyb20gTUlNRSB0eXBlIGluIElNQVAgc2VydmVyLgo+IAo+IFRoYW5rcyAKPiBHcmVnb3J5 CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdl T1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3Jn Cmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWly YWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 05:39:59 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 05:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6C0f-0004NA-1K; Wed, 31 Dec 2014 05:39:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6C0c-0004N5-8T for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 05:39:50 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 92/DE-25276-52C83A45; Wed, 31 Dec 2014 05:39:49 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-5.tower-21.messagelabs.com!1420004388!18561418!1 X-Originating-IP: [131.111.8.140] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5154 invoked from network); 31 Dec 2014 05:39:48 -0000 Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk) (131.111.8.140) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 05:39:48 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62435 helo=[192.168.0.6]) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6C0Z-0008Gg-lv (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 05:39:48 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> Date: Wed, 31 Dec 2014 00:39:45 -0500 Message-Id: <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> To: Thomas Gazagnaire , mirageos-devel X-Mailer: Apple Mail (2.1993) Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgVGhvbWFzLAoKSSBsb29rZWQgYXQgdGhlIG1ldGFkYXRhIHRoYXQgZ2V0cyBjcmVhdGVkIGZv ciBldmVyeSBlbWFpbCBtZXNzYWdlIGFuZCBpdOKAmXMgc21hbGwgLSBsZXNzIHRoYW4gMTAwIGJ5 dGVzLiBTbyBJIHJhbiBhIHNpbXBsZSB0ZXN0IG9mIGFwcGVuZGluZyAyMCwwMDAgdW5pcXVlIDEw MCBieXRlcyBhc2NpaSBtZXNzYWdlcy4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSByZXBvc2l0 b3J5IHNpemUgdG8gYmUgb24gdGhlIG9yZGVyIG9mIGEgZmV3IG1lZ2FieXRlcywgaW5zdGVhZCBp dCB3YXMgNC43Ry4gVGhpcyBpcyByb3VnaGx5IDIzNEsgb3ZlcmhlYWQgcGVyIDEwMCBieXRlcyBt ZXNzYWdlLCB3aGljaCB3b3VsZCBiZSBxdWl0ZSBpbXByYWN0aWNhbCBmb3IgdGhlIGVtYWlsIHN0 b3JhZ2Ugd2l0aCB0aGUgbWV0YWRhdGEgZXNzZW50aWFsbHkgZXhjZWVkaW5nIHRoZSBtZXNzYWdl IHN0b3JhZ2UuCgpHcmVnb3J5Cgo+IE9uIERlYyAzMCwgMjAxNCwgYXQgNzowNyBQTSwgR3JlZ29y eSBUc2lwZW55dWsgPGd0MzAzQGNhbS5hYy51az4gd3JvdGU6Cj4gCj4gSGkgVGhvbWFzLAo+IAo+ IEnigJltIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQga2luZCBvZiBzdG9yYWdlIG92ZXJoZWFk IGFuZCBkZWR1cCBJIGdldCBpbiBJcm1pbi4gRmlyc3QgSSB0cmllZCB0byBjb252ZXJ0IHRoZSBn b29nbGUgZW1haWwgYXJjaGl2ZSAoMi40RykgdG8gdGhlIElNQVAgc2VydmVyIElybWluIGZvcm1h dCAuIEFmdGVyIGNvbnZlcnNpb24gdGhlIHNpemUgb2YgdGhlIGdpdCByZXBvc2l0b3J5IHdhcyB0 d2ljZSB0aGUgc2l6ZSBvZiB0aGUgb3JpZ2luYWwgYXJjaGl2ZS4gSSBkbyBoYXZlIHNvbWUgYWRk aXRpb25hbCBzdHJ1Y3R1cmVzIHRoYXQgSSBjcmVhdGUsIGxpa2UgcGVyIG1haWxib3ggaW5kZXgg YW5kIHN1bW1hcnkgc3RhdGlzdGljcyBhbmQgcGVyIGVtYWlsIG1lc3NhZ2UgZmxhZ3Mgc28gcGVy aGFwcyB0aGUgZXh0cmEgc2l6ZSBpcyBjb21pbmcgZnJvbSB0aG9zZSBzdHJ1Y3R1cmVzIHRob3Vn aCBpdCBzZWVtcyBhIGJpdCBoaWdoLiBJIHdpbGwgaGF2ZSB0byBlc3RpbWF0ZSB0aGUgZXhwZWN0 ZWQgc2l6ZSBmcm9tIGFkZGl0aW9uYWwgc3RydWN0dXJlcyB0byB1bmRlcnN0YW5kIHRoaXMgcmVz dWx0LiBOZXh0IEkgZHVtcGVkIGludG8gaXJtaW4gMiwwMDAgb2YgMU0gZmlsZXMgd2l0aCByYW5k b20gYXNjaWkgY29udGVudCB3aGljaCByZXN1bHRlZCBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgc2l6 ZSBvZiA5NTBNLiBJIGZpZ3VyZSBJcm1pbiBjb21wcmVzc2VzIHRoZSBjb250ZW50LCByaWdodD8g VG8gdmVyaWZ5IHRoaXMgSSBkdW1wZWQgMiwwMDAgb2YgMi40TSBpbWFnZSBmaWxlcyB3aXRoIGNv bmNhdGVuYXRlZCBjb3VudGVyIHRvIG1ha2UgdGhlIGNvbnRlbnQgdW5pcXVlLiBUaGUgc2l6ZSBv ZiByZXBvc2l0b3J5IGZvciB0aGlzIHdhcyA0LjZHLCB3aGljaCBpcyBleHBlY3RlZC4gVGhlbiBJ IHJlcGVhdGVkIHRoZSBsYXN0IHRlc3QgYnV0IHdpdGggaWRlbnRpY2FsIGltYWdlcyBhbmQgdGhp cyB0aW1lIHRoZSBzaXplIHdhcyAyN00sIHdoaWNoIHdhcyBjbGVhcmx5IGEgbmljZSBwcm9vZiBv ZiB0aGUgZGVkdXBpbmcgYnkgSXJtaW4uIE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGNvbXBy ZXNzaW9uIGluIElybWluIGlzIGNvbmZpZ3VyYWJsZT8gQ2FuIGl0IGJlIGNvbmZpZ3VyYWJsZSBw ZXIgaW5kaXZpZHVhbCBjb250ZW50PyBGb3IgaW5zdGFuY2UsIEkgZG9u4oCZdCB3YW50IHRvIGNv bXByZXNzIGltYWdlcyBhcyB0aGVyZSBpcyBub3RoaW5nIHRvIGdhaW4gZnJvbSB0aGUgc3BhY2Ug c2F2aW5nIGFuZCBjb25zZXF1ZW50bHkgdGhlcmUgaXMgdW5uZWNlc3NhcnkgcmVzb3VyY2UgdXNh Z2UgYnV0IEkgZG8gd2FudCB0byBjb21wcmVzcyB0aGUgdGV4dCBpZiB0aGUgY29tcHJlc3Npb24g b3ZlcmhlYWQgaXMgcmVhc29uYWJsZS4gSSBjYW4gZmlndXJlIG91dCB0aGUgdHlwZSBvZiBjb250 ZW50IGZyb20gTUlNRSB0eXBlIGluIElNQVAgc2VydmVyLgo+IAo+IFRoYW5rcyAKPiBHcmVnb3J5 CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdl T1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3Jn Cmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWly YWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 10:27:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 10:27:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GUd-0004GV-Tv; Wed, 31 Dec 2014 10:27:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GUc-0004GQ-LX for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 10:27:06 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 5B/38-01660-97FC3A45; Wed, 31 Dec 2014 10:27:05 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1420021624!15741980!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28099 invoked from network); 31 Dec 2014 10:27:04 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 31 Dec 2014 10:27:04 -0000 Received: by mail-wi0-f178.google.com with SMTP id em10so25219263wid.17 for ; Wed, 31 Dec 2014 02:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O30kiuA+5KSK90R4OYmwPDrUE2m3YtLPwhJySPXC25o=; b=d4TfDGYidl5d2/uaAn9AAacL1FCFKNVnO1VDjmYMgJjpyPKG3YiYV7BHE5nDsWLtgF cgazNNIuk/HGVxHdiMkGjJJ9CD+zdnlvPlu64UASgnd6lRyTLlpo6pIirUXZoH3izMAA VuYcsqKTiv4cggZBva2eWrORxtiUeAOjFkyVqUnhp4kfKDKDaIv5yi6NTG1htRrhVN7+ CSsqYKYgTRITuZIVmCmFS+v/j/YFRfX1mzUctZqJSYrpaa4w2jdgIfzYBc7BsLJSLyUU 9E51Qo/KczPNSsZE0bC8mWjGFGUfkXnNgFYX39tZoGxKIGBSD9PIFB/PdYkkcR7O4+wI 4KVg== X-Received: by 10.194.191.227 with SMTP id hb3mr131232015wjc.79.1420021624584; Wed, 31 Dec 2014 02:27:04 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id js5sm46585447wid.11.2014.12.31.02.27.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Dec 2014 02:27:03 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> Date: Wed, 31 Dec 2014 11:27:06 +0100 Message-Id: <104D7956-17DF-410C-823E-EC3B87658A7A@gazagnaire.org> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgR3JlZ29yeSwKCj4gSeKAmW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0 b3JhZ2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGluIElybWluLiBGaXJzdCBJIHRyaWVkIHRv IGNvbnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZlICgyLjRHKSB0byB0aGUgSU1BUCBzZXJ2 ZXIgSXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lvbiB0aGUgc2l6ZSBvZiB0aGUgZ2l0IHJl cG9zaXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBhcmNoaXZlLiBJIGRv IGhhdmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMgdGhhdCBJIGNyZWF0ZSwgbGlrZSBwZXIg bWFpbGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0aWNzIGFuZCBwZXIgZW1haWwgbWVzc2Fn ZSBmbGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXplIGlzIGNvbWluZyBmcm9tIHRob3NlIHN0 cnVjdHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhpZ2guIEkgd2lsbCBoYXZlIHRvIGVzdGlt YXRlIHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRpb25hbCBzdHJ1Y3R1cmVzIHRvIHVuZGVy c3RhbmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQgaW50byBpcm1pbiAyLDAwMCBvZiAxTSBm aWxlcyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdoaWNoIHJlc3VsdGVkIGluIHRoZSBnaXQg cmVwb3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJlIElybWluIGNvbXByZXNzZXMgdGhlIGNv bnRlbnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1bXBlZCAyLDAwMCBvZiAyLjRNIGltYWdl IGZpbGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIgdG8gbWFrZSB0aGUgY29udGVudCB1bmlx dWUuIFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRoaXMgd2FzIDQuNkcsIHdoaWNoIGlzIGV4 cGVjdGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3QgdGVzdCBidXQgd2l0aCBpZGVudGljYWwg aW1hZ2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2FzIDI3TSwgd2hpY2ggd2FzIGNsZWFybHkg YSBuaWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJcm1pbi4gTXkgcXVlc3Rpb24gaXMgd2hl dGhlciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMgY29uZmlndXJhYmxlPyBDYW4gaXQgYmUg Y29uZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRlbnQ/IEZvciBpbnN0YW5jZSwgSSBkb27i gJl0IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRoZXJlIGlzIG5vdGhpbmcgdG8gZ2FpbiBm cm9tIHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVlbnRseSB0aGVyZSBpcyB1bm5lY2Vzc2Fy eSByZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRvIGNvbXByZXNzIHRoZSB0ZXh0IGlmIHRo ZSBjb21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25hYmxlLiBJIGNhbiBmaWd1cmUgb3V0IHRo ZSB0eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUgaW4gSU1BUCBzZXJ2ZXIuCgpJbmRlZWQs IElybWluIGRlZHVwbGljYXRlIHNpbWlsYXIgY29udGVudHMgYXV0b21hdGljYWxseSBhcyBpdCB1 c2VzIHRoZSBkaWdlc3Qgb2YgaW50ZXJuYWwgb2JqZWN0cyBhcyBpbnRlcm5hbCBrZXlzICh0aGF0 J3Mgc2ltaWxhciB0byBjb250ZW50IGFkZHJlc3NhYmxlIHN0b3JlcyBvciBoYXNoLWNvbnNpbmcp LgoKRm9yIHRoZSBjb21wcmVzc2lvbiwgaXQgZGVwZW5kcyBvbiB0aGUgYmFja2VuZC4gSWYgeW91 IHVzZSBgSXJtaW5fZnNgIHlvdSB3aWxsIGhhdmUgbm9uZS4gSWYgeW91IHVzZSB0aGUgR2l0IGJh Y2tlbmQsIHlvdSBoYXZlIHR3byBraW5kcyBvZiBjb21wcmVzc2lvbnM6Ci0gdGhlIEdpdCBzZXJp YWxpc2F0aW9uIGZvcm1hdCBleHRlbnNpdmVseSB1c2VzIHRoZSB6bGliIGxpYnJhcnkuIEJhc2lj YWxseSBldmVyeSBjaHVuayBvZiBieXRlcyBpcyBjb21wcmVzc2VkLCBiZWluZyB0aGUgYmxvYnMg b3IgdGhlIHRoZSB0cmVlIGFuZCBjb21taXQgbWV0YWRhdGEKLSB5b3UgY2FuIHJ1biBgZ2l0IGdj YCBhdCB0aGUgcm9vdCBvZiB5b3VyIEdpdCByZXBvc2l0b3J5IGFuZCB0aGUgR2l0IHRvb2wgd2ls bCB0cnkgdG8gY29tcGFjdCBzaW1pbGFyIGNvbnRlbnRzIHRvZ2V0aGVyIGluIGAucGFja2AgZmls ZXMuIFRoZSBhbGdvcml0aG0gc29ydCB0aGUgY29udGVudHMgYnkgZmlsZW5hbWUsIHRoZW4gYnkg c2l6ZSBhbmQgdGhlbiB1c2UgYSBzbGlkaW5nLXdpbmRvdyB0byBmaW5kIHNpbWlsYXIgY29udGVu dHMgYW5kIGNvbXB1dGUgYSBkaWZmLWJhc2VkIHJlcHJlc2VudGF0aW9uLiBTb21lIGtpbmQgb2Yg YGdpdCBnY2AgaXMgYWxzbyBydW4gYmVmb3JlIGRvaW5nIGEgcHVzaC9wdWxsLCBhcyB0aGUgYC5w YWNrYCBmaWxlcyBhcmUgZXhhY3RseSB3aGF0IGlzIHNlbnQgb3ZlciB0aGUgbmV0d29yay4gU2Vl IFsxXSBmb3IgYSBncmVhdCBleHBsYW5hdGlvbiBvZiB0aGUgR2l0IGZvcm1hdC4KCkl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvIGNvbnRyb2wgdGhlIGxldmVsIG9mIGNvbXByZXNzaW9uIGJ5IGV4cGxp Y2l0bHkgcGFzc2luZyBhIH5sZXZlbCBhcmd1bWVudCB0byBabGliLmNvbXByZXNzWzJdIGluIG9j YW1sLWdpdFszXSBidXQgaXQgaXMgbm90IGRvbmUgY3VycmVudGx5WzRdLiBJJ20gbm90IHN1cmUg aXQgaXMgcG9zc2libGUgdG8gZGlzYWJsZSB0aGUgY29tcHJlc3Npb24gY29tcGxldGVseSBhbmQg c3RpbGwgYmUgY29tcGF0aWJsZSB3aXRoIHRoZSBHaXQgZm9ybWF0IHRob3VnaC4gSSdsbCBhZGQg dGhpcyBvcHRpb24gaW4gdGhlIG5leHQgcmVsZWFzZS4KCkJlc3QsClRob21hcwoKWzFdIGh0dHA6 Ly9zdGVmYW4uc2Fhc2VuLm1lL2FydGljbGVzL2dpdC1jbG9uZS1pbi1oYXNrZWxsLWZyb20tdGhl LWJvdHRvbS11cC8KWzJdIGh0dHA6Ly9uaXQuZ2ZvcmdlLmlucmlhLmZyL2NhbWx6aXAvWmxpYi5o dG1sI1ZBTENvbXByZXNzClszXSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL29jYW1sLWdpdC9i bG9iL21hc3Rlci9saWIvbWlzYy5tbCNMNzUKWzRdIGh0dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2Uv b2NhbWwtZ2l0L2lzc3Vlcy80MQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBs aXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9t YWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 10:27:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 10:27:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GUd-0004GV-Tv; Wed, 31 Dec 2014 10:27:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GUc-0004GQ-LX for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 10:27:06 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 5B/38-01660-97FC3A45; Wed, 31 Dec 2014 10:27:05 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1420021624!15741980!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28099 invoked from network); 31 Dec 2014 10:27:04 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 31 Dec 2014 10:27:04 -0000 Received: by mail-wi0-f178.google.com with SMTP id em10so25219263wid.17 for ; Wed, 31 Dec 2014 02:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O30kiuA+5KSK90R4OYmwPDrUE2m3YtLPwhJySPXC25o=; b=d4TfDGYidl5d2/uaAn9AAacL1FCFKNVnO1VDjmYMgJjpyPKG3YiYV7BHE5nDsWLtgF cgazNNIuk/HGVxHdiMkGjJJ9CD+zdnlvPlu64UASgnd6lRyTLlpo6pIirUXZoH3izMAA VuYcsqKTiv4cggZBva2eWrORxtiUeAOjFkyVqUnhp4kfKDKDaIv5yi6NTG1htRrhVN7+ CSsqYKYgTRITuZIVmCmFS+v/j/YFRfX1mzUctZqJSYrpaa4w2jdgIfzYBc7BsLJSLyUU 9E51Qo/KczPNSsZE0bC8mWjGFGUfkXnNgFYX39tZoGxKIGBSD9PIFB/PdYkkcR7O4+wI 4KVg== X-Received: by 10.194.191.227 with SMTP id hb3mr131232015wjc.79.1420021624584; Wed, 31 Dec 2014 02:27:04 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id js5sm46585447wid.11.2014.12.31.02.27.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Dec 2014 02:27:03 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> Date: Wed, 31 Dec 2014 11:27:06 +0100 Message-Id: <104D7956-17DF-410C-823E-EC3B87658A7A@gazagnaire.org> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SGkgR3JlZ29yeSwKCj4gSeKAmW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0 b3JhZ2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGluIElybWluLiBGaXJzdCBJIHRyaWVkIHRv IGNvbnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZlICgyLjRHKSB0byB0aGUgSU1BUCBzZXJ2 ZXIgSXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lvbiB0aGUgc2l6ZSBvZiB0aGUgZ2l0IHJl cG9zaXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBhcmNoaXZlLiBJIGRv IGhhdmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMgdGhhdCBJIGNyZWF0ZSwgbGlrZSBwZXIg bWFpbGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0aWNzIGFuZCBwZXIgZW1haWwgbWVzc2Fn ZSBmbGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXplIGlzIGNvbWluZyBmcm9tIHRob3NlIHN0 cnVjdHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhpZ2guIEkgd2lsbCBoYXZlIHRvIGVzdGlt YXRlIHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRpb25hbCBzdHJ1Y3R1cmVzIHRvIHVuZGVy c3RhbmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQgaW50byBpcm1pbiAyLDAwMCBvZiAxTSBm aWxlcyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdoaWNoIHJlc3VsdGVkIGluIHRoZSBnaXQg cmVwb3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJlIElybWluIGNvbXByZXNzZXMgdGhlIGNv bnRlbnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1bXBlZCAyLDAwMCBvZiAyLjRNIGltYWdl IGZpbGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIgdG8gbWFrZSB0aGUgY29udGVudCB1bmlx dWUuIFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRoaXMgd2FzIDQuNkcsIHdoaWNoIGlzIGV4 cGVjdGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3QgdGVzdCBidXQgd2l0aCBpZGVudGljYWwg aW1hZ2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2FzIDI3TSwgd2hpY2ggd2FzIGNsZWFybHkg YSBuaWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJcm1pbi4gTXkgcXVlc3Rpb24gaXMgd2hl dGhlciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMgY29uZmlndXJhYmxlPyBDYW4gaXQgYmUg Y29uZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRlbnQ/IEZvciBpbnN0YW5jZSwgSSBkb27i gJl0IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRoZXJlIGlzIG5vdGhpbmcgdG8gZ2FpbiBm cm9tIHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVlbnRseSB0aGVyZSBpcyB1bm5lY2Vzc2Fy eSByZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRvIGNvbXByZXNzIHRoZSB0ZXh0IGlmIHRo ZSBjb21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25hYmxlLiBJIGNhbiBmaWd1cmUgb3V0IHRo ZSB0eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUgaW4gSU1BUCBzZXJ2ZXIuCgpJbmRlZWQs IElybWluIGRlZHVwbGljYXRlIHNpbWlsYXIgY29udGVudHMgYXV0b21hdGljYWxseSBhcyBpdCB1 c2VzIHRoZSBkaWdlc3Qgb2YgaW50ZXJuYWwgb2JqZWN0cyBhcyBpbnRlcm5hbCBrZXlzICh0aGF0 J3Mgc2ltaWxhciB0byBjb250ZW50IGFkZHJlc3NhYmxlIHN0b3JlcyBvciBoYXNoLWNvbnNpbmcp LgoKRm9yIHRoZSBjb21wcmVzc2lvbiwgaXQgZGVwZW5kcyBvbiB0aGUgYmFja2VuZC4gSWYgeW91 IHVzZSBgSXJtaW5fZnNgIHlvdSB3aWxsIGhhdmUgbm9uZS4gSWYgeW91IHVzZSB0aGUgR2l0IGJh Y2tlbmQsIHlvdSBoYXZlIHR3byBraW5kcyBvZiBjb21wcmVzc2lvbnM6Ci0gdGhlIEdpdCBzZXJp YWxpc2F0aW9uIGZvcm1hdCBleHRlbnNpdmVseSB1c2VzIHRoZSB6bGliIGxpYnJhcnkuIEJhc2lj YWxseSBldmVyeSBjaHVuayBvZiBieXRlcyBpcyBjb21wcmVzc2VkLCBiZWluZyB0aGUgYmxvYnMg b3IgdGhlIHRoZSB0cmVlIGFuZCBjb21taXQgbWV0YWRhdGEKLSB5b3UgY2FuIHJ1biBgZ2l0IGdj YCBhdCB0aGUgcm9vdCBvZiB5b3VyIEdpdCByZXBvc2l0b3J5IGFuZCB0aGUgR2l0IHRvb2wgd2ls bCB0cnkgdG8gY29tcGFjdCBzaW1pbGFyIGNvbnRlbnRzIHRvZ2V0aGVyIGluIGAucGFja2AgZmls ZXMuIFRoZSBhbGdvcml0aG0gc29ydCB0aGUgY29udGVudHMgYnkgZmlsZW5hbWUsIHRoZW4gYnkg c2l6ZSBhbmQgdGhlbiB1c2UgYSBzbGlkaW5nLXdpbmRvdyB0byBmaW5kIHNpbWlsYXIgY29udGVu dHMgYW5kIGNvbXB1dGUgYSBkaWZmLWJhc2VkIHJlcHJlc2VudGF0aW9uLiBTb21lIGtpbmQgb2Yg YGdpdCBnY2AgaXMgYWxzbyBydW4gYmVmb3JlIGRvaW5nIGEgcHVzaC9wdWxsLCBhcyB0aGUgYC5w YWNrYCBmaWxlcyBhcmUgZXhhY3RseSB3aGF0IGlzIHNlbnQgb3ZlciB0aGUgbmV0d29yay4gU2Vl IFsxXSBmb3IgYSBncmVhdCBleHBsYW5hdGlvbiBvZiB0aGUgR2l0IGZvcm1hdC4KCkl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvIGNvbnRyb2wgdGhlIGxldmVsIG9mIGNvbXByZXNzaW9uIGJ5IGV4cGxp Y2l0bHkgcGFzc2luZyBhIH5sZXZlbCBhcmd1bWVudCB0byBabGliLmNvbXByZXNzWzJdIGluIG9j YW1sLWdpdFszXSBidXQgaXQgaXMgbm90IGRvbmUgY3VycmVudGx5WzRdLiBJJ20gbm90IHN1cmUg aXQgaXMgcG9zc2libGUgdG8gZGlzYWJsZSB0aGUgY29tcHJlc3Npb24gY29tcGxldGVseSBhbmQg c3RpbGwgYmUgY29tcGF0aWJsZSB3aXRoIHRoZSBHaXQgZm9ybWF0IHRob3VnaC4gSSdsbCBhZGQg dGhpcyBvcHRpb24gaW4gdGhlIG5leHQgcmVsZWFzZS4KCkJlc3QsClRob21hcwoKWzFdIGh0dHA6 Ly9zdGVmYW4uc2Fhc2VuLm1lL2FydGljbGVzL2dpdC1jbG9uZS1pbi1oYXNrZWxsLWZyb20tdGhl LWJvdHRvbS11cC8KWzJdIGh0dHA6Ly9uaXQuZ2ZvcmdlLmlucmlhLmZyL2NhbWx6aXAvWmxpYi5o dG1sI1ZBTENvbXByZXNzClszXSBodHRwczovL2dpdGh1Yi5jb20vbWlyYWdlL29jYW1sLWdpdC9i bG9iL21hc3Rlci9saWIvbWlzYy5tbCNMNzUKWzRdIGh0dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2Uv b2NhbWwtZ2l0L2lzc3Vlcy80MQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApNaXJhZ2VPUy1kZXZlbEBs aXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9t YWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 10:32:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 10:32:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GZY-0004Qf-DW; Wed, 31 Dec 2014 10:32:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GZX-0004Qa-Fl for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 10:32:11 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id 17/25-02707-AA0D3A45; Wed, 31 Dec 2014 10:32:10 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1420021929!12398332!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24205 invoked from network); 31 Dec 2014 10:32:10 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 31 Dec 2014 10:32:10 -0000 Received: by mail-wg0-f50.google.com with SMTP id a1so21897402wgh.37 for ; Wed, 31 Dec 2014 02:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5eF+Tz5zcIvMdbBqaA/Om72ka+SeFhc980jQppl9dDA=; b=IDM/BgkTFhlbWxY3ljyzyjaV/ryypmfjLsmRhf7xnVMzJPePiDVNYGwmYmGf/gW76e r47wGD4TWmI4f3pqPVMUzcqJ4nXJD/pStKP//afHHg4jgi20WviVthmvZ74R1aCc5PpS fnyXVC2omE7kmF7KHKFOQY7HttWxXy8OFpNDda8LP5hxVF/U801IKFKeafq9SzbUQUpe ko1DuoHKGFFBq0KmR3IcPv+LiRrHHZQgUHEDb+N19r8/i4IuMoDdGIMADRr46k9Pgk7z +mLFRShhinEUivz/yY6iMdp0TBKiF49BLRsAL/VXAX7tXfYjS3LXdcCBXRm6o49PJdx+ 2/Vw== X-Received: by 10.194.184.140 with SMTP id eu12mr111282440wjc.25.1420021929852; Wed, 31 Dec 2014 02:32:09 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id e18sm57066340wjz.27.2014.12.31.02.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Dec 2014 02:32:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> Date: Wed, 31 Dec 2014 11:32:11 +0100 Message-Id: <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org PiBJIGxvb2tlZCBhdCB0aGUgbWV0YWRhdGEgdGhhdCBnZXRzIGNyZWF0ZWQgZm9yIGV2ZXJ5IGVt YWlsIG1lc3NhZ2UgYW5kIGl04oCZcyBzbWFsbCAtIGxlc3MgdGhhbiAxMDAgYnl0ZXMuIFNvIEkg cmFuIGEgc2ltcGxlIHRlc3Qgb2YgYXBwZW5kaW5nIDIwLDAwMCB1bmlxdWUgMTAwIGJ5dGVzIGFz Y2lpIG1lc3NhZ2VzLiBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgdGhlIHJlcG9zaXRvcnkgc2l6ZSB0 byBiZSBvbiB0aGUgb3JkZXIgb2YgYSBmZXcgbWVnYWJ5dGVzLCBpbnN0ZWFkIGl0IHdhcyA0LjdH LiBUaGlzIGlzIHJvdWdobHkgMjM0SyBvdmVyaGVhZCBwZXIgMTAwIGJ5dGVzIG1lc3NhZ2UsIHdo aWNoIHdvdWxkIGJlIHF1aXRlIGltcHJhY3RpY2FsIGZvciB0aGUgZW1haWwgc3RvcmFnZSB3aXRo IHRoZSBtZXRhZGF0YSBlc3NlbnRpYWxseSBleGNlZWRpbmcgdGhlIG1lc3NhZ2Ugc3RvcmFnZS4K CkRpZCB5b3Ugc3RhcnQgZnJvbSBhbiBlbXB0eSByZXBvc2l0b3J5PyBXb3VsZCBiZSBpbnRlcmVz dGVkIHRvIHJ1biB5b3VyIGNvZGUgbG9jYWxseSB0byBjaGVjayB3aGF0IGhhcHBlbnMuIAoKTW9y ZSBnZW5lcmFsbHkgYWxsIHRoZSBiZW5jaHMvZXhwZXJpbWVudHMgeW91IGFyZSBydW5uaW5nIGFy ZSB2ZXJ5IHVzZWZ1bCwgaXQgd291bGQgYmUgbmljZSB0byBwdXQgdGhlbSBzb21ld2hlcmUgb25s aW5lIGFuZCB0dXJuIHRoZW0gaW50byBmdW5jdGlvbmFsIHRlc3RzIHRvIHJ1biB0aGVtIHJlZ3Vs YXJseSB0byBjaGVjayB0aGF0IHRoZSBzZXJpYWxpc2F0aW9uIGZvcm1hdCBkb2Vzbid0IGdvIGNy YXp5LgoKVGhhbmtzIQpUaG9tYXMKCgoKCj4gCj4gR3JlZ29yeQo+IAo+PiBPbiBEZWMgMzAsIDIw MTQsIGF0IDc6MDcgUE0sIEdyZWdvcnkgVHNpcGVueXVrIDxndDMwM0BjYW0uYWMudWs+IHdyb3Rl Ogo+PiAKPj4gSGkgVGhvbWFzLAo+PiAKPj4gSeKAmW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hh dCBraW5kIG9mIHN0b3JhZ2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGluIElybWluLiBGaXJz dCBJIHRyaWVkIHRvIGNvbnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZlICgyLjRHKSB0byB0 aGUgSU1BUCBzZXJ2ZXIgSXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lvbiB0aGUgc2l6ZSBv ZiB0aGUgZ2l0IHJlcG9zaXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBh cmNoaXZlLiBJIGRvIGhhdmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMgdGhhdCBJIGNyZWF0 ZSwgbGlrZSBwZXIgbWFpbGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0aWNzIGFuZCBwZXIg ZW1haWwgbWVzc2FnZSBmbGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXplIGlzIGNvbWluZyBm cm9tIHRob3NlIHN0cnVjdHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhpZ2guIEkgd2lsbCBo YXZlIHRvIGVzdGltYXRlIHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRpb25hbCBzdHJ1Y3R1 cmVzIHRvIHVuZGVyc3RhbmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQgaW50byBpcm1pbiAy LDAwMCBvZiAxTSBmaWxlcyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdoaWNoIHJlc3VsdGVk IGluIHRoZSBnaXQgcmVwb3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJlIElybWluIGNvbXBy ZXNzZXMgdGhlIGNvbnRlbnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1bXBlZCAyLDAwMCBv ZiAyLjRNIGltYWdlIGZpbGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIgdG8gbWFrZSB0aGUg Y29udGVudCB1bmlxdWUuIFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRoaXMgd2FzIDQuNkcs IHdoaWNoIGlzIGV4cGVjdGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3QgdGVzdCBidXQgd2l0 aCBpZGVudGljYWwgaW1hZ2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2FzIDI3TSwgd2hpY2gg d2FzIGNsZWFybHkgYSBuaWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJcm1pbi4gTXkgcXVl c3Rpb24gaXMgd2hldGhlciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMgY29uZmlndXJhYmxl PyBDYW4gaXQgYmUgY29uZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRlbnQ/IEZvciBpbnN0 YW5jZSwgSSBkb27igJl0IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRoZXJlIGlzIG5vdGhp bmcgdG8gZ2FpbiBmcm9tIHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVlbnRseSB0aGVyZSBp cyB1bm5lY2Vzc2FyeSByZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRvIGNvbXByZXNzIHRo ZSB0ZXh0IGlmIHRoZSBjb21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25hYmxlLiBJIGNhbiBm aWd1cmUgb3V0IHRoZSB0eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUgaW4gSU1BUCBzZXJ2 ZXIuCj4+IAo+PiBUaGFua3MgCj4+IEdyZWdvcnkKPiAKCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWly YWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qu b3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 10:32:12 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 10:32:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GZY-0004Qf-DW; Wed, 31 Dec 2014 10:32:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6GZX-0004Qa-Fl for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 10:32:11 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id 17/25-02707-AA0D3A45; Wed, 31 Dec 2014 10:32:10 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1420021929!12398332!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24205 invoked from network); 31 Dec 2014 10:32:10 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 31 Dec 2014 10:32:10 -0000 Received: by mail-wg0-f50.google.com with SMTP id a1so21897402wgh.37 for ; Wed, 31 Dec 2014 02:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5eF+Tz5zcIvMdbBqaA/Om72ka+SeFhc980jQppl9dDA=; b=IDM/BgkTFhlbWxY3ljyzyjaV/ryypmfjLsmRhf7xnVMzJPePiDVNYGwmYmGf/gW76e r47wGD4TWmI4f3pqPVMUzcqJ4nXJD/pStKP//afHHg4jgi20WviVthmvZ74R1aCc5PpS fnyXVC2omE7kmF7KHKFOQY7HttWxXy8OFpNDda8LP5hxVF/U801IKFKeafq9SzbUQUpe ko1DuoHKGFFBq0KmR3IcPv+LiRrHHZQgUHEDb+N19r8/i4IuMoDdGIMADRr46k9Pgk7z +mLFRShhinEUivz/yY6iMdp0TBKiF49BLRsAL/VXAX7tXfYjS3LXdcCBXRm6o49PJdx+ 2/Vw== X-Received: by 10.194.184.140 with SMTP id eu12mr111282440wjc.25.1420021929852; Wed, 31 Dec 2014 02:32:09 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id e18sm57066340wjz.27.2014.12.31.02.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Dec 2014 02:32:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> Date: Wed, 31 Dec 2014 11:32:11 +0100 Message-Id: <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org PiBJIGxvb2tlZCBhdCB0aGUgbWV0YWRhdGEgdGhhdCBnZXRzIGNyZWF0ZWQgZm9yIGV2ZXJ5IGVt YWlsIG1lc3NhZ2UgYW5kIGl04oCZcyBzbWFsbCAtIGxlc3MgdGhhbiAxMDAgYnl0ZXMuIFNvIEkg cmFuIGEgc2ltcGxlIHRlc3Qgb2YgYXBwZW5kaW5nIDIwLDAwMCB1bmlxdWUgMTAwIGJ5dGVzIGFz Y2lpIG1lc3NhZ2VzLiBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgdGhlIHJlcG9zaXRvcnkgc2l6ZSB0 byBiZSBvbiB0aGUgb3JkZXIgb2YgYSBmZXcgbWVnYWJ5dGVzLCBpbnN0ZWFkIGl0IHdhcyA0LjdH LiBUaGlzIGlzIHJvdWdobHkgMjM0SyBvdmVyaGVhZCBwZXIgMTAwIGJ5dGVzIG1lc3NhZ2UsIHdo aWNoIHdvdWxkIGJlIHF1aXRlIGltcHJhY3RpY2FsIGZvciB0aGUgZW1haWwgc3RvcmFnZSB3aXRo IHRoZSBtZXRhZGF0YSBlc3NlbnRpYWxseSBleGNlZWRpbmcgdGhlIG1lc3NhZ2Ugc3RvcmFnZS4K CkRpZCB5b3Ugc3RhcnQgZnJvbSBhbiBlbXB0eSByZXBvc2l0b3J5PyBXb3VsZCBiZSBpbnRlcmVz dGVkIHRvIHJ1biB5b3VyIGNvZGUgbG9jYWxseSB0byBjaGVjayB3aGF0IGhhcHBlbnMuIAoKTW9y ZSBnZW5lcmFsbHkgYWxsIHRoZSBiZW5jaHMvZXhwZXJpbWVudHMgeW91IGFyZSBydW5uaW5nIGFy ZSB2ZXJ5IHVzZWZ1bCwgaXQgd291bGQgYmUgbmljZSB0byBwdXQgdGhlbSBzb21ld2hlcmUgb25s aW5lIGFuZCB0dXJuIHRoZW0gaW50byBmdW5jdGlvbmFsIHRlc3RzIHRvIHJ1biB0aGVtIHJlZ3Vs YXJseSB0byBjaGVjayB0aGF0IHRoZSBzZXJpYWxpc2F0aW9uIGZvcm1hdCBkb2Vzbid0IGdvIGNy YXp5LgoKVGhhbmtzIQpUaG9tYXMKCgoKCj4gCj4gR3JlZ29yeQo+IAo+PiBPbiBEZWMgMzAsIDIw MTQsIGF0IDc6MDcgUE0sIEdyZWdvcnkgVHNpcGVueXVrIDxndDMwM0BjYW0uYWMudWs+IHdyb3Rl Ogo+PiAKPj4gSGkgVGhvbWFzLAo+PiAKPj4gSeKAmW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hh dCBraW5kIG9mIHN0b3JhZ2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGluIElybWluLiBGaXJz dCBJIHRyaWVkIHRvIGNvbnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZlICgyLjRHKSB0byB0 aGUgSU1BUCBzZXJ2ZXIgSXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lvbiB0aGUgc2l6ZSBv ZiB0aGUgZ2l0IHJlcG9zaXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBh cmNoaXZlLiBJIGRvIGhhdmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMgdGhhdCBJIGNyZWF0 ZSwgbGlrZSBwZXIgbWFpbGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0aWNzIGFuZCBwZXIg ZW1haWwgbWVzc2FnZSBmbGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXplIGlzIGNvbWluZyBm cm9tIHRob3NlIHN0cnVjdHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhpZ2guIEkgd2lsbCBo YXZlIHRvIGVzdGltYXRlIHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRpb25hbCBzdHJ1Y3R1 cmVzIHRvIHVuZGVyc3RhbmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQgaW50byBpcm1pbiAy LDAwMCBvZiAxTSBmaWxlcyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdoaWNoIHJlc3VsdGVk IGluIHRoZSBnaXQgcmVwb3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJlIElybWluIGNvbXBy ZXNzZXMgdGhlIGNvbnRlbnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1bXBlZCAyLDAwMCBv ZiAyLjRNIGltYWdlIGZpbGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIgdG8gbWFrZSB0aGUg Y29udGVudCB1bmlxdWUuIFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRoaXMgd2FzIDQuNkcs IHdoaWNoIGlzIGV4cGVjdGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3QgdGVzdCBidXQgd2l0 aCBpZGVudGljYWwgaW1hZ2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2FzIDI3TSwgd2hpY2gg d2FzIGNsZWFybHkgYSBuaWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJcm1pbi4gTXkgcXVl c3Rpb24gaXMgd2hldGhlciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMgY29uZmlndXJhYmxl PyBDYW4gaXQgYmUgY29uZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRlbnQ/IEZvciBpbnN0 YW5jZSwgSSBkb27igJl0IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRoZXJlIGlzIG5vdGhp bmcgdG8gZ2FpbiBmcm9tIHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVlbnRseSB0aGVyZSBp cyB1bm5lY2Vzc2FyeSByZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRvIGNvbXByZXNzIHRo ZSB0ZXh0IGlmIHRoZSBjb21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25hYmxlLiBJIGNhbiBm aWd1cmUgb3V0IHRoZSB0eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUgaW4gSU1BUCBzZXJ2 ZXIuCj4+IAo+PiBUaGFua3MgCj4+IEdyZWdvcnkKPiAKCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpNaXJhZ2VPUy1kZXZlbCBtYWlsaW5nIGxpc3QKTWly YWdlT1MtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qu b3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9taXJhZ2Vvcy1kZXZlbAo= From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 11:13:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 11:13:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6HDm-00058M-Np; Wed, 31 Dec 2014 11:13:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6HDl-00058H-Gp for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 11:13:45 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id B8/D3-09842-86AD3A45; Wed, 31 Dec 2014 11:13:44 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1420024424!18275567!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24715 invoked from network); 31 Dec 2014 11:13:44 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 31 Dec 2014 11:13:44 -0000 Received: by mail-wg0-f45.google.com with SMTP id b13so21864492wgh.32 for ; Wed, 31 Dec 2014 03:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pTYk5HlPp2Uup6ZgvtA6ImosYW7DXejEgoTHZ028AKc=; b=MRMOY35xSDUq7H/chaA8rphFjMd9eS96xPCcZwvx5vkmYKOt3JwyFha0J0tt1FTb4o zxzYTLG9w3tM391fIzVgDTq2xTYXinTdjhG5PuccSPuudOhWe8JaTHUSdcWiCApu9usz EK171pK2jgjCO/BWtNii4z3bCKFBSmK8QvKcG6uJKrgyjoYPD+LBMd/lAWrJ7zIKmh+j ugUntqwt9WnSho0TLE5tQKrGVHKnmWFnECeOBhvt+wtpZKFvdWYQwNX8iw59DpRNtZhb xHZJobtMfUHzNlBfw+GQ69SuHcrgNCtl9hiupKKHkQiXsHHK+FD7W4F+EoXQJg6RnIgY nFjA== X-Received: by 10.194.90.81 with SMTP id bu17mr38372118wjb.3.1420024423975; Wed, 31 Dec 2014 03:13:43 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id be4sm46715336wib.16.2014.12.31.03.13.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Dec 2014 03:13:42 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> Date: Wed, 31 Dec 2014 12:13:46 +0100 Message-Id: <13DED803-7891-4D52-8384-346410BE3708@gazagnaire.org> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Pj4gSSBsb29rZWQgYXQgdGhlIG1ldGFkYXRhIHRoYXQgZ2V0cyBjcmVhdGVkIGZvciBldmVyeSBl bWFpbCBtZXNzYWdlIGFuZCBpdOKAmXMgc21hbGwgLSBsZXNzIHRoYW4gMTAwIGJ5dGVzLiBTbyBJ IHJhbiBhIHNpbXBsZSB0ZXN0IG9mIGFwcGVuZGluZyAyMCwwMDAgdW5pcXVlIDEwMCBieXRlcyBh c2NpaSBtZXNzYWdlcy4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSByZXBvc2l0b3J5IHNpemUg dG8gYmUgb24gdGhlIG9yZGVyIG9mIGEgZmV3IG1lZ2FieXRlcywgaW5zdGVhZCBpdCB3YXMgNC43 Ry4gVGhpcyBpcyByb3VnaGx5IDIzNEsgb3ZlcmhlYWQgcGVyIDEwMCBieXRlcyBtZXNzYWdlLCB3 aGljaCB3b3VsZCBiZSBxdWl0ZSBpbXByYWN0aWNhbCBmb3IgdGhlIGVtYWlsIHN0b3JhZ2Ugd2l0 aCB0aGUgbWV0YWRhdGEgZXNzZW50aWFsbHkgZXhjZWVkaW5nIHRoZSBtZXNzYWdlIHN0b3JhZ2Uu Cj4gCj4gRGlkIHlvdSBzdGFydCBmcm9tIGFuIGVtcHR5IHJlcG9zaXRvcnk/IFdvdWxkIGJlIGlu dGVyZXN0ZWQgdG8gcnVuIHlvdXIgY29kZSBsb2NhbGx5IHRvIGNoZWNrIHdoYXQgaGFwcGVucy4g CgpEaWQgeW91IGFkZCB0aGUgbWVzc2FnZSBzZXF1ZW50aWFsbHkgb3IgZGlkIHlvdSB1c2UgYSB2 aWV3PyBJZiB5b3UgaGF2ZSAyMGsgY29tbWl0cyAod2hpY2ggYXJlIGF0IGxlYXN0IDRrKSwgYnV0 IHlvdSBhbHNvIGhhdmUgMjBrIGRpZmZlcmVudCBkaXJlY3RvcmllcyAod2hpY2ggY29udGFpbiAx LCAyLCAzLCAuLi4gMjBrIGZpbGVzKS4gV2hhdCdzIHRoZSBzaXplIG9mIHlvdXIgZmlsZW5hbWVz LiBUaGV5IGFyZSBzZXJpYWxpemVkIGluIHRoZSBkaXJlY3RvcnkgbWV0YWRhdGEsIHNvIGlmIHlv dSBoYXZlIDEwIGJ5dGUgZmlsZW5hbWVzLCB5b3Ugc2hvdWxkIGluZGVlZCBleHBlY3QgdGhlIGxh c3QgZGlyZWN0b3J5IG1ldGFkYXRhIHRvIGJlIGFyb3VuZCAyMGsqMTAgKG1heWJlIGEgYml0IGxl c3MgYXMgaXQgaXMgY29tcHJlc3NlZCkuIEFueXdheSwgdGhlIEdpdCBmb3JtYXQgaXMgbm90IHZl cnkgZmxleGlibGUgKGFzIHdlIHdhbnQgdG8ga2VlcCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIEdp dCBmb3JtYXQpIGJ1dCB0aGF0IHVzZWZ1bCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgbm90IG9wdGlt YWwgdG8gaW1wcm92ZSBpdCBpbiB0aGUgY3VzdG9tIGJhY2tlbmQuCgpUaG9tYXMKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFp bGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 11:13:48 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 11:13:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6HDm-00058M-Np; Wed, 31 Dec 2014 11:13:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6HDl-00058H-Gp for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 11:13:45 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id B8/D3-09842-86AD3A45; Wed, 31 Dec 2014 11:13:44 +0000 X-Env-Sender: thomas.gazagnaire@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1420024424!18275567!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24715 invoked from network); 31 Dec 2014 11:13:44 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 31 Dec 2014 11:13:44 -0000 Received: by mail-wg0-f45.google.com with SMTP id b13so21864492wgh.32 for ; Wed, 31 Dec 2014 03:13:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pTYk5HlPp2Uup6ZgvtA6ImosYW7DXejEgoTHZ028AKc=; b=MRMOY35xSDUq7H/chaA8rphFjMd9eS96xPCcZwvx5vkmYKOt3JwyFha0J0tt1FTb4o zxzYTLG9w3tM391fIzVgDTq2xTYXinTdjhG5PuccSPuudOhWe8JaTHUSdcWiCApu9usz EK171pK2jgjCO/BWtNii4z3bCKFBSmK8QvKcG6uJKrgyjoYPD+LBMd/lAWrJ7zIKmh+j ugUntqwt9WnSho0TLE5tQKrGVHKnmWFnECeOBhvt+wtpZKFvdWYQwNX8iw59DpRNtZhb xHZJobtMfUHzNlBfw+GQ69SuHcrgNCtl9hiupKKHkQiXsHHK+FD7W4F+EoXQJg6RnIgY nFjA== X-Received: by 10.194.90.81 with SMTP id bu17mr38372118wjb.3.1420024423975; Wed, 31 Dec 2014 03:13:43 -0800 (PST) Received: from [192.168.1.44] (car06-8-83-155-104-81.fbx.proxad.net. [83.155.104.81]) by mx.google.com with ESMTPSA id be4sm46715336wib.16.2014.12.31.03.13.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Dec 2014 03:13:42 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Thomas Gazagnaire In-Reply-To: <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> Date: Wed, 31 Dec 2014 12:13:46 +0100 Message-Id: <13DED803-7891-4D52-8384-346410BE3708@gazagnaire.org> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> To: Gregory Tsipenyuk X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Pj4gSSBsb29rZWQgYXQgdGhlIG1ldGFkYXRhIHRoYXQgZ2V0cyBjcmVhdGVkIGZvciBldmVyeSBl bWFpbCBtZXNzYWdlIGFuZCBpdOKAmXMgc21hbGwgLSBsZXNzIHRoYW4gMTAwIGJ5dGVzLiBTbyBJ IHJhbiBhIHNpbXBsZSB0ZXN0IG9mIGFwcGVuZGluZyAyMCwwMDAgdW5pcXVlIDEwMCBieXRlcyBh c2NpaSBtZXNzYWdlcy4gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRoZSByZXBvc2l0b3J5IHNpemUg dG8gYmUgb24gdGhlIG9yZGVyIG9mIGEgZmV3IG1lZ2FieXRlcywgaW5zdGVhZCBpdCB3YXMgNC43 Ry4gVGhpcyBpcyByb3VnaGx5IDIzNEsgb3ZlcmhlYWQgcGVyIDEwMCBieXRlcyBtZXNzYWdlLCB3 aGljaCB3b3VsZCBiZSBxdWl0ZSBpbXByYWN0aWNhbCBmb3IgdGhlIGVtYWlsIHN0b3JhZ2Ugd2l0 aCB0aGUgbWV0YWRhdGEgZXNzZW50aWFsbHkgZXhjZWVkaW5nIHRoZSBtZXNzYWdlIHN0b3JhZ2Uu Cj4gCj4gRGlkIHlvdSBzdGFydCBmcm9tIGFuIGVtcHR5IHJlcG9zaXRvcnk/IFdvdWxkIGJlIGlu dGVyZXN0ZWQgdG8gcnVuIHlvdXIgY29kZSBsb2NhbGx5IHRvIGNoZWNrIHdoYXQgaGFwcGVucy4g CgpEaWQgeW91IGFkZCB0aGUgbWVzc2FnZSBzZXF1ZW50aWFsbHkgb3IgZGlkIHlvdSB1c2UgYSB2 aWV3PyBJZiB5b3UgaGF2ZSAyMGsgY29tbWl0cyAod2hpY2ggYXJlIGF0IGxlYXN0IDRrKSwgYnV0 IHlvdSBhbHNvIGhhdmUgMjBrIGRpZmZlcmVudCBkaXJlY3RvcmllcyAod2hpY2ggY29udGFpbiAx LCAyLCAzLCAuLi4gMjBrIGZpbGVzKS4gV2hhdCdzIHRoZSBzaXplIG9mIHlvdXIgZmlsZW5hbWVz LiBUaGV5IGFyZSBzZXJpYWxpemVkIGluIHRoZSBkaXJlY3RvcnkgbWV0YWRhdGEsIHNvIGlmIHlv dSBoYXZlIDEwIGJ5dGUgZmlsZW5hbWVzLCB5b3Ugc2hvdWxkIGluZGVlZCBleHBlY3QgdGhlIGxh c3QgZGlyZWN0b3J5IG1ldGFkYXRhIHRvIGJlIGFyb3VuZCAyMGsqMTAgKG1heWJlIGEgYml0IGxl c3MgYXMgaXQgaXMgY29tcHJlc3NlZCkuIEFueXdheSwgdGhlIEdpdCBmb3JtYXQgaXMgbm90IHZl cnkgZmxleGlibGUgKGFzIHdlIHdhbnQgdG8ga2VlcCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIEdp dCBmb3JtYXQpIGJ1dCB0aGF0IHVzZWZ1bCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgbm90IG9wdGlt YWwgdG8gaW1wcm92ZSBpdCBpbiB0aGUgY3VzdG9tIGJhY2tlbmQuCgpUaG9tYXMKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFp bGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 14:47:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 14:47:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6KYd-0000lH-KE; Wed, 31 Dec 2014 14:47:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6KYc-0000lC-PA for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 14:47:30 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id D2/9D-15461-28C04A45; Wed, 31 Dec 2014 14:47:30 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-11.tower-21.messagelabs.com!1420037248!18618610!1 X-Originating-IP: [131.111.8.140] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29904 invoked from network); 31 Dec 2014 14:47:29 -0000 Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk) (131.111.8.140) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 14:47:29 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62654 helo=[192.168.0.6]) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6KYa-0001Nt-jR (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 14:47:28 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> Date: Wed, 31 Dec 2014 09:47:26 -0500 Message-Id: <5E1D07D9-A6A7-49E1-94F1-4C2750F1F75D@cam.ac.uk> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SSByYW4gYWxsIHRlc3RzIG9uIGVtcHR5IHJlcG9zaXRvcmllcy4KCkRvZXMgaXQgbWFrZSBzZW5z ZSB0byBoYXZlIOKAnGJlbmNobWFya+KAnSBmb2xkZXIgdW5kZXIgSXJtaW4gdG8gY2hlY2sgaW4g dGhlIHRlc3RzPwoKPiBPbiBEZWMgMzEsIDIwMTQsIGF0IDU6MzIgQU0sIFRob21hcyBHYXphZ25h aXJlIDx0aG9tYXNAZ2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+IAo+PiBJIGxvb2tlZCBhdCB0aGUg bWV0YWRhdGEgdGhhdCBnZXRzIGNyZWF0ZWQgZm9yIGV2ZXJ5IGVtYWlsIG1lc3NhZ2UgYW5kIGl0 4oCZcyBzbWFsbCAtIGxlc3MgdGhhbiAxMDAgYnl0ZXMuIFNvIEkgcmFuIGEgc2ltcGxlIHRlc3Qg b2YgYXBwZW5kaW5nIDIwLDAwMCB1bmlxdWUgMTAwIGJ5dGVzIGFzY2lpIG1lc3NhZ2VzLiBJIHdv dWxkIGhhdmUgZXhwZWN0ZWQgdGhlIHJlcG9zaXRvcnkgc2l6ZSB0byBiZSBvbiB0aGUgb3JkZXIg b2YgYSBmZXcgbWVnYWJ5dGVzLCBpbnN0ZWFkIGl0IHdhcyA0LjdHLiBUaGlzIGlzIHJvdWdobHkg MjM0SyBvdmVyaGVhZCBwZXIgMTAwIGJ5dGVzIG1lc3NhZ2UsIHdoaWNoIHdvdWxkIGJlIHF1aXRl IGltcHJhY3RpY2FsIGZvciB0aGUgZW1haWwgc3RvcmFnZSB3aXRoIHRoZSBtZXRhZGF0YSBlc3Nl bnRpYWxseSBleGNlZWRpbmcgdGhlIG1lc3NhZ2Ugc3RvcmFnZS4KPiAKPiBEaWQgeW91IHN0YXJ0 IGZyb20gYW4gZW1wdHkgcmVwb3NpdG9yeT8gV291bGQgYmUgaW50ZXJlc3RlZCB0byBydW4geW91 ciBjb2RlIGxvY2FsbHkgdG8gY2hlY2sgd2hhdCBoYXBwZW5zLiAKPiAKPiBNb3JlIGdlbmVyYWxs eSBhbGwgdGhlIGJlbmNocy9leHBlcmltZW50cyB5b3UgYXJlIHJ1bm5pbmcgYXJlIHZlcnkgdXNl ZnVsLCBpdCB3b3VsZCBiZSBuaWNlIHRvIHB1dCB0aGVtIHNvbWV3aGVyZSBvbmxpbmUgYW5kIHR1 cm4gdGhlbSBpbnRvIGZ1bmN0aW9uYWwgdGVzdHMgdG8gcnVuIHRoZW0gcmVndWxhcmx5IHRvIGNo ZWNrIHRoYXQgdGhlIHNlcmlhbGlzYXRpb24gZm9ybWF0IGRvZXNuJ3QgZ28gY3JhenkuCj4gCj4g VGhhbmtzIQo+IFRob21hcwo+IAo+IAo+IAo+IAo+PiAKPj4gR3JlZ29yeQo+PiAKPj4+IE9uIERl YyAzMCwgMjAxNCwgYXQgNzowNyBQTSwgR3JlZ29yeSBUc2lwZW55dWsgPGd0MzAzQGNhbS5hYy51 az4gd3JvdGU6Cj4+PiAKPj4+IEhpIFRob21hcywKPj4+IAo+Pj4gSeKAmW0gdHJ5aW5nIHRvIGZp Z3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0b3JhZ2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGlu IElybWluLiBGaXJzdCBJIHRyaWVkIHRvIGNvbnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZl ICgyLjRHKSB0byB0aGUgSU1BUCBzZXJ2ZXIgSXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lv biB0aGUgc2l6ZSBvZiB0aGUgZ2l0IHJlcG9zaXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRo ZSBvcmlnaW5hbCBhcmNoaXZlLiBJIGRvIGhhdmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMg dGhhdCBJIGNyZWF0ZSwgbGlrZSBwZXIgbWFpbGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0 aWNzIGFuZCBwZXIgZW1haWwgbWVzc2FnZSBmbGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXpl IGlzIGNvbWluZyBmcm9tIHRob3NlIHN0cnVjdHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhp Z2guIEkgd2lsbCBoYXZlIHRvIGVzdGltYXRlIHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRp b25hbCBzdHJ1Y3R1cmVzIHRvIHVuZGVyc3RhbmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQg aW50byBpcm1pbiAyLDAwMCBvZiAxTSBmaWxlcyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdo aWNoIHJlc3VsdGVkIGluIHRoZSBnaXQgcmVwb3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJl IElybWluIGNvbXByZXNzZXMgdGhlIGNvbnRlbnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1 bXBlZCAyLDAwMCBvZiAyLjRNIGltYWdlIGZpbGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIg dG8gbWFrZSB0aGUgY29udGVudCB1bmlxdWUuIFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRo aXMgd2FzIDQuNkcsIHdoaWNoIGlzIGV4cGVjdGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3Qg dGVzdCBidXQgd2l0aCBpZGVudGljYWwgaW1hZ2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2Fz IDI3TSwgd2hpY2ggd2FzIGNsZWFybHkgYSBuaWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJ cm1pbi4gTXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMg Y29uZmlndXJhYmxlPyBDYW4gaXQgYmUgY29uZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRl bnQ/IEZvciBpbnN0YW5jZSwgSSBkb27igJl0IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRo ZXJlIGlzIG5vdGhpbmcgdG8gZ2FpbiBmcm9tIHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVl bnRseSB0aGVyZSBpcyB1bm5lY2Vzc2FyeSByZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRv IGNvbXByZXNzIHRoZSB0ZXh0IGlmIHRoZSBjb21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25h YmxlLiBJIGNhbiBmaWd1cmUgb3V0IHRoZSB0eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUg aW4gSU1BUCBzZXJ2ZXIuCj4+PiAKPj4+IFRoYW5rcyAKPj4+IEdyZWdvcnkKPj4gCj4gCgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2 ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6 Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3Mt ZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 14:47:39 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 14:47:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6KYd-0000lH-KE; Wed, 31 Dec 2014 14:47:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6KYc-0000lC-PA for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 14:47:30 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id D2/9D-15461-28C04A45; Wed, 31 Dec 2014 14:47:30 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-11.tower-21.messagelabs.com!1420037248!18618610!1 X-Originating-IP: [131.111.8.140] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29904 invoked from network); 31 Dec 2014 14:47:29 -0000 Received: from ppsw-40.csi.cam.ac.uk (HELO ppsw-40.csi.cam.ac.uk) (131.111.8.140) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 14:47:29 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62654 helo=[192.168.0.6]) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6KYa-0001Nt-jR (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 14:47:28 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> Date: Wed, 31 Dec 2014 09:47:26 -0500 Message-Id: <5E1D07D9-A6A7-49E1-94F1-4C2750F1F75D@cam.ac.uk> References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SSByYW4gYWxsIHRlc3RzIG9uIGVtcHR5IHJlcG9zaXRvcmllcy4KCkRvZXMgaXQgbWFrZSBzZW5z ZSB0byBoYXZlIOKAnGJlbmNobWFya+KAnSBmb2xkZXIgdW5kZXIgSXJtaW4gdG8gY2hlY2sgaW4g dGhlIHRlc3RzPwoKPiBPbiBEZWMgMzEsIDIwMTQsIGF0IDU6MzIgQU0sIFRob21hcyBHYXphZ25h aXJlIDx0aG9tYXNAZ2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+IAo+PiBJIGxvb2tlZCBhdCB0aGUg bWV0YWRhdGEgdGhhdCBnZXRzIGNyZWF0ZWQgZm9yIGV2ZXJ5IGVtYWlsIG1lc3NhZ2UgYW5kIGl0 4oCZcyBzbWFsbCAtIGxlc3MgdGhhbiAxMDAgYnl0ZXMuIFNvIEkgcmFuIGEgc2ltcGxlIHRlc3Qg b2YgYXBwZW5kaW5nIDIwLDAwMCB1bmlxdWUgMTAwIGJ5dGVzIGFzY2lpIG1lc3NhZ2VzLiBJIHdv dWxkIGhhdmUgZXhwZWN0ZWQgdGhlIHJlcG9zaXRvcnkgc2l6ZSB0byBiZSBvbiB0aGUgb3JkZXIg b2YgYSBmZXcgbWVnYWJ5dGVzLCBpbnN0ZWFkIGl0IHdhcyA0LjdHLiBUaGlzIGlzIHJvdWdobHkg MjM0SyBvdmVyaGVhZCBwZXIgMTAwIGJ5dGVzIG1lc3NhZ2UsIHdoaWNoIHdvdWxkIGJlIHF1aXRl IGltcHJhY3RpY2FsIGZvciB0aGUgZW1haWwgc3RvcmFnZSB3aXRoIHRoZSBtZXRhZGF0YSBlc3Nl bnRpYWxseSBleGNlZWRpbmcgdGhlIG1lc3NhZ2Ugc3RvcmFnZS4KPiAKPiBEaWQgeW91IHN0YXJ0 IGZyb20gYW4gZW1wdHkgcmVwb3NpdG9yeT8gV291bGQgYmUgaW50ZXJlc3RlZCB0byBydW4geW91 ciBjb2RlIGxvY2FsbHkgdG8gY2hlY2sgd2hhdCBoYXBwZW5zLiAKPiAKPiBNb3JlIGdlbmVyYWxs eSBhbGwgdGhlIGJlbmNocy9leHBlcmltZW50cyB5b3UgYXJlIHJ1bm5pbmcgYXJlIHZlcnkgdXNl ZnVsLCBpdCB3b3VsZCBiZSBuaWNlIHRvIHB1dCB0aGVtIHNvbWV3aGVyZSBvbmxpbmUgYW5kIHR1 cm4gdGhlbSBpbnRvIGZ1bmN0aW9uYWwgdGVzdHMgdG8gcnVuIHRoZW0gcmVndWxhcmx5IHRvIGNo ZWNrIHRoYXQgdGhlIHNlcmlhbGlzYXRpb24gZm9ybWF0IGRvZXNuJ3QgZ28gY3JhenkuCj4gCj4g VGhhbmtzIQo+IFRob21hcwo+IAo+IAo+IAo+IAo+PiAKPj4gR3JlZ29yeQo+PiAKPj4+IE9uIERl YyAzMCwgMjAxNCwgYXQgNzowNyBQTSwgR3JlZ29yeSBUc2lwZW55dWsgPGd0MzAzQGNhbS5hYy51 az4gd3JvdGU6Cj4+PiAKPj4+IEhpIFRob21hcywKPj4+IAo+Pj4gSeKAmW0gdHJ5aW5nIHRvIGZp Z3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0b3JhZ2Ugb3ZlcmhlYWQgYW5kIGRlZHVwIEkgZ2V0IGlu IElybWluLiBGaXJzdCBJIHRyaWVkIHRvIGNvbnZlcnQgdGhlIGdvb2dsZSBlbWFpbCBhcmNoaXZl ICgyLjRHKSB0byB0aGUgSU1BUCBzZXJ2ZXIgSXJtaW4gZm9ybWF0IC4gQWZ0ZXIgY29udmVyc2lv biB0aGUgc2l6ZSBvZiB0aGUgZ2l0IHJlcG9zaXRvcnkgd2FzIHR3aWNlIHRoZSBzaXplIG9mIHRo ZSBvcmlnaW5hbCBhcmNoaXZlLiBJIGRvIGhhdmUgc29tZSBhZGRpdGlvbmFsIHN0cnVjdHVyZXMg dGhhdCBJIGNyZWF0ZSwgbGlrZSBwZXIgbWFpbGJveCBpbmRleCBhbmQgc3VtbWFyeSBzdGF0aXN0 aWNzIGFuZCBwZXIgZW1haWwgbWVzc2FnZSBmbGFncyBzbyBwZXJoYXBzIHRoZSBleHRyYSBzaXpl IGlzIGNvbWluZyBmcm9tIHRob3NlIHN0cnVjdHVyZXMgdGhvdWdoIGl0IHNlZW1zIGEgYml0IGhp Z2guIEkgd2lsbCBoYXZlIHRvIGVzdGltYXRlIHRoZSBleHBlY3RlZCBzaXplIGZyb20gYWRkaXRp b25hbCBzdHJ1Y3R1cmVzIHRvIHVuZGVyc3RhbmQgdGhpcyByZXN1bHQuIE5leHQgSSBkdW1wZWQg aW50byBpcm1pbiAyLDAwMCBvZiAxTSBmaWxlcyB3aXRoIHJhbmRvbSBhc2NpaSBjb250ZW50IHdo aWNoIHJlc3VsdGVkIGluIHRoZSBnaXQgcmVwb3NpdG9yeSBzaXplIG9mIDk1ME0uIEkgZmlndXJl IElybWluIGNvbXByZXNzZXMgdGhlIGNvbnRlbnQsIHJpZ2h0PyBUbyB2ZXJpZnkgdGhpcyBJIGR1 bXBlZCAyLDAwMCBvZiAyLjRNIGltYWdlIGZpbGVzIHdpdGggY29uY2F0ZW5hdGVkIGNvdW50ZXIg dG8gbWFrZSB0aGUgY29udGVudCB1bmlxdWUuIFRoZSBzaXplIG9mIHJlcG9zaXRvcnkgZm9yIHRo aXMgd2FzIDQuNkcsIHdoaWNoIGlzIGV4cGVjdGVkLiBUaGVuIEkgcmVwZWF0ZWQgdGhlIGxhc3Qg dGVzdCBidXQgd2l0aCBpZGVudGljYWwgaW1hZ2VzIGFuZCB0aGlzIHRpbWUgdGhlIHNpemUgd2Fz IDI3TSwgd2hpY2ggd2FzIGNsZWFybHkgYSBuaWNlIHByb29mIG9mIHRoZSBkZWR1cGluZyBieSBJ cm1pbi4gTXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgY29tcHJlc3Npb24gaW4gSXJtaW4gaXMg Y29uZmlndXJhYmxlPyBDYW4gaXQgYmUgY29uZmlndXJhYmxlIHBlciBpbmRpdmlkdWFsIGNvbnRl bnQ/IEZvciBpbnN0YW5jZSwgSSBkb27igJl0IHdhbnQgdG8gY29tcHJlc3MgaW1hZ2VzIGFzIHRo ZXJlIGlzIG5vdGhpbmcgdG8gZ2FpbiBmcm9tIHRoZSBzcGFjZSBzYXZpbmcgYW5kIGNvbnNlcXVl bnRseSB0aGVyZSBpcyB1bm5lY2Vzc2FyeSByZXNvdXJjZSB1c2FnZSBidXQgSSBkbyB3YW50IHRv IGNvbXByZXNzIHRoZSB0ZXh0IGlmIHRoZSBjb21wcmVzc2lvbiBvdmVyaGVhZCBpcyByZWFzb25h YmxlLiBJIGNhbiBmaWd1cmUgb3V0IHRoZSB0eXBlIG9mIGNvbnRlbnQgZnJvbSBNSU1FIHR5cGUg aW4gSU1BUCBzZXJ2ZXIuCj4+PiAKPj4+IFRoYW5rcyAKPj4+IEdyZWdvcnkKPj4gCj4gCgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2 ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9TLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6 Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3Mt ZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 14:54:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 14:54:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Kfm-0000vN-87; Wed, 31 Dec 2014 14:54:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Kfl-0000vI-4Q for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 14:54:53 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 4F/D4-25276-C3E04A45; Wed, 31 Dec 2014 14:54:52 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-15.tower-21.messagelabs.com!1420037691!18633617!1 X-Originating-IP: [131.111.8.151] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23510 invoked from network); 31 Dec 2014 14:54:51 -0000 Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk) (131.111.8.151) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 14:54:51 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62680 helo=[192.168.0.6]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6Kfi-0004aC-YP (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 14:54:51 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <13DED803-7891-4D52-8384-346410BE3708@gazagnaire.org> Date: Wed, 31 Dec 2014 09:54:49 -0500 Message-Id: References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> <13DED803-7891-4D52-8384-346410BE3708@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SSB0cmllZCBhZGRpbmcgYm90aCB3aXRoL3dpdGhvdXQgdGhlIHZpZXcgd2l0aCB0aGUgc2FtZSBy ZXN1bHQuIEZpbGVuYW1lIHNpemUgaXMgc21hbGwgLSBhcm91bmQgMTAgYnl0ZXMuCldoYXQgZG8g eW91IHRoaW5rIGlzIHRoZSBiZXN0IGJhY2tlbmQgZm9ybWF0IHRvIHVzZSBmb3IgZW1haWxzPwoK PiBPbiBEZWMgMzEsIDIwMTQsIGF0IDY6MTMgQU0sIFRob21hcyBHYXphZ25haXJlIDx0aG9tYXNA Z2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+IAo+Pj4gSSBsb29rZWQgYXQgdGhlIG1ldGFkYXRhIHRo YXQgZ2V0cyBjcmVhdGVkIGZvciBldmVyeSBlbWFpbCBtZXNzYWdlIGFuZCBpdOKAmXMgc21hbGwg LSBsZXNzIHRoYW4gMTAwIGJ5dGVzLiBTbyBJIHJhbiBhIHNpbXBsZSB0ZXN0IG9mIGFwcGVuZGlu ZyAyMCwwMDAgdW5pcXVlIDEwMCBieXRlcyBhc2NpaSBtZXNzYWdlcy4gSSB3b3VsZCBoYXZlIGV4 cGVjdGVkIHRoZSByZXBvc2l0b3J5IHNpemUgdG8gYmUgb24gdGhlIG9yZGVyIG9mIGEgZmV3IG1l Z2FieXRlcywgaW5zdGVhZCBpdCB3YXMgNC43Ry4gVGhpcyBpcyByb3VnaGx5IDIzNEsgb3Zlcmhl YWQgcGVyIDEwMCBieXRlcyBtZXNzYWdlLCB3aGljaCB3b3VsZCBiZSBxdWl0ZSBpbXByYWN0aWNh bCBmb3IgdGhlIGVtYWlsIHN0b3JhZ2Ugd2l0aCB0aGUgbWV0YWRhdGEgZXNzZW50aWFsbHkgZXhj ZWVkaW5nIHRoZSBtZXNzYWdlIHN0b3JhZ2UuCj4+IAo+PiBEaWQgeW91IHN0YXJ0IGZyb20gYW4g ZW1wdHkgcmVwb3NpdG9yeT8gV291bGQgYmUgaW50ZXJlc3RlZCB0byBydW4geW91ciBjb2RlIGxv Y2FsbHkgdG8gY2hlY2sgd2hhdCBoYXBwZW5zLiAKPiAKPiBEaWQgeW91IGFkZCB0aGUgbWVzc2Fn ZSBzZXF1ZW50aWFsbHkgb3IgZGlkIHlvdSB1c2UgYSB2aWV3PyBJZiB5b3UgaGF2ZSAyMGsgY29t bWl0cyAod2hpY2ggYXJlIGF0IGxlYXN0IDRrKSwgYnV0IHlvdSBhbHNvIGhhdmUgMjBrIGRpZmZl cmVudCBkaXJlY3RvcmllcyAod2hpY2ggY29udGFpbiAxLCAyLCAzLCAuLi4gMjBrIGZpbGVzKS4g V2hhdCdzIHRoZSBzaXplIG9mIHlvdXIgZmlsZW5hbWVzLiBUaGV5IGFyZSBzZXJpYWxpemVkIGlu IHRoZSBkaXJlY3RvcnkgbWV0YWRhdGEsIHNvIGlmIHlvdSBoYXZlIDEwIGJ5dGUgZmlsZW5hbWVz LCB5b3Ugc2hvdWxkIGluZGVlZCBleHBlY3QgdGhlIGxhc3QgZGlyZWN0b3J5IG1ldGFkYXRhIHRv IGJlIGFyb3VuZCAyMGsqMTAgKG1heWJlIGEgYml0IGxlc3MgYXMgaXQgaXMgY29tcHJlc3NlZCku IEFueXdheSwgdGhlIEdpdCBmb3JtYXQgaXMgbm90IHZlcnkgZmxleGlibGUgKGFzIHdlIHdhbnQg dG8ga2VlcCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIEdpdCBmb3JtYXQpIGJ1dCB0aGF0IHVzZWZ1 bCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgbm90IG9wdGltYWwgdG8gaW1wcm92ZSBpdCBpbiB0aGUg Y3VzdG9tIGJhY2tlbmQuCj4gCj4gVGhvbWFzCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9j Z2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 14:54:56 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 14:54:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Kfm-0000vN-87; Wed, 31 Dec 2014 14:54:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Kfl-0000vI-4Q for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 14:54:53 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 4F/D4-25276-C3E04A45; Wed, 31 Dec 2014 14:54:52 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-15.tower-21.messagelabs.com!1420037691!18633617!1 X-Originating-IP: [131.111.8.151] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MSA9PiAxNDE4OTU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23510 invoked from network); 31 Dec 2014 14:54:51 -0000 Received: from ppsw-51.csi.cam.ac.uk (HELO ppsw-51.csi.cam.ac.uk) (131.111.8.151) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 14:54:51 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62680 helo=[192.168.0.6]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6Kfi-0004aC-YP (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 14:54:51 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <13DED803-7891-4D52-8384-346410BE3708@gazagnaire.org> Date: Wed, 31 Dec 2014 09:54:49 -0500 Message-Id: References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <5262B6D3-4B1A-400B-AE7A-7D30E401B444@cam.ac.uk> <35CB58BC-8F82-4124-BA9F-C8C219F323E6@gazagnaire.org> <13DED803-7891-4D52-8384-346410BE3708@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org SSB0cmllZCBhZGRpbmcgYm90aCB3aXRoL3dpdGhvdXQgdGhlIHZpZXcgd2l0aCB0aGUgc2FtZSBy ZXN1bHQuIEZpbGVuYW1lIHNpemUgaXMgc21hbGwgLSBhcm91bmQgMTAgYnl0ZXMuCldoYXQgZG8g eW91IHRoaW5rIGlzIHRoZSBiZXN0IGJhY2tlbmQgZm9ybWF0IHRvIHVzZSBmb3IgZW1haWxzPwoK PiBPbiBEZWMgMzEsIDIwMTQsIGF0IDY6MTMgQU0sIFRob21hcyBHYXphZ25haXJlIDx0aG9tYXNA Z2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+IAo+Pj4gSSBsb29rZWQgYXQgdGhlIG1ldGFkYXRhIHRo YXQgZ2V0cyBjcmVhdGVkIGZvciBldmVyeSBlbWFpbCBtZXNzYWdlIGFuZCBpdOKAmXMgc21hbGwg LSBsZXNzIHRoYW4gMTAwIGJ5dGVzLiBTbyBJIHJhbiBhIHNpbXBsZSB0ZXN0IG9mIGFwcGVuZGlu ZyAyMCwwMDAgdW5pcXVlIDEwMCBieXRlcyBhc2NpaSBtZXNzYWdlcy4gSSB3b3VsZCBoYXZlIGV4 cGVjdGVkIHRoZSByZXBvc2l0b3J5IHNpemUgdG8gYmUgb24gdGhlIG9yZGVyIG9mIGEgZmV3IG1l Z2FieXRlcywgaW5zdGVhZCBpdCB3YXMgNC43Ry4gVGhpcyBpcyByb3VnaGx5IDIzNEsgb3Zlcmhl YWQgcGVyIDEwMCBieXRlcyBtZXNzYWdlLCB3aGljaCB3b3VsZCBiZSBxdWl0ZSBpbXByYWN0aWNh bCBmb3IgdGhlIGVtYWlsIHN0b3JhZ2Ugd2l0aCB0aGUgbWV0YWRhdGEgZXNzZW50aWFsbHkgZXhj ZWVkaW5nIHRoZSBtZXNzYWdlIHN0b3JhZ2UuCj4+IAo+PiBEaWQgeW91IHN0YXJ0IGZyb20gYW4g ZW1wdHkgcmVwb3NpdG9yeT8gV291bGQgYmUgaW50ZXJlc3RlZCB0byBydW4geW91ciBjb2RlIGxv Y2FsbHkgdG8gY2hlY2sgd2hhdCBoYXBwZW5zLiAKPiAKPiBEaWQgeW91IGFkZCB0aGUgbWVzc2Fn ZSBzZXF1ZW50aWFsbHkgb3IgZGlkIHlvdSB1c2UgYSB2aWV3PyBJZiB5b3UgaGF2ZSAyMGsgY29t bWl0cyAod2hpY2ggYXJlIGF0IGxlYXN0IDRrKSwgYnV0IHlvdSBhbHNvIGhhdmUgMjBrIGRpZmZl cmVudCBkaXJlY3RvcmllcyAod2hpY2ggY29udGFpbiAxLCAyLCAzLCAuLi4gMjBrIGZpbGVzKS4g V2hhdCdzIHRoZSBzaXplIG9mIHlvdXIgZmlsZW5hbWVzLiBUaGV5IGFyZSBzZXJpYWxpemVkIGlu IHRoZSBkaXJlY3RvcnkgbWV0YWRhdGEsIHNvIGlmIHlvdSBoYXZlIDEwIGJ5dGUgZmlsZW5hbWVz LCB5b3Ugc2hvdWxkIGluZGVlZCBleHBlY3QgdGhlIGxhc3QgZGlyZWN0b3J5IG1ldGFkYXRhIHRv IGJlIGFyb3VuZCAyMGsqMTAgKG1heWJlIGEgYml0IGxlc3MgYXMgaXQgaXMgY29tcHJlc3NlZCku IEFueXdheSwgdGhlIEdpdCBmb3JtYXQgaXMgbm90IHZlcnkgZmxleGlibGUgKGFzIHdlIHdhbnQg dG8ga2VlcCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIEdpdCBmb3JtYXQpIGJ1dCB0aGF0IHVzZWZ1 bCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgbm90IG9wdGltYWwgdG8gaW1wcm92ZSBpdCBpbiB0aGUg Y3VzdG9tIGJhY2tlbmQuCj4gCj4gVGhvbWFzCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTWlyYWdlT1MtZGV2ZWwgbWFpbGluZyBsaXN0Ck1pcmFnZU9T LWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9j Z2ktYmluL21haWxtYW4vbGlzdGluZm8vbWlyYWdlb3MtZGV2ZWwK From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 14:56:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 14:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Khl-0000x6-Fo; Wed, 31 Dec 2014 14:56:57 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Khj-0000x1-Pi for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 14:56:55 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 3E/32-15461-7BE04A45; Wed, 31 Dec 2014 14:56:55 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-8.tower-21.messagelabs.com!1420037813!18661677!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27459 invoked from network); 31 Dec 2014 14:56:54 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 14:56:54 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62683 helo=[192.168.0.6]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6Khh-0000jB-qc (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 14:56:53 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <104D7956-17DF-410C-823E-EC3B87658A7A@gazagnaire.org> Date: Wed, 31 Dec 2014 09:56:51 -0500 Message-Id: References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <104D7956-17DF-410C-823E-EC3B87658A7A@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBhbmQgZm9yIHRoZSByZWZlcmVuY2VzIQoKR3Jl Z29yeQoKPiBPbiBEZWMgMzEsIDIwMTQsIGF0IDU6MjcgQU0sIFRob21hcyBHYXphZ25haXJlIDx0 aG9tYXNAZ2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+IAo+IEhpIEdyZWdvcnksCj4gCj4+IEnigJlt IHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQga2luZCBvZiBzdG9yYWdlIG92ZXJoZWFkIGFuZCBk ZWR1cCBJIGdldCBpbiBJcm1pbi4gRmlyc3QgSSB0cmllZCB0byBjb252ZXJ0IHRoZSBnb29nbGUg ZW1haWwgYXJjaGl2ZSAoMi40RykgdG8gdGhlIElNQVAgc2VydmVyIElybWluIGZvcm1hdCAuIEFm dGVyIGNvbnZlcnNpb24gdGhlIHNpemUgb2YgdGhlIGdpdCByZXBvc2l0b3J5IHdhcyB0d2ljZSB0 aGUgc2l6ZSBvZiB0aGUgb3JpZ2luYWwgYXJjaGl2ZS4gSSBkbyBoYXZlIHNvbWUgYWRkaXRpb25h bCBzdHJ1Y3R1cmVzIHRoYXQgSSBjcmVhdGUsIGxpa2UgcGVyIG1haWxib3ggaW5kZXggYW5kIHN1 bW1hcnkgc3RhdGlzdGljcyBhbmQgcGVyIGVtYWlsIG1lc3NhZ2UgZmxhZ3Mgc28gcGVyaGFwcyB0 aGUgZXh0cmEgc2l6ZSBpcyBjb21pbmcgZnJvbSB0aG9zZSBzdHJ1Y3R1cmVzIHRob3VnaCBpdCBz ZWVtcyBhIGJpdCBoaWdoLiBJIHdpbGwgaGF2ZSB0byBlc3RpbWF0ZSB0aGUgZXhwZWN0ZWQgc2l6 ZSBmcm9tIGFkZGl0aW9uYWwgc3RydWN0dXJlcyB0byB1bmRlcnN0YW5kIHRoaXMgcmVzdWx0LiBO ZXh0IEkgZHVtcGVkIGludG8gaXJtaW4gMiwwMDAgb2YgMU0gZmlsZXMgd2l0aCByYW5kb20gYXNj aWkgY29udGVudCB3aGljaCByZXN1bHRlZCBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgc2l6ZSBvZiA5 NTBNLiBJIGZpZ3VyZSBJcm1pbiBjb21wcmVzc2VzIHRoZSBjb250ZW50LCByaWdodD8gVG8gdmVy aWZ5IHRoaXMgSSBkdW1wZWQgMiwwMDAgb2YgMi40TSBpbWFnZSBmaWxlcyB3aXRoIGNvbmNhdGVu YXRlZCBjb3VudGVyIHRvIG1ha2UgdGhlIGNvbnRlbnQgdW5pcXVlLiBUaGUgc2l6ZSBvZiByZXBv c2l0b3J5IGZvciB0aGlzIHdhcyA0LjZHLCB3aGljaCBpcyBleHBlY3RlZC4gVGhlbiBJIHJlcGVh dGVkIHRoZSBsYXN0IHRlc3QgYnV0IHdpdGggaWRlbnRpY2FsIGltYWdlcyBhbmQgdGhpcyB0aW1l IHRoZSBzaXplIHdhcyAyN00sIHdoaWNoIHdhcyBjbGVhcmx5IGEgbmljZSBwcm9vZiBvZiB0aGUg ZGVkdXBpbmcgYnkgSXJtaW4uIE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGNvbXByZXNzaW9u IGluIElybWluIGlzIGNvbmZpZ3VyYWJsZT8gQ2FuIGl0IGJlIGNvbmZpZ3VyYWJsZSBwZXIgaW5k aXZpZHVhbCBjb250ZW50PyBGb3IgaW5zdGFuY2UsIEkgZG9u4oCZdCB3YW50IHRvIGNvbXByZXNz IGltYWdlcyBhcyB0aGVyZSBpcyBub3RoaW5nIHRvIGdhaW4gZnJvbSB0aGUgc3BhY2Ugc2F2aW5n IGFuZCBjb25zZXF1ZW50bHkgdGhlcmUgaXMgdW5uZWNlc3NhcnkgcmVzb3VyY2UgdXNhZ2UgYnV0 IEkgZG8gd2FudCB0byBjb21wcmVzcyB0aGUgdGV4dCBpZiB0aGUgY29tcHJlc3Npb24gb3Zlcmhl YWQgaXMgcmVhc29uYWJsZS4gSSBjYW4gZmlndXJlIG91dCB0aGUgdHlwZSBvZiBjb250ZW50IGZy b20gTUlNRSB0eXBlIGluIElNQVAgc2VydmVyLgo+IAo+IEluZGVlZCwgSXJtaW4gZGVkdXBsaWNh dGUgc2ltaWxhciBjb250ZW50cyBhdXRvbWF0aWNhbGx5IGFzIGl0IHVzZXMgdGhlIGRpZ2VzdCBv ZiBpbnRlcm5hbCBvYmplY3RzIGFzIGludGVybmFsIGtleXMgKHRoYXQncyBzaW1pbGFyIHRvIGNv bnRlbnQgYWRkcmVzc2FibGUgc3RvcmVzIG9yIGhhc2gtY29uc2luZykuCj4gCj4gRm9yIHRoZSBj b21wcmVzc2lvbiwgaXQgZGVwZW5kcyBvbiB0aGUgYmFja2VuZC4gSWYgeW91IHVzZSBgSXJtaW5f ZnNgIHlvdSB3aWxsIGhhdmUgbm9uZS4gSWYgeW91IHVzZSB0aGUgR2l0IGJhY2tlbmQsIHlvdSBo YXZlIHR3byBraW5kcyBvZiBjb21wcmVzc2lvbnM6Cj4gLSB0aGUgR2l0IHNlcmlhbGlzYXRpb24g Zm9ybWF0IGV4dGVuc2l2ZWx5IHVzZXMgdGhlIHpsaWIgbGlicmFyeS4gQmFzaWNhbGx5IGV2ZXJ5 IGNodW5rIG9mIGJ5dGVzIGlzIGNvbXByZXNzZWQsIGJlaW5nIHRoZSBibG9icyBvciB0aGUgdGhl IHRyZWUgYW5kIGNvbW1pdCBtZXRhZGF0YQo+IC0geW91IGNhbiBydW4gYGdpdCBnY2AgYXQgdGhl IHJvb3Qgb2YgeW91ciBHaXQgcmVwb3NpdG9yeSBhbmQgdGhlIEdpdCB0b29sIHdpbGwgdHJ5IHRv IGNvbXBhY3Qgc2ltaWxhciBjb250ZW50cyB0b2dldGhlciBpbiBgLnBhY2tgIGZpbGVzLiBUaGUg YWxnb3JpdGhtIHNvcnQgdGhlIGNvbnRlbnRzIGJ5IGZpbGVuYW1lLCB0aGVuIGJ5IHNpemUgYW5k IHRoZW4gdXNlIGEgc2xpZGluZy13aW5kb3cgdG8gZmluZCBzaW1pbGFyIGNvbnRlbnRzIGFuZCBj b21wdXRlIGEgZGlmZi1iYXNlZCByZXByZXNlbnRhdGlvbi4gU29tZSBraW5kIG9mIGBnaXQgZ2Ng IGlzIGFsc28gcnVuIGJlZm9yZSBkb2luZyBhIHB1c2gvcHVsbCwgYXMgdGhlIGAucGFja2AgZmls ZXMgYXJlIGV4YWN0bHkgd2hhdCBpcyBzZW50IG92ZXIgdGhlIG5ldHdvcmsuIFNlZSBbMV0gZm9y IGEgZ3JlYXQgZXhwbGFuYXRpb24gb2YgdGhlIEdpdCBmb3JtYXQuCj4gCj4gSXQgd291bGQgYmUg cG9zc2libGUgdG8gY29udHJvbCB0aGUgbGV2ZWwgb2YgY29tcHJlc3Npb24gYnkgZXhwbGljaXRs eSBwYXNzaW5nIGEgfmxldmVsIGFyZ3VtZW50IHRvIFpsaWIuY29tcHJlc3NbMl0gaW4gb2NhbWwt Z2l0WzNdIGJ1dCBpdCBpcyBub3QgZG9uZSBjdXJyZW50bHlbNF0uIEknbSBub3Qgc3VyZSBpdCBp cyBwb3NzaWJsZSB0byBkaXNhYmxlIHRoZSBjb21wcmVzc2lvbiBjb21wbGV0ZWx5IGFuZCBzdGls bCBiZSBjb21wYXRpYmxlIHdpdGggdGhlIEdpdCBmb3JtYXQgdGhvdWdoLiBJJ2xsIGFkZCB0aGlz IG9wdGlvbiBpbiB0aGUgbmV4dCByZWxlYXNlLgo+IAo+IEJlc3QsCj4gVGhvbWFzCj4gCj4gWzFd IGh0dHA6Ly9zdGVmYW4uc2Fhc2VuLm1lL2FydGljbGVzL2dpdC1jbG9uZS1pbi1oYXNrZWxsLWZy b20tdGhlLWJvdHRvbS11cC8KPiBbMl0gaHR0cDovL25pdC5nZm9yZ2UuaW5yaWEuZnIvY2FtbHpp cC9abGliLmh0bWwjVkFMQ29tcHJlc3MKPiBbM10gaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9v Y2FtbC1naXQvYmxvYi9tYXN0ZXIvbGliL21pc2MubWwjTDc1Cj4gWzRdIGh0dHBzOi8vZ2l0aHVi LmNvbS9taXJhZ2Uvb2NhbWwtZ2l0L2lzc3Vlcy80MQo+IAoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApN aXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVj dC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 14:56:57 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 14:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Khl-0000x6-Fo; Wed, 31 Dec 2014 14:56:57 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6Khj-0000x1-Pi for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 14:56:55 +0000 Received: from [85.158.143.35] by server-3.bemta-4.messagelabs.com id 3E/32-15461-7BE04A45; Wed, 31 Dec 2014 14:56:55 +0000 X-Env-Sender: gt303@cam.ac.uk X-Msg-Ref: server-8.tower-21.messagelabs.com!1420037813!18661677!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27459 invoked from network); 31 Dec 2014 14:56:54 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 14:56:54 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ool-44c2736f.dyn.optonline.net ([68.194.115.111]:62683 helo=[192.168.0.6]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:gt303) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Y6Khh-0000jB-qc (Exim 4.82_3-c0e5623) (return-path ); Wed, 31 Dec 2014 14:56:53 +0000 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Gregory Tsipenyuk In-Reply-To: <104D7956-17DF-410C-823E-EC3B87658A7A@gazagnaire.org> Date: Wed, 31 Dec 2014 09:56:51 -0500 Message-Id: References: <0D22934B-20C1-44C6-B750-761BF2E76838@cam.ac.uk> <104D7956-17DF-410C-823E-EC3B87658A7A@gazagnaire.org> To: Thomas Gazagnaire X-Mailer: Apple Mail (2.1993) Cc: mirageos-devel Subject: Re: [MirageOS-devel] irmin storage overhead and dedup X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBhbmQgZm9yIHRoZSByZWZlcmVuY2VzIQoKR3Jl Z29yeQoKPiBPbiBEZWMgMzEsIDIwMTQsIGF0IDU6MjcgQU0sIFRob21hcyBHYXphZ25haXJlIDx0 aG9tYXNAZ2F6YWduYWlyZS5vcmc+IHdyb3RlOgo+IAo+IEhpIEdyZWdvcnksCj4gCj4+IEnigJlt IHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQga2luZCBvZiBzdG9yYWdlIG92ZXJoZWFkIGFuZCBk ZWR1cCBJIGdldCBpbiBJcm1pbi4gRmlyc3QgSSB0cmllZCB0byBjb252ZXJ0IHRoZSBnb29nbGUg ZW1haWwgYXJjaGl2ZSAoMi40RykgdG8gdGhlIElNQVAgc2VydmVyIElybWluIGZvcm1hdCAuIEFm dGVyIGNvbnZlcnNpb24gdGhlIHNpemUgb2YgdGhlIGdpdCByZXBvc2l0b3J5IHdhcyB0d2ljZSB0 aGUgc2l6ZSBvZiB0aGUgb3JpZ2luYWwgYXJjaGl2ZS4gSSBkbyBoYXZlIHNvbWUgYWRkaXRpb25h bCBzdHJ1Y3R1cmVzIHRoYXQgSSBjcmVhdGUsIGxpa2UgcGVyIG1haWxib3ggaW5kZXggYW5kIHN1 bW1hcnkgc3RhdGlzdGljcyBhbmQgcGVyIGVtYWlsIG1lc3NhZ2UgZmxhZ3Mgc28gcGVyaGFwcyB0 aGUgZXh0cmEgc2l6ZSBpcyBjb21pbmcgZnJvbSB0aG9zZSBzdHJ1Y3R1cmVzIHRob3VnaCBpdCBz ZWVtcyBhIGJpdCBoaWdoLiBJIHdpbGwgaGF2ZSB0byBlc3RpbWF0ZSB0aGUgZXhwZWN0ZWQgc2l6 ZSBmcm9tIGFkZGl0aW9uYWwgc3RydWN0dXJlcyB0byB1bmRlcnN0YW5kIHRoaXMgcmVzdWx0LiBO ZXh0IEkgZHVtcGVkIGludG8gaXJtaW4gMiwwMDAgb2YgMU0gZmlsZXMgd2l0aCByYW5kb20gYXNj aWkgY29udGVudCB3aGljaCByZXN1bHRlZCBpbiB0aGUgZ2l0IHJlcG9zaXRvcnkgc2l6ZSBvZiA5 NTBNLiBJIGZpZ3VyZSBJcm1pbiBjb21wcmVzc2VzIHRoZSBjb250ZW50LCByaWdodD8gVG8gdmVy aWZ5IHRoaXMgSSBkdW1wZWQgMiwwMDAgb2YgMi40TSBpbWFnZSBmaWxlcyB3aXRoIGNvbmNhdGVu YXRlZCBjb3VudGVyIHRvIG1ha2UgdGhlIGNvbnRlbnQgdW5pcXVlLiBUaGUgc2l6ZSBvZiByZXBv c2l0b3J5IGZvciB0aGlzIHdhcyA0LjZHLCB3aGljaCBpcyBleHBlY3RlZC4gVGhlbiBJIHJlcGVh dGVkIHRoZSBsYXN0IHRlc3QgYnV0IHdpdGggaWRlbnRpY2FsIGltYWdlcyBhbmQgdGhpcyB0aW1l IHRoZSBzaXplIHdhcyAyN00sIHdoaWNoIHdhcyBjbGVhcmx5IGEgbmljZSBwcm9vZiBvZiB0aGUg ZGVkdXBpbmcgYnkgSXJtaW4uIE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGNvbXByZXNzaW9u IGluIElybWluIGlzIGNvbmZpZ3VyYWJsZT8gQ2FuIGl0IGJlIGNvbmZpZ3VyYWJsZSBwZXIgaW5k aXZpZHVhbCBjb250ZW50PyBGb3IgaW5zdGFuY2UsIEkgZG9u4oCZdCB3YW50IHRvIGNvbXByZXNz IGltYWdlcyBhcyB0aGVyZSBpcyBub3RoaW5nIHRvIGdhaW4gZnJvbSB0aGUgc3BhY2Ugc2F2aW5n IGFuZCBjb25zZXF1ZW50bHkgdGhlcmUgaXMgdW5uZWNlc3NhcnkgcmVzb3VyY2UgdXNhZ2UgYnV0 IEkgZG8gd2FudCB0byBjb21wcmVzcyB0aGUgdGV4dCBpZiB0aGUgY29tcHJlc3Npb24gb3Zlcmhl YWQgaXMgcmVhc29uYWJsZS4gSSBjYW4gZmlndXJlIG91dCB0aGUgdHlwZSBvZiBjb250ZW50IGZy b20gTUlNRSB0eXBlIGluIElNQVAgc2VydmVyLgo+IAo+IEluZGVlZCwgSXJtaW4gZGVkdXBsaWNh dGUgc2ltaWxhciBjb250ZW50cyBhdXRvbWF0aWNhbGx5IGFzIGl0IHVzZXMgdGhlIGRpZ2VzdCBv ZiBpbnRlcm5hbCBvYmplY3RzIGFzIGludGVybmFsIGtleXMgKHRoYXQncyBzaW1pbGFyIHRvIGNv bnRlbnQgYWRkcmVzc2FibGUgc3RvcmVzIG9yIGhhc2gtY29uc2luZykuCj4gCj4gRm9yIHRoZSBj b21wcmVzc2lvbiwgaXQgZGVwZW5kcyBvbiB0aGUgYmFja2VuZC4gSWYgeW91IHVzZSBgSXJtaW5f ZnNgIHlvdSB3aWxsIGhhdmUgbm9uZS4gSWYgeW91IHVzZSB0aGUgR2l0IGJhY2tlbmQsIHlvdSBo YXZlIHR3byBraW5kcyBvZiBjb21wcmVzc2lvbnM6Cj4gLSB0aGUgR2l0IHNlcmlhbGlzYXRpb24g Zm9ybWF0IGV4dGVuc2l2ZWx5IHVzZXMgdGhlIHpsaWIgbGlicmFyeS4gQmFzaWNhbGx5IGV2ZXJ5 IGNodW5rIG9mIGJ5dGVzIGlzIGNvbXByZXNzZWQsIGJlaW5nIHRoZSBibG9icyBvciB0aGUgdGhl IHRyZWUgYW5kIGNvbW1pdCBtZXRhZGF0YQo+IC0geW91IGNhbiBydW4gYGdpdCBnY2AgYXQgdGhl IHJvb3Qgb2YgeW91ciBHaXQgcmVwb3NpdG9yeSBhbmQgdGhlIEdpdCB0b29sIHdpbGwgdHJ5IHRv IGNvbXBhY3Qgc2ltaWxhciBjb250ZW50cyB0b2dldGhlciBpbiBgLnBhY2tgIGZpbGVzLiBUaGUg YWxnb3JpdGhtIHNvcnQgdGhlIGNvbnRlbnRzIGJ5IGZpbGVuYW1lLCB0aGVuIGJ5IHNpemUgYW5k IHRoZW4gdXNlIGEgc2xpZGluZy13aW5kb3cgdG8gZmluZCBzaW1pbGFyIGNvbnRlbnRzIGFuZCBj b21wdXRlIGEgZGlmZi1iYXNlZCByZXByZXNlbnRhdGlvbi4gU29tZSBraW5kIG9mIGBnaXQgZ2Ng IGlzIGFsc28gcnVuIGJlZm9yZSBkb2luZyBhIHB1c2gvcHVsbCwgYXMgdGhlIGAucGFja2AgZmls ZXMgYXJlIGV4YWN0bHkgd2hhdCBpcyBzZW50IG92ZXIgdGhlIG5ldHdvcmsuIFNlZSBbMV0gZm9y IGEgZ3JlYXQgZXhwbGFuYXRpb24gb2YgdGhlIEdpdCBmb3JtYXQuCj4gCj4gSXQgd291bGQgYmUg cG9zc2libGUgdG8gY29udHJvbCB0aGUgbGV2ZWwgb2YgY29tcHJlc3Npb24gYnkgZXhwbGljaXRs eSBwYXNzaW5nIGEgfmxldmVsIGFyZ3VtZW50IHRvIFpsaWIuY29tcHJlc3NbMl0gaW4gb2NhbWwt Z2l0WzNdIGJ1dCBpdCBpcyBub3QgZG9uZSBjdXJyZW50bHlbNF0uIEknbSBub3Qgc3VyZSBpdCBp cyBwb3NzaWJsZSB0byBkaXNhYmxlIHRoZSBjb21wcmVzc2lvbiBjb21wbGV0ZWx5IGFuZCBzdGls bCBiZSBjb21wYXRpYmxlIHdpdGggdGhlIEdpdCBmb3JtYXQgdGhvdWdoLiBJJ2xsIGFkZCB0aGlz IG9wdGlvbiBpbiB0aGUgbmV4dCByZWxlYXNlLgo+IAo+IEJlc3QsCj4gVGhvbWFzCj4gCj4gWzFd IGh0dHA6Ly9zdGVmYW4uc2Fhc2VuLm1lL2FydGljbGVzL2dpdC1jbG9uZS1pbi1oYXNrZWxsLWZy b20tdGhlLWJvdHRvbS11cC8KPiBbMl0gaHR0cDovL25pdC5nZm9yZ2UuaW5yaWEuZnIvY2FtbHpp cC9abGliLmh0bWwjVkFMQ29tcHJlc3MKPiBbM10gaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9v Y2FtbC1naXQvYmxvYi9tYXN0ZXIvbGliL21pc2MubWwjTDc1Cj4gWzRdIGh0dHBzOi8vZ2l0aHVi LmNvbS9taXJhZ2Uvb2NhbWwtZ2l0L2lzc3Vlcy80MQo+IAoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCk1pcmFnZU9TLWRldmVsIG1haWxpbmcgbGlzdApN aXJhZ2VPUy1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVj dC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL21pcmFnZW9zLWRldmVsCg== From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 20:08:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 20:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6PZZ-0006Ko-So; Wed, 31 Dec 2014 20:08:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6PZY-0006Kj-Ej for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 20:08:48 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 92/3A-09842-FC754A45; Wed, 31 Dec 2014 20:08:47 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1420056527!18661215!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21659 invoked from network); 31 Dec 2014 20:08:47 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 20:08:47 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id fe7ef8de; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 31 Dec 2014 20:15:29 +0000 (GMT) From: Anil Madhavapeddy Date: Wed, 31 Dec 2014 20:08:45 +0000 Message-Id: To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Cc: Lars Kurth , Russell Pavlicek Subject: [MirageOS-devel] Mirage 2014 in review: IPv6, TLS, Irmin, Jitsu, etc X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Dear Miragists, I've put together a review of the year over on the website: http://openmirage.org/blog/2014-in-review A lot's happened this year, and I'm most excited (yes, more than usual) about what's about to come in 2015. But for now, a very happy new year wherever you happen to be in the world! -anil PS: The post was written in a bit of a rush, so if I've missed out something interesting please let me know and I'll edit it in. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel From mirageos-devel-bounces@lists.xenproject.org Wed Dec 31 20:08:55 2014 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 31 Dec 2014 20:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6PZZ-0006Ko-So; Wed, 31 Dec 2014 20:08:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y6PZY-0006Kj-Ej for mirageos-devel@lists.xenproject.org; Wed, 31 Dec 2014 20:08:48 +0000 Received: from [85.158.143.35] by server-1.bemta-4.messagelabs.com id 92/3A-09842-FC754A45; Wed, 31 Dec 2014 20:08:47 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1420056527!18661215!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21659 invoked from network); 31 Dec 2014 20:08:47 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2014 20:08:47 -0000 Received: from [192.168.1.69] (cpc7-cmbg14-2-0-cust238.5-4.cable.virginm.net [86.30.244.239]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id fe7ef8de; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Wed, 31 Dec 2014 20:15:29 +0000 (GMT) From: Anil Madhavapeddy Date: Wed, 31 Dec 2014 20:08:45 +0000 Message-Id: To: mirageos-devel Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Cc: Lars Kurth , Russell Pavlicek Subject: [MirageOS-devel] Mirage 2014 in review: IPv6, TLS, Irmin, Jitsu, etc X-BeenThere: mirageos-devel@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mirageos-devel-bounces@lists.xenproject.org Errors-To: mirageos-devel-bounces@lists.xenproject.org Dear Miragists, I've put together a review of the year over on the website: http://openmirage.org/blog/2014-in-review A lot's happened this year, and I'm most excited (yes, more than usual) about what's about to come in 2015. But for now, a very happy new year wherever you happen to be in the world! -anil PS: The post was written in a bit of a rush, so if I've missed out something interesting please let me know and I'll edit it in. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel