From mirageos-devel-bounces@lists.xenproject.org Thu Dec 14 22:42:18 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 Dec 2023 22:42:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.654796.1022182 (Exim 4.92) (envelope-from ) id 1rDuP5-0005N1-4h; Thu, 14 Dec 2023 22:42:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 654796.1022182; Thu, 14 Dec 2023 22:42:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rDuP5-0005Mu-1q; Thu, 14 Dec 2023 22:42:03 +0000 Received: by outflank-mailman (input) for mailman id 654796; Thu, 14 Dec 2023 22:42:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rDuP4-0005Mk-93 for mirageos-devel@lists.xenproject.org; Thu, 14 Dec 2023 22:42:02 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd9762a7-9ad1-11ee-98e9-6d05b1d4d9a1; Thu, 14 Dec 2023 23:41:59 +0100 (CET) Received: from [192.168.42.12] (i59F52677.versanet.de [89.245.38.119]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id E7D4E1E799 for ; Thu, 14 Dec 2023 23:41:57 +0100 (CET) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: fd9762a7-9ad1-11ee-98e9-6d05b1d4d9a1 Message-ID: Date: Thu, 14 Dec 2023 23:41:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 To: mirageos-devel Content-Language: en-US From: Hannes Mehnert Subject: MirageOS and my recent involvement Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, it is pretty quite on this list. I'm not sure whether this is a good sign or not. I unfortunately had to cancel the retreat in November due to lack of signups (3 people managed to sign up within the deadline) :/ While late signups are possible, it is always a burden. But I have some exciting MirageOS related news that I find worth sharing, and hope to engage discussions by doing so. Maybe it is also worth to restart weekly / biweekly MirageOS meetings (as in the old days) -- what do you think? Some repositories in the mirage organization are suffering from bitrot, and/or lack of cleanups or reviews (such as the ocaml-solo5 PR waiting since a long time for proper reviews that would enable to use OCaml 5) -- my personal experience with OCaml 5 from a resource perspective is not very good, that's why I don't really care about that too much (and am happy that 4.14 is under long-term support). ## MirageVPN / OpenVPN We at robur managed to receive EU (NGI Assure) funding to work on MirageVPN (an OpenVPN implementation), which we started back in 2019 - to add more mdoern crypto and more recent features (tls-crypt, ..), a server implementation, a QubesOS client unikernel, ... -- https://nlnet.nl/project/MirageVPN/ \o/ The source is developed at https://github.com/robur-coop/miragevpn (also see our blog entries at https://blog.robur.coop) In case you are using OpenVPN and are looking for a replacement, please have a try (and/or open issues if you're stuck / missing features). ## DNSvizor / DNSmasq We at robur also managed to receive EU (NGI0 Entrust) funding to work on DNSvizor (a DNS resolver and DHCP server - basically a DNSmasq replacement) https://nlnet.nl/project/DNSvizor/ (earlier funding for this project didn't pan out due to how to direct the money -- https://nlnet.nl/project/Robur/) -- but we already have a basic repository up and running https://github.com/robur-coop/dnsvizor At the earlier retreats previous versions of such a unikernel were actively being used - and we also discovered some issues that were then fixed on site. But now, finally putting several months of effort into it (in 2024) will hopefully result in a useful unikernel. Again, if you wish for some features, or have a DNSmasq in production that you're keen on having replaced, don't hesitate to open an issue (and provide us with your configuration). ## uTCP Since August I've motivated myself to work a bit more on uTCP, a TCP/IP stack that originated from Netsem, a formal model in HOL4. Apart from minor bugfixes to get it compiling again, I pushed it into production (first for retreat.mirage.io, then once the resource leakage was sorted, also on a.ns.robur.coop, and now finally as tls reverse proxy on *.robur.coop). Some highlights from the last months: making it usable: - properly set initial window - segment reassembly performance: - improve performance of checksum computation by a factor of 5 - avoid lots of allocations (improved performance by factor of 3) correctness - drop connection in LAST ACK if FIN was received - fix exceptions (Cstruct.shift exceeding send queue, Cstruct.shiftv with negative amount) - no longer being stuck in various states (CLOSE WAIT, FIN WAIT 2) [which turned out to be an issue in the model] - avoid usage of multiple maps convenience: - add metrics and monitoring - since mirage 4.4.1, using uTCP is possible without too much headache (still some, see https://github.com/mirage/retreat.mirage.io/blob/748f29e20499a8b508b11a302e8890202202e854/config.ml#L36-L69 for an example) It is now in a nice shape - while working on it, I also discovered that mirage-tcpip has some issues (apart from resource leaks, it also doesn't validate any checksum). There are still some open issues to work on before releasing an initial version (such as path MTU discovery, selective acknowledgement, congestion control, increase initial window size, accurate byte counting). But the upside is that even the reverse TLS tunnel that carries quite some load doesn't seem to leak memory anymore. repository: https://github.com/robur-coop/utcp blog article:https://hannes.robur.coop/Posts/TCP-ns network semantics: https://www.cl.cam.ac.uk/~pes20/Netsem/ JACM journal paper (2019): http://www.cl.cam.ac.uk/~pes20/Netsem/paper3.pdf ## NetHSM The first (to my knowledge) commercial product using MirageOS (and Muen) is now for sale; it is a "Hardware Security Module", so something you can store your private keys which hopefully never get extracted. With the robur team (namely Steffi and Martin) I was involved in the early days (doing system design and implementation) [though I've not followed changes in later years]. See their announcement at https://www.nitrokey.com/news/2023/after-8-years-development-nethsm-10-available-first-open-source-hardware-security-module NB: I don't agree with everything they say. I'm especially sad how they did a code dump on GitHub instead of preserving the commit history. Best, Hannes From mirageos-devel-bounces@lists.xenproject.org Fri Dec 15 18:19:08 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 Dec 2023 18:19:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.655314.1023033 (Exim 4.92) (envelope-from ) id 1rECm1-0005v7-TV; Fri, 15 Dec 2023 18:18:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 655314.1023033; Fri, 15 Dec 2023 18:18:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rECm1-0005v0-QX; Fri, 15 Dec 2023 18:18:57 +0000 Received: by outflank-mailman (input) for mailman id 655314; Fri, 15 Dec 2023 18:18:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rECm0-0005un-Dc for mirageos-devel@lists.xenproject.org; Fri, 15 Dec 2023 18:18:56 +0000 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 670b08b1-9b76-11ee-98ea-6d05b1d4d9a1; Fri, 15 Dec 2023 19:18:54 +0100 (CET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 7DBF4240002 for ; Fri, 15 Dec 2023 18:18:52 +0000 (UTC) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: 670b08b1-9b76-11ee-98ea-6d05b1d4d9a1 From: Thomas Gazagnaire Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Updates on Tarides Plans with MirageOS - Request for Feedback Message-Id: Date: Fri, 15 Dec 2023 19:18:42 +0100 To: mirageos-devel@lists.xenproject.org X-Mailer: Apple Mail (2.3774.200.91.1.1) X-GND-Sasl: thomas@gazagnaire.org Hello there, Over the last year, Tarides has been engaging with partners in the space = sector to adapt MirageOS for use in space environments. Following = participation in Cyber@StationF and initial discussions with Thales = Alenia Space in late 2022, we have begun the development of SpaceOS. = This operating system, leveraging numerous MirageOS components, is = designed to meet the new requirements of multi-mission, multi-user = satellite missions (what people also call "NewSpace"). SpaceOS's development has led to Tarides joining a consortium of = academic and commercial entities in the space industry. We have = successfully obtained our first grant (with the [ORCHIDE project, part = of the EU HORIZON CL4-2023-SPACE-01-11 = programme,](https://ec.europa.eu/info/funding-tenders/opportunities/portal= /screen/how-to-participate/org-details/999999999/project/101135595/program= /43108390/details)) and have several others under review. The goal for = SpaceOS is to remain as open-source as possible, aligning with the = MirageOS community's approach to software development (with a few = exceptions in scenarios involving proprietary hardware or software = vendors). Hence, Tarides is planning active development work on MirageOS in the = coming years in conjunction with the early development stages of = SpaceOS. We have ambitious plans in mind and are reaching out to the = MirageOS community to gather input and perspectives during this phase. = We welcome your thoughts on this matter, whether these are agreements, = disagreements, or general comments. Please share your feedback on this = mailing list (preferred) or through private communication. ### Tooling Over the past five years, our efforts have focused on integrating = Mirage-specific tooling into the OCaml Platform. We plan to continue in = this direction. This integration is intended to benefit both Mirage = developers (by reducing the maintenance burden on the core MirageOS = team) and the broader OCaml user base (as they could benefit from = MirageOS workflow -- especially cross-compilation -- in other = situations). A significant part of this effort was transitioning from custom = x-compilation runes to using Dune workspace via `opam -monorepo`. This = migration was not always painless (to say the least), but we learned a = few things that are now being applied to the new "package management" = feature of Dune 4. Thus, we plan to continue to work on migrating from = `opam-monorepo` to the `dune pkg` command to ensure it works for = MirageOS users. This new command addresses the limitations identified in = opam-monorepo, especially for packages not built with Dune. An alpha = version is currently available (try `dune pkg` with Dune 3.12), and we = anticipate a complete release in Q1 2024. We really want to ensure this = is a drop-in replacement for Mirage's use of `opam-monorepo`, so we will = work with upstream to ensure that is the case (and so we can deprecate = opam-monorepo in Q2 2024). Regarding mirage/functoria, my general feeling is that while the CLI = tool was initially valuable for gathering an ecosystem of libraries, = nowadays, it is less clear if this is still required. Right now, most of = the tool's complexity is handling the installation of packages needed = for a specific target/combination of devices. This will no longer be = needed if the build system can do this instead. Ideally, any OCaml = application (following a few design principles) could be compiled to a = unikernel simply using Dune, as envisioned by the [Workflow = W12](https://ocaml.org/docs/platform-roadmap#w12-compile-to-mirageos) of = the OCaml Roadmap. However, there is no existing design on how this = should work at this stage. So, before starting this, is that the right = direction for the mirage tool? ### Targets The principal target backend for MirageOS nowadays is Solo5. This is a = solid backend, which has been audited and optimised for security. It is = also relatively simple to add new devices given the by-design = low-complexity approach of its device model. However, while solo5 is = today the most secure unikernel "runtime", I also feel it has issues = hindering potential changes. For one, it is slow -- the device model is = not meant for high-speed I/O, and there is no support for SMP; for most = use cases, it is not an issue, but for others we are looking at, it can = be. The other one is that the device model is very simple (for good = reasons) and challenging to extend to new devices (see below for more = detail). In an ideal world, this could be fixable, but there are also = very few courageous active maintainers, so any changes - like moving to = OCaml5 - are complex to make. Thus, we are evaluating alternate backends with the main criteria to = reduce the maintenance cost. Despite its currently limited security = features, one interesting possibility is shifting towards alternative = backends like unikraft. Christiano spent a bit of time looking at this = earlier this year (with a prototype of the OCaml 5 runtime x-compiler to = Unikraft [here](https://github.com/haesbaert/unikraft-ocaml) and a = roadmap for Unikraft security = [here](https://github.com/orgs/unikraft/projects/32/views/1)). Same as = above, we are interested to hear what people think and if anyone is = interested in collaborating with us in porting MirageOS to unikraft (and = contributing to Unikfraft' security roadmap). ### Devices and Libraries There are three areas that we would like to focus on (or continue to = focus on) in the next couple of years. First, we still believe there are better abstractions for storing data = than POSIX. Hence, we are continuing to develop and improve Irmin. We = are currently porting `irmin-pack` to MirageOS (the backend of Irmin = used by the Tezos blockchain to store its ledger history) via the = [Notafs](https://github.com/tarides/notafs) project. Notafs is a pseudo = filesystem for Mirage block devices. It can handle a small number of = large files. While the limited number of filenames is unsatisfying for = general usage, it can be used to run the irmin-pack backend of Irmin, = which only requires a dozen huge files. By running Irmin, one gets for = free a filesystem-on-steroid for MirageOS: it supports an arbitrarily = large number of filenames; is optimised for small and large file = contents; performs file deduplication; includes a git-like history with = branching and merging, ... and it even provides a garbage collector to = avoid running out of disk space (by deleting older commits). Since the = Irmin filesystem is versioned by Merkle hashes, one can imagine = deploying reproducible unikernels on reproducible filesystem states! We are also interested in developing new network protocols for space = applications, which could benefit from MirageOS's capabilities. We are = likely targeting the [Space Communication = Protocol](https://en.wikipedia.org/wiki/Space_Communications_Protocol_Spec= ifications), which seems an interesting domain as there does not seem to = exist any open-source, robust implementation of these protocols.=20 Finally, the API for devices supported by MirageOS currently maps to = what is available on virtualised infrastructure (i.e. virtual block = devices and virtual network interface). We are interested in = investigating how to extend this, for instance, by reviving the = PCI-passthrough experimentations done a few years ago by Florian, or by = investigating new multi-tenancy device frameworks like = [vAccel](https://vaccel.org/) to (securely?) share GPGPUs or FPGAs = between users. Alternatively, we could use Owl using CPU. We also = welcome anyone with any experience in this area to discuss existing = alternatives. ### OS Distribution Finally, we are considering options for building a flexible OS = distribution, which might include elements like = [LinuxKit/MirageSDK](https://github.com/linuxkit/linuxkit/tree/master/proj= ects/miragesdk). This concept combines a secure Linux kernel with a = collection of Mirage-based system services and an extended version of = Albatross for orchestration, all customisable based on specific needs. = We are in the early stages of this discussion and welcome any input or = expressions of interest in furthering these ideas. Best, Thomas From mirageos-devel-bounces@lists.xenproject.org Sun Dec 17 10:33:59 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 17 Dec 2023 10:33:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.655560.1023293 (Exim 4.92) (envelope-from ) id 1rEoSz-0006Ae-64; Sun, 17 Dec 2023 10:33:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 655560.1023293; Sun, 17 Dec 2023 10:33:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rEoSz-0006AX-2i; Sun, 17 Dec 2023 10:33:49 +0000 Received: by outflank-mailman (input) for mailman id 655560; Sun, 17 Dec 2023 10:33:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rEoSx-0006AR-9D for mirageos-devel@lists.xenproject.org; Sun, 17 Dec 2023 10:33:47 +0000 Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c06b695e-9cc7-11ee-9b0f-b553b5be7939; Sun, 17 Dec 2023 11:33:44 +0100 (CET) Received: by mail.gandi.net (Postfix) with ESMTPSA id F0E3020002 for ; Sun, 17 Dec 2023 10:33:42 +0000 (UTC) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: c06b695e-9cc7-11ee-9b0f-b553b5be7939 From: Thomas Gazagnaire Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: MirageOS and my recent involvement Date: Sun, 17 Dec 2023 11:33:32 +0100 References: To: mirageos-devel In-Reply-To: Message-Id: <384B75D1-6B7C-4946-81D9-BE5E0D87A3E2@gazagnaire.org> X-Mailer: Apple Mail (2.3774.200.91.1.1) X-GND-Sasl: thomas@gazagnaire.org Dear Hannes, > I have some exciting MirageOS related news that I find worth sharing, = and hope to engage discussions by doing so. Maybe it is also worth to = restart weekly / biweekly MirageOS meetings (as in the old days) -- what = do you think? I think that=E2=80=99s a great idea to restart bi-weekly MirageOS = meetings. There are many projects that are going on, it would be great = to sync more regularly. Should we start early January? > Some repositories in the mirage organization are suffering from = bitrot, and/or lack of cleanups or reviews (such as the ocaml-solo5 PR = waiting since a long time for proper reviews that would enable to use = OCaml 5) -- my personal experience with OCaml 5 from a resource = perspective is not very good, that's why I don't really care about that = too much (and am happy that 4.14 is under long-term support). Do you have some reproducible case for the OCaml5 resource usage? 5.1.1 = is shipping with a few improvements and it would be great to see if that = fixes what you have observed. > ## uTCP >=20 > Since August I've motivated myself to work a bit more on uTCP, a = TCP/IP stack that originated from Netsem, a formal model in HOL4. >=20 > [=E2=80=A6] As we already have discussed offline, I=E2=80=99m quite excited by = seeing progress on that new implementation as having a robust, verified = and extendable TCP stack is super important. I=E2=80=99m also curious to = compare the performance with the previous stack. > ## NetHSM >=20 > The first (to my knowledge) commercial product using MirageOS (and = Muen) is now for sale; it is a "Hardware Security Module", so something = you can store your private keys which hopefully never get extracted. = With the robur team (namely Steffi and Martin) I was involved in the = early days (doing system design and implementation) [though I've not = followed changes in later years]. See their announcement at = https://www.nitrokey.com/news/2023/after-8-years-development-nethsm-10-ava= ilable-first-open-source-hardware-security-module That=E2=80=99s indeed probably the first commercial projects to use = Solo5. However, that=E2=80=99s not the only one using the library part = of the "library operating systems" approach. For instance, the network = stack (mirage-tcpip (UDP/TCP), charrrua (NTP/DNS), cohttp) is used = widely (dozen of millions of users) to translate all the container raw = traffic into host syscalls in Docker for Desktop since 2016 :-) As you = pointed out in your blog, the stack mostly handle well-formed traffic = (that has been generated by the Linux kernel) but it=E2=80=99s pretty = solid and flexible. Happy to see if we can swap it with uTCP when this = is ready. Best, Thomas= From mirageos-devel-bounces@lists.xenproject.org Mon Dec 18 15:19:20 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 18 Dec 2023 15:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.656129.1024134 (Exim 4.92) (envelope-from ) id 1rFFOf-0002NT-97; Mon, 18 Dec 2023 15:19:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 656129.1024134; Mon, 18 Dec 2023 15:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFFOf-0002NM-5a; Mon, 18 Dec 2023 15:19:09 +0000 Received: by outflank-mailman (input) for mailman id 656129; Mon, 18 Dec 2023 15:19:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFFOd-0002Jg-Qs for mirageos-devel@lists.xenproject.org; Mon, 18 Dec 2023 15:19:08 +0000 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [2607:f8b0:4864:20::102a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c79e0d38-9db8-11ee-98eb-6d05b1d4d9a1; Mon, 18 Dec 2023 16:19:06 +0100 (CET) Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-28b0c586c51so1334364a91.2 for ; Mon, 18 Dec 2023 07:19:05 -0800 (PST) Received: from [192.168.0.10] (27-140-183-241.rev.home.ne.jp. [27.140.183.241]) by smtp.gmail.com with ESMTPSA id s9-20020a17090a1c0900b00286f2b39a95sm7612161pjs.31.2023.12.18.07.19.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Dec 2023 07:19:03 -0800 (PST) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: c79e0d38-9db8-11ee-98eb-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702912744; x=1703517544; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aJ3IR6ydqJIM+Waa3eN/1e8SGd9sobHxuMWkaGIiLSU=; b=RH4D1Xg9IaJiKpoZiO8SwrRd0Vz3ql60if+WqoFy5FGc/bsextqeSajZgk/6BC415e lSpoN3RHg4YsuHr4mcMpZyVChvqgVn45uyxAs4dr35FEo/sMsJqiz7TxOZptuxjDAUcq G8GknW+DiLD27HooWC8NXlQHiyKYrbGNpCyhoX36bJK2BR7nlvn4rkOGHDherZ8ojxmw 43bN0lXWK5avucxs0gC2kggKllSotZvtKQovTrON1pmHGNOLdprzf+hcXAVBd4pVDp8Y BqNo3+zriIfI6w2RN28kWcifWki3WRzhQvCF6oTSLMZGJesC3e5SGVCUuYC7mpPw7FnK qDog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702912744; x=1703517544; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aJ3IR6ydqJIM+Waa3eN/1e8SGd9sobHxuMWkaGIiLSU=; b=IaTPhl6BxOd7WMiedzxiygd+nxZWBs6T2mD7RR9h+OgT0I/zWXUMjh+bUhinznNI+/ hSXTZ5psJZfp6r+oVeJPy2zmqP7NRUD9KrBSpZq2L+Z40RJ+qMVy6QqHjxO6HWigA/zR +1TXD6GVEM/UsLaZsY8SIo+CN2MdgN5vf0z9Q2Sb7lHbeo8+DlhKahpX1kYv46UM/gqh O4dJhh2m9FLwGnh46jia0E75prGvieWPxfMNY4E9WwS5xWYWEdcEHkILgGcGOTjwor+M 1+UcODOVA12AMNxfH72VEy5xiGbvswMoQ3TMlnnIUqTDdHpcKQ8ODJnOgrDxb57Gqpue A0Cg== X-Gm-Message-State: AOJu0YzA7Kt22m1r0IuK1v9iK6BdxLpVW2UOYz6k42TyYxR2nquEdAex Cgkfa8BYD7Co8SEbPuPeyYz9oBD+7M0= X-Google-Smtp-Source: AGHT+IHc6mAw/Pa6Eh9iZEVITyBNazH4SV0BIEXGWJDcyEtzyqy8UNosy243hZGTnj4uZ1+U/pUnWA== X-Received: by 2002:a17:90a:7787:b0:286:58c4:6e49 with SMTP id v7-20020a17090a778700b0028658c46e49mr7376980pjk.42.1702912743601; Mon, 18 Dec 2023 07:19:03 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2023 00:19:00 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Updates on Tarides Plans with MirageOS - Request for Feedback Content-Language: en-US To: mirageos-devel@lists.xenproject.org References: From: Takayuki Imada In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBUaG9tYXMsDQoNClRoYW5rcyBmb3Igc2hhcmluZyBtYW55IHVwZGF0ZXMhDQoNCkkn bSBpbnRlcmVzdGVkIGluIHNvbWUgdG9waWNzIGJlbG93LCBhbmQgaGFwcHkgdG8gYmUgZW5n YWdlZCBpbiBvbmUgb3IgdHdvIG9mIHRoZW0gdGhvdWdoIEkgYW0gYSB3ZWVrZW5kIGhvYmJ5 aXN0LiA6LSkNCg0KICAgMS4gU29sbzUgaW1wcm92ZW1lbnQNCiAgIDIuIFVuaWtyYWZ0IGJh Y2stZW5kDQogICAtPiBJIGxpa2UgdGhlIFNvbG81IHBoaWxvc29waHkgKHNpbXBsZSwgc21h bGwsIGFuZCBzZWN1cmVkKS4gSG93ZXZlciAuLi4gdGhlIGN1cnJlbnQgU29sbzUgaW1wbGVt ZW50YXRpb24gaGFzIHNvbWUgcHJvYmxlbXMgYXMgeW91IG1lbnRpb25lZC4NCiAgICAgIFNv LCBoYXZpbmcgYW4gYWx0ZXJuYXRpdmUgYmFjay1lbmQgc2VlbXMgYSBnb29kIHdheS4NCiAg IDMuIE1pcmFnZU9TIGRldmljZSBBUElzIChtYWlubHkgdGFyZ2V0aW5nIFBDSWUgZGV2aWNl cz8pDQogICAtPiBJIGhhdmUgcHJldmlvdXNseSB0cmllZCAiTWlyYWdlT1MgKyBTb2xvNSBo dnQgKyBOZXRtYXAgKyAxMEdiRSB3aXRoIFNSLUlPViIuIE15IGV4cGVyaWVuY2Ugb24gdGhh dCB3aWxsIGJlIGhlbHBmdWwgdG8gdGhpcyB0b3BpYyENCg0KS2luZCByZWdhcmRzLA0KDQot LSANClRha2F5dWtpIEltYWRhDQoNCg0KT24gMjAyMy8xMi8xNiAzOjE4LCBUaG9tYXMgR2F6 YWduYWlyZSB3cm90ZToNCj4gSGVsbG8gdGhlcmUsDQo+IA0KPiBPdmVyIHRoZSBsYXN0IHll YXIsIFRhcmlkZXMgaGFzIGJlZW4gZW5nYWdpbmcgd2l0aCBwYXJ0bmVycyBpbiB0aGUgc3Bh Y2Ugc2VjdG9yIHRvIGFkYXB0IE1pcmFnZU9TIGZvciB1c2UgaW4gc3BhY2UgZW52aXJvbm1l bnRzLiBGb2xsb3dpbmcgcGFydGljaXBhdGlvbiBpbiBDeWJlckBTdGF0aW9uRiBhbmQgaW5p dGlhbCBkaXNjdXNzaW9ucyB3aXRoIFRoYWxlcyBBbGVuaWEgU3BhY2UgaW4gbGF0ZSAyMDIy LCB3ZSBoYXZlIGJlZ3VuIHRoZSBkZXZlbG9wbWVudCBvZiBTcGFjZU9TLiBUaGlzIG9wZXJh dGluZyBzeXN0ZW0sIGxldmVyYWdpbmcgbnVtZXJvdXMgTWlyYWdlT1MgY29tcG9uZW50cywg aXMgZGVzaWduZWQgdG8gbWVldCB0aGUgbmV3IHJlcXVpcmVtZW50cyBvZiBtdWx0aS1taXNz aW9uLCBtdWx0aS11c2VyIHNhdGVsbGl0ZSBtaXNzaW9ucyAod2hhdCBwZW9wbGUgYWxzbyBj YWxsICJOZXdTcGFjZSIpLg0KPiANCj4gU3BhY2VPUydzIGRldmVsb3BtZW50IGhhcyBsZWQg dG8gVGFyaWRlcyBqb2luaW5nIGEgY29uc29ydGl1bSBvZiBhY2FkZW1pYyBhbmQgY29tbWVy Y2lhbCBlbnRpdGllcyBpbiB0aGUgc3BhY2UgaW5kdXN0cnkuIFdlIGhhdmUgc3VjY2Vzc2Z1 bGx5IG9idGFpbmVkIG91ciBmaXJzdCBncmFudCAod2l0aCB0aGUgW09SQ0hJREUgcHJvamVj dCwgcGFydCBvZiB0aGUgRVUgSE9SSVpPTiBDTDQtMjAyMy1TUEFDRS0wMS0xMSBwcm9ncmFt bWUsXShodHRwczovL2VjLmV1cm9wYS5ldS9pbmZvL2Z1bmRpbmctdGVuZGVycy9vcHBvcnR1 bml0aWVzL3BvcnRhbC9zY3JlZW4vaG93LXRvLXBhcnRpY2lwYXRlL29yZy1kZXRhaWxzLzk5 OTk5OTk5OS9wcm9qZWN0LzEwMTEzNTU5NS9wcm9ncmFtLzQzMTA4MzkwL2RldGFpbHMpKSBh bmQgaGF2ZSBzZXZlcmFsIG90aGVycyB1bmRlciByZXZpZXcuIFRoZSBnb2FsIGZvciBTcGFj ZU9TIGlzIHRvIHJlbWFpbiBhcyBvcGVuLXNvdXJjZSBhcyBwb3NzaWJsZSwgYWxpZ25pbmcg d2l0aCB0aGUgTWlyYWdlT1MgY29tbXVuaXR5J3MgYXBwcm9hY2ggdG8gc29mdHdhcmUgZGV2 ZWxvcG1lbnQgKHdpdGggYSBmZXcgZXhjZXB0aW9ucyBpbiBzY2VuYXJpb3MgaW52b2x2aW5n IHByb3ByaWV0YXJ5IGhhcmR3YXJlIG9yIHNvZnR3YXJlIHZlbmRvcnMpLg0KPiANCj4gSGVu Y2UsIFRhcmlkZXMgaXMgcGxhbm5pbmcgYWN0aXZlIGRldmVsb3BtZW50IHdvcmsgb24gTWly YWdlT1MgaW4gdGhlIGNvbWluZyB5ZWFycyBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBlYXJs eSBkZXZlbG9wbWVudCBzdGFnZXMgb2YgU3BhY2VPUy4gV2UgaGF2ZSBhbWJpdGlvdXMgcGxh bnMgaW4gbWluZCBhbmQgYXJlIHJlYWNoaW5nIG91dCB0byB0aGUgTWlyYWdlT1MgY29tbXVu aXR5IHRvIGdhdGhlciBpbnB1dCBhbmQgcGVyc3BlY3RpdmVzIGR1cmluZyB0aGlzIHBoYXNl LiBXZSB3ZWxjb21lIHlvdXIgdGhvdWdodHMgb24gdGhpcyBtYXR0ZXIsIHdoZXRoZXIgdGhl c2UgYXJlIGFncmVlbWVudHMsIGRpc2FncmVlbWVudHMsIG9yIGdlbmVyYWwgY29tbWVudHMu IFBsZWFzZSBzaGFyZSB5b3VyIGZlZWRiYWNrIG9uIHRoaXMgbWFpbGluZyBsaXN0IChwcmVm ZXJyZWQpIG9yIHRocm91Z2ggcHJpdmF0ZSBjb21tdW5pY2F0aW9uLg0KPiANCj4gIyMjIFRv b2xpbmcNCj4gDQo+IE92ZXIgdGhlIHBhc3QgZml2ZSB5ZWFycywgb3VyIGVmZm9ydHMgaGF2 ZSBmb2N1c2VkIG9uIGludGVncmF0aW5nIE1pcmFnZS1zcGVjaWZpYyB0b29saW5nIGludG8g dGhlIE9DYW1sIFBsYXRmb3JtLiBXZSBwbGFuIHRvIGNvbnRpbnVlIGluIHRoaXMgZGlyZWN0 aW9uLiBUaGlzIGludGVncmF0aW9uIGlzIGludGVuZGVkIHRvIGJlbmVmaXQgYm90aCBNaXJh Z2UgZGV2ZWxvcGVycyAoYnkgcmVkdWNpbmcgdGhlIG1haW50ZW5hbmNlIGJ1cmRlbiBvbiB0 aGUgY29yZSBNaXJhZ2VPUyB0ZWFtKSBhbmQgdGhlIGJyb2FkZXIgT0NhbWwgdXNlciBiYXNl IChhcyB0aGV5IGNvdWxkIGJlbmVmaXQgZnJvbSBNaXJhZ2VPUyB3b3JrZmxvdyAtLSBlc3Bl Y2lhbGx5IGNyb3NzLWNvbXBpbGF0aW9uIC0tIGluIG90aGVyIHNpdHVhdGlvbnMpLg0KPiAN Cj4gQSBzaWduaWZpY2FudCBwYXJ0IG9mIHRoaXMgZWZmb3J0IHdhcyB0cmFuc2l0aW9uaW5n IGZyb20gY3VzdG9tIHgtY29tcGlsYXRpb24gcnVuZXMgdG8gdXNpbmcgRHVuZSB3b3Jrc3Bh Y2UgdmlhIGBvcGFtIC1tb25vcmVwb2AuIFRoaXMgbWlncmF0aW9uIHdhcyBub3QgYWx3YXlz IHBhaW5sZXNzICh0byBzYXkgdGhlIGxlYXN0KSwgYnV0IHdlIGxlYXJuZWQgYSBmZXcgdGhp bmdzIHRoYXQgYXJlIG5vdyBiZWluZyBhcHBsaWVkIHRvIHRoZSBuZXcgInBhY2thZ2UgbWFu YWdlbWVudCIgZmVhdHVyZSBvZiBEdW5lIDQuIFRodXMsIHdlIHBsYW4gdG8gY29udGludWUg dG8gd29yayBvbiBtaWdyYXRpbmcgZnJvbSBgb3BhbS1tb25vcmVwb2AgdG8gdGhlIGBkdW5l IHBrZ2AgY29tbWFuZCB0byBlbnN1cmUgaXQgd29ya3MgZm9yIE1pcmFnZU9TIHVzZXJzLiBU aGlzIG5ldyBjb21tYW5kIGFkZHJlc3NlcyB0aGUgbGltaXRhdGlvbnMgaWRlbnRpZmllZCBp biBvcGFtLW1vbm9yZXBvLCBlc3BlY2lhbGx5IGZvciBwYWNrYWdlcyBub3QgYnVpbHQgd2l0 aCBEdW5lLiBBbiBhbHBoYSB2ZXJzaW9uIGlzIGN1cnJlbnRseSBhdmFpbGFibGUgKHRyeSBg ZHVuZSBwa2dgIHdpdGggRHVuZSAzLjEyKSwgYW5kIHdlIGFudGljaXBhdGUgYSBjb21wbGV0 ZSByZWxlYXNlIGluIFExIDIwMjQuIFdlIHJlYWxseSB3YW50IHRvIGVuc3VyZSB0aGlzIGlz IGEgZHJvcC1pbiByZXBsYWNlbWVudCBmb3IgTWlyYWdlJ3MgdXNlIG9mIGBvcGFtLW1vbm9y ZXBvYCwgc28gd2Ugd2lsbCB3b3JrIHdpdGggdXBzdHJlYW0gdG8gZW5zdXJlIHRoYXQgaXMg dGhlIGNhc2UgKGFuZCBzbyB3ZSBjYW4gZGVwcmVjYXRlIG9wYW0tbW9ub3JlcG8gaW4gUTIg MjAyNCkuDQo+IA0KPiBSZWdhcmRpbmcgbWlyYWdlL2Z1bmN0b3JpYSwgbXkgZ2VuZXJhbCBm ZWVsaW5nIGlzIHRoYXQgd2hpbGUgdGhlIENMSSB0b29sIHdhcyBpbml0aWFsbHkgdmFsdWFi bGUgZm9yIGdhdGhlcmluZyBhbiBlY29zeXN0ZW0gb2YgbGlicmFyaWVzLCBub3dhZGF5cywg aXQgaXMgbGVzcyBjbGVhciBpZiB0aGlzIGlzIHN0aWxsIHJlcXVpcmVkLiBSaWdodCBub3cs IG1vc3Qgb2YgdGhlIHRvb2wncyBjb21wbGV4aXR5IGlzIGhhbmRsaW5nIHRoZSBpbnN0YWxs YXRpb24gb2YgcGFja2FnZXMgbmVlZGVkIGZvciBhIHNwZWNpZmljIHRhcmdldC9jb21iaW5h dGlvbiBvZiBkZXZpY2VzLiBUaGlzIHdpbGwgbm8gbG9uZ2VyIGJlIG5lZWRlZCBpZiB0aGUg YnVpbGQgc3lzdGVtIGNhbiBkbyB0aGlzIGluc3RlYWQuIElkZWFsbHksIGFueSBPQ2FtbCBh cHBsaWNhdGlvbiAoZm9sbG93aW5nIGEgZmV3IGRlc2lnbiBwcmluY2lwbGVzKSBjb3VsZCBi ZSBjb21waWxlZCB0byBhIHVuaWtlcm5lbCBzaW1wbHkgdXNpbmcgRHVuZSwgYXMgZW52aXNp b25lZCBieSB0aGUgW1dvcmtmbG93IFcxMl0oaHR0cHM6Ly9vY2FtbC5vcmcvZG9jcy9wbGF0 Zm9ybS1yb2FkbWFwI3cxMi1jb21waWxlLXRvLW1pcmFnZW9zKSBvZiB0aGUgT0NhbWwgUm9h ZG1hcC4gSG93ZXZlciwgdGhlcmUgaXMgbm8gZXhpc3RpbmcgZGVzaWduIG9uIGhvdyB0aGlz IHNob3VsZCB3b3JrIGF0IHRoaXMgc3RhZ2UuIFNvLCBiZWZvcmUgc3RhcnRpbmcgdGhpcywg aXMgdGhhdCB0aGUgcmlnaHQgZGlyZWN0aW9uIGZvciB0aGUgbWlyYWdlIHRvb2w/DQo+IA0K PiAjIyMgVGFyZ2V0cw0KPiANCj4gVGhlIHByaW5jaXBhbCB0YXJnZXQgYmFja2VuZCBmb3Ig TWlyYWdlT1Mgbm93YWRheXMgaXMgU29sbzUuIFRoaXMgaXMgYSBzb2xpZCBiYWNrZW5kLCB3 aGljaCBoYXMgYmVlbiBhdWRpdGVkIGFuZCBvcHRpbWlzZWQgZm9yIHNlY3VyaXR5LiBJdCBp cyBhbHNvIHJlbGF0aXZlbHkgc2ltcGxlIHRvIGFkZCBuZXcgZGV2aWNlcyBnaXZlbiB0aGUg YnktZGVzaWduIGxvdy1jb21wbGV4aXR5IGFwcHJvYWNoIG9mIGl0cyBkZXZpY2UgbW9kZWwu IEhvd2V2ZXIsIHdoaWxlIHNvbG81IGlzIHRvZGF5IHRoZSBtb3N0IHNlY3VyZSB1bmlrZXJu ZWwgInJ1bnRpbWUiLCBJIGFsc28gZmVlbCBpdCBoYXMgaXNzdWVzIGhpbmRlcmluZyBwb3Rl bnRpYWwgY2hhbmdlcy4gRm9yIG9uZSwgaXQgaXMgc2xvdyAtLSB0aGUgZGV2aWNlIG1vZGVs IGlzIG5vdCBtZWFudCBmb3IgaGlnaC1zcGVlZCBJL08sIGFuZCB0aGVyZSBpcyBubyBzdXBw b3J0IGZvciBTTVA7IGZvciBtb3N0IHVzZSBjYXNlcywgaXQgaXMgbm90IGFuIGlzc3VlLCBi dXQgZm9yIG90aGVycyB3ZSBhcmUgbG9va2luZyBhdCwgaXQgY2FuIGJlLiBUaGUgb3RoZXIg b25lIGlzIHRoYXQgdGhlIGRldmljZSBtb2RlbCBpcyB2ZXJ5IHNpbXBsZSAoZm9yIGdvb2Qg cmVhc29ucykgYW5kIGNoYWxsZW5naW5nIHRvIGV4dGVuZCB0byBuZXcgZGV2aWNlcyAoc2Vl IGJlbG93IGZvciBtb3JlIGRldGFpbCkuIEluIGFuIGlkZWFsIHdvcmxkLCB0aGlzIGNvdWxk IGJlIGZpeGFibGUsIGJ1dCB0aGVyZSBhcmUgYWxzbyB2ZXJ5IGZldyBjb3VyYWdlb3VzIGFj dGl2ZSBtYWludGFpbmVycywgc28gYW55IGNoYW5nZXMgLSBsaWtlIG1vdmluZyB0byBPQ2Ft bDUgLSBhcmUgY29tcGxleCB0byBtYWtlLg0KPiANCj4gVGh1cywgd2UgYXJlIGV2YWx1YXRp bmcgYWx0ZXJuYXRlIGJhY2tlbmRzIHdpdGggdGhlIG1haW4gY3JpdGVyaWEgdG8gcmVkdWNl IHRoZSBtYWludGVuYW5jZSBjb3N0LiBEZXNwaXRlIGl0cyBjdXJyZW50bHkgbGltaXRlZCBz ZWN1cml0eSBmZWF0dXJlcywgb25lIGludGVyZXN0aW5nIHBvc3NpYmlsaXR5IGlzIHNoaWZ0 aW5nIHRvd2FyZHMgYWx0ZXJuYXRpdmUgYmFja2VuZHMgbGlrZSB1bmlrcmFmdC4gQ2hyaXN0 aWFubyBzcGVudCBhIGJpdCBvZiB0aW1lIGxvb2tpbmcgYXQgdGhpcyBlYXJsaWVyIHRoaXMg eWVhciAod2l0aCBhIHByb3RvdHlwZSBvZiB0aGUgT0NhbWwgNSBydW50aW1lIHgtY29tcGls ZXIgdG8gVW5pa3JhZnQgW2hlcmVdKGh0dHBzOi8vZ2l0aHViLmNvbS9oYWVzYmFlcnQvdW5p a3JhZnQtb2NhbWwpIGFuZCBhIHJvYWRtYXAgZm9yIFVuaWtyYWZ0IHNlY3VyaXR5IFtoZXJl XShodHRwczovL2dpdGh1Yi5jb20vb3Jncy91bmlrcmFmdC9wcm9qZWN0cy8zMi92aWV3cy8x KSkuIFNhbWUgYXMgYWJvdmUsIHdlIGFyZSBpbnRlcmVzdGVkIHRvIGhlYXIgd2hhdCBwZW9w bGUgdGhpbmsgYW5kIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkIGluIGNvbGxhYm9yYXRpbmcg d2l0aCB1cyBpbiBwb3J0aW5nIE1pcmFnZU9TIHRvIHVuaWtyYWZ0IChhbmQgY29udHJpYnV0 aW5nIHRvIFVuaWtmcmFmdCcgc2VjdXJpdHkgcm9hZG1hcCkuDQo+IA0KPiAjIyMgRGV2aWNl cyBhbmQgTGlicmFyaWVzDQo+IA0KPiBUaGVyZSBhcmUgdGhyZWUgYXJlYXMgdGhhdCB3ZSB3 b3VsZCBsaWtlIHRvIGZvY3VzIG9uIChvciBjb250aW51ZSB0byBmb2N1cyBvbikgaW4gdGhl IG5leHQgY291cGxlIG9mIHllYXJzLg0KPiANCj4gRmlyc3QsIHdlIHN0aWxsIGJlbGlldmUg dGhlcmUgYXJlIGJldHRlciBhYnN0cmFjdGlvbnMgZm9yIHN0b3JpbmcgZGF0YSB0aGFuIFBP U0lYLiBIZW5jZSwgd2UgYXJlIGNvbnRpbnVpbmcgdG8gZGV2ZWxvcCBhbmQgaW1wcm92ZSBJ cm1pbi4gV2UgYXJlIGN1cnJlbnRseSBwb3J0aW5nIGBpcm1pbi1wYWNrYCB0byBNaXJhZ2VP UyAodGhlIGJhY2tlbmQgb2YgSXJtaW4gdXNlZCBieSB0aGUgVGV6b3MgYmxvY2tjaGFpbiB0 byBzdG9yZSBpdHMgbGVkZ2VyIGhpc3RvcnkpIHZpYSB0aGUgW05vdGFmc10oaHR0cHM6Ly9n aXRodWIuY29tL3RhcmlkZXMvbm90YWZzKSBwcm9qZWN0LiBOb3RhZnMgaXMgYSBwc2V1ZG8g ZmlsZXN5c3RlbSBmb3IgTWlyYWdlIGJsb2NrIGRldmljZXMuIEl0IGNhbiBoYW5kbGUgYSBz bWFsbCBudW1iZXIgb2YgbGFyZ2UgZmlsZXMuIFdoaWxlIHRoZSBsaW1pdGVkIG51bWJlciBv ZiBmaWxlbmFtZXMgaXMgdW5zYXRpc2Z5aW5nIGZvciBnZW5lcmFsIHVzYWdlLCBpdCBjYW4g YmUgdXNlZCB0byBydW4gdGhlIGlybWluLXBhY2sgYmFja2VuZCBvZiBJcm1pbiwgd2hpY2gg b25seSByZXF1aXJlcyBhIGRvemVuIGh1Z2UgZmlsZXMuIEJ5IHJ1bm5pbmcgSXJtaW4sIG9u ZSBnZXRzIGZvciBmcmVlIGEgZmlsZXN5c3RlbS1vbi1zdGVyb2lkIGZvciBNaXJhZ2VPUzog aXQgc3VwcG9ydHMgYW4gYXJiaXRyYXJpbHkgbGFyZ2UgbnVtYmVyIG9mIGZpbGVuYW1lczsg aXMgb3B0aW1pc2VkIGZvciBzbWFsbCBhbmQgbGFyZ2UgZmlsZSBjb250ZW50czsgcGVyZm9y bXMgZmlsZSBkZWR1cGxpY2F0aW9uOyBpbmNsdWRlcyBhIGdpdC1saWtlIGhpc3Rvcnkgd2l0 aCBicmFuY2hpbmcgYW5kIG1lcmdpbmcsIC4uLiBhbmQgaXQgZXZlbiBwcm92aWRlcyBhIGdh cmJhZ2UgY29sbGVjdG9yIHRvIGF2b2lkIHJ1bm5pbmcgb3V0IG9mIGRpc2sgc3BhY2UgKGJ5 IGRlbGV0aW5nIG9sZGVyIGNvbW1pdHMpLiBTaW5jZSB0aGUgSXJtaW4gZmlsZXN5c3RlbSBp cyB2ZXJzaW9uZWQgYnkgTWVya2xlIGhhc2hlcywgb25lIGNhbiBpbWFnaW5lIGRlcGxveWlu ZyByZXByb2R1Y2libGUgdW5pa2VybmVscyBvbiByZXByb2R1Y2libGUgZmlsZXN5c3RlbSBz dGF0ZXMhDQo+IA0KPiBXZSBhcmUgYWxzbyBpbnRlcmVzdGVkIGluIGRldmVsb3BpbmcgbmV3 IG5ldHdvcmsgcHJvdG9jb2xzIGZvciBzcGFjZSBhcHBsaWNhdGlvbnMsIHdoaWNoIGNvdWxk IGJlbmVmaXQgZnJvbSBNaXJhZ2VPUydzIGNhcGFiaWxpdGllcy4gV2UgYXJlIGxpa2VseSB0 YXJnZXRpbmcgdGhlIFtTcGFjZSBDb21tdW5pY2F0aW9uIFByb3RvY29sXShodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9TcGFjZV9Db21tdW5pY2F0aW9uc19Qcm90b2NvbF9TcGVj aWZpY2F0aW9ucyksIHdoaWNoIHNlZW1zIGFuIGludGVyZXN0aW5nIGRvbWFpbiBhcyB0aGVy ZSBkb2VzIG5vdCBzZWVtIHRvIGV4aXN0IGFueSBvcGVuLXNvdXJjZSwgcm9idXN0IGltcGxl bWVudGF0aW9uIG9mIHRoZXNlIHByb3RvY29scy4NCj4gDQo+IEZpbmFsbHksIHRoZSBBUEkg Zm9yIGRldmljZXMgc3VwcG9ydGVkIGJ5IE1pcmFnZU9TIGN1cnJlbnRseSBtYXBzIHRvIHdo YXQgaXMgYXZhaWxhYmxlIG9uIHZpcnR1YWxpc2VkIGluZnJhc3RydWN0dXJlIChpLmUuIHZp cnR1YWwgYmxvY2sgZGV2aWNlcyBhbmQgdmlydHVhbCBuZXR3b3JrIGludGVyZmFjZSkuIFdl IGFyZSBpbnRlcmVzdGVkIGluIGludmVzdGlnYXRpbmcgaG93IHRvIGV4dGVuZCB0aGlzLCBm b3IgaW5zdGFuY2UsIGJ5IHJldml2aW5nIHRoZSBQQ0ktcGFzc3Rocm91Z2ggZXhwZXJpbWVu dGF0aW9ucyBkb25lIGEgZmV3IHllYXJzIGFnbyBieSBGbG9yaWFuLCBvciBieSBpbnZlc3Rp Z2F0aW5nIG5ldyBtdWx0aS10ZW5hbmN5IGRldmljZSBmcmFtZXdvcmtzIGxpa2UgW3ZBY2Nl bF0oaHR0cHM6Ly92YWNjZWwub3JnLykgdG8gKHNlY3VyZWx5Pykgc2hhcmUgR1BHUFVzIG9y IEZQR0FzIGJldHdlZW4gdXNlcnMuIEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIHVzZSBPd2wg dXNpbmcgQ1BVLiBXZSBhbHNvIHdlbGNvbWUgYW55b25lIHdpdGggYW55IGV4cGVyaWVuY2Ug aW4gdGhpcyBhcmVhIHRvIGRpc2N1c3MgZXhpc3RpbmcgYWx0ZXJuYXRpdmVzLg0KPiANCj4g IyMjIE9TIERpc3RyaWJ1dGlvbg0KPiANCj4gRmluYWxseSwgd2UgYXJlIGNvbnNpZGVyaW5n IG9wdGlvbnMgZm9yIGJ1aWxkaW5nIGEgZmxleGlibGUgT1MgZGlzdHJpYnV0aW9uLCB3aGlj aCBtaWdodCBpbmNsdWRlIGVsZW1lbnRzIGxpa2UgW0xpbnV4S2l0L01pcmFnZVNES10oaHR0 cHM6Ly9naXRodWIuY29tL2xpbnV4a2l0L2xpbnV4a2l0L3RyZWUvbWFzdGVyL3Byb2plY3Rz L21pcmFnZXNkaykuIFRoaXMgY29uY2VwdCBjb21iaW5lcyBhIHNlY3VyZSBMaW51eCBrZXJu ZWwgd2l0aCBhIGNvbGxlY3Rpb24gb2YgTWlyYWdlLWJhc2VkIHN5c3RlbSBzZXJ2aWNlcyBh bmQgYW4gZXh0ZW5kZWQgdmVyc2lvbiBvZiBBbGJhdHJvc3MgZm9yIG9yY2hlc3RyYXRpb24s IGFsbCBjdXN0b21pc2FibGUgYmFzZWQgb24gc3BlY2lmaWMgbmVlZHMuIFdlIGFyZSBpbiB0 aGUgZWFybHkgc3RhZ2VzIG9mIHRoaXMgZGlzY3Vzc2lvbiBhbmQgd2VsY29tZSBhbnkgaW5w dXQgb3IgZXhwcmVzc2lvbnMgb2YgaW50ZXJlc3QgaW4gZnVydGhlcmluZyB0aGVzZSBpZGVh cy4NCj4gDQo+IEJlc3QsDQo+IFRob21hcw0KPiANCj4gDQo= From mirageos-devel-bounces@lists.xenproject.org Tue Dec 19 13:11:20 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 19 Dec 2023 13:11:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.656783.1025220 (Exim 4.92) (envelope-from ) id 1rFZsK-0000w7-Hx; Tue, 19 Dec 2023 13:11:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 656783.1025220; Tue, 19 Dec 2023 13:11:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFZsK-0000w0-F0; Tue, 19 Dec 2023 13:11:08 +0000 Received: by outflank-mailman (input) for mailman id 656783; Tue, 19 Dec 2023 13:11:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFZsJ-0000uo-TN for mirageos-devel@lists.xenproject.org; Tue, 19 Dec 2023 13:11:07 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0f6c3b7e-9e70-11ee-9b0f-b553b5be7939; Tue, 19 Dec 2023 14:11:04 +0100 (CET) Received: from [192.168.42.12] (i59F5CAF8.versanet.de [89.245.202.248]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id E67501A22F for ; Tue, 19 Dec 2023 14:11:01 +0100 (CET) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: 0f6c3b7e-9e70-11ee-9b0f-b553b5be7939 Message-ID: Date: Tue, 19 Dec 2023 14:10:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-US To: mirageos-devel@lists.xenproject.org References: From: Hannes Mehnert Subject: Re: Updates on Tarides Plans with MirageOS - Request for Feedback In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGksDQoNCg0KdGhhbmtzIGZvciB5b3VyIGVsYWJvcmF0ZSBtYWlsLiBJIGhhdmUgc29tZSBj b21tZW50cyBpbmxpbmUgYmVsb3cuDQoNCg0KT24gMTUvMTIvMjAyMyAxOToxOCwgVGhvbWFz IEdhemFnbmFpcmUgd3JvdGU6DQo+ICMjIyBUb29saW5nDQo+IA0KPiBPdmVyIHRoZSBwYXN0 IGZpdmUgeWVhcnMsIG91ciBlZmZvcnRzIGhhdmUgZm9jdXNlZCBvbiBpbnRlZ3JhdGluZyBN aXJhZ2Utc3BlY2lmaWMgdG9vbGluZyBpbnRvIHRoZSBPQ2FtbCBQbGF0Zm9ybS4gV2UgcGxh biB0byBjb250aW51ZSBpbiB0aGlzIGRpcmVjdGlvbi4gVGhpcyBpbnRlZ3JhdGlvbiBpcyBp bnRlbmRlZCB0byBiZW5lZml0IGJvdGggTWlyYWdlIGRldmVsb3BlcnMgKGJ5IHJlZHVjaW5n IHRoZSBtYWludGVuYW5jZSBidXJkZW4gb24gdGhlIGNvcmUgTWlyYWdlT1MgdGVhbSkgYW5k IHRoZSBicm9hZGVyIE9DYW1sIHVzZXIgYmFzZSAoYXMgdGhleSBjb3VsZCBiZW5lZml0IGZy b20gTWlyYWdlT1Mgd29ya2Zsb3cgLS0gZXNwZWNpYWxseSBjcm9zcy1jb21waWxhdGlvbiAt LSBpbiBvdGhlciBzaXR1YXRpb25zKS4NCj4gDQo+IEEgc2lnbmlmaWNhbnQgcGFydCBvZiB0 aGlzIGVmZm9ydCB3YXMgdHJhbnNpdGlvbmluZyBmcm9tIGN1c3RvbSB4LWNvbXBpbGF0aW9u IHJ1bmVzIHRvIHVzaW5nIER1bmUgd29ya3NwYWNlIHZpYSBgb3BhbSAtbW9ub3JlcG9gLiBU aGlzIG1pZ3JhdGlvbiB3YXMgbm90IGFsd2F5cyBwYWlubGVzcyAodG8gc2F5IHRoZSBsZWFz dCksIGJ1dCB3ZSBsZWFybmVkIGEgZmV3IHRoaW5ncyB0aGF0IGFyZSBub3cgYmVpbmcgYXBw bGllZCB0byB0aGUgbmV3ICJwYWNrYWdlIG1hbmFnZW1lbnQiIGZlYXR1cmUgb2YgRHVuZSA0 LiBUaHVzLCB3ZSBwbGFuIHRvIGNvbnRpbnVlIHRvIHdvcmsgb24gbWlncmF0aW5nIGZyb20g YG9wYW0tbW9ub3JlcG9gIHRvIHRoZSBgZHVuZSBwa2dgIGNvbW1hbmQgdG8gZW5zdXJlIGl0 IHdvcmtzIGZvciBNaXJhZ2VPUyB1c2Vycy4gVGhpcyBuZXcgY29tbWFuZCBhZGRyZXNzZXMg dGhlIGxpbWl0YXRpb25zIGlkZW50aWZpZWQgaW4gb3BhbS1tb25vcmVwbywgZXNwZWNpYWxs eSBmb3IgcGFja2FnZXMgbm90IGJ1aWx0IHdpdGggRHVuZS4gQW4gYWxwaGEgdmVyc2lvbiBp cyBjdXJyZW50bHkgYXZhaWxhYmxlICh0cnkgYGR1bmUgcGtnYCB3aXRoIER1bmUgMy4xMiks IGFuZCB3ZSBhbnRpY2lwYXRlIGEgY29tcGxldGUgcmVsZWFzZSBpbiBRMSAyMDI0LiBXZSBy ZWFsbHkgd2FudCB0byBlbnN1cmUgdGhpcyBpcyBhIGRyb3AtaW4gcmVwbGFjZW1lbnQgZm9y IE1pcmFnZSdzIHVzZSBvZiBgb3BhbS1tb25vcmVwb2AsIHNvIHdlIHdpbGwgd29yayB3aXRo IHVwc3RyZWFtIHRvIGVuc3VyZSB0aGF0IGlzIHRoZSBjYXNlIChhbmQgc28gd2UgY2FuIGRl cHJlY2F0ZSBvcGFtLW1vbm9yZXBvIGluIFEyIDIwMjQpLg0KDQoNCkknbSBsb29raW5nIGZv cndhcmQgdG8gcmVtb3ZlIG9wYW0tbW9ub3JlcG8gZnJvbSB0aGUgY2hhaW4gLSBidXQgYXQg dGhlIA0Kc2FtZSB0aW1lIEknbSB3b3JyaWVkIHRoYXQgImR1bmUgcGtnIiB3aWxsIGp1c3Qg aGF2ZSBkaWZmZXJlbnQgYnVncy4gSSANCmhvcGUgeW91IG1hbmFnZWQgdG8gdXNlIHRoZSBp c3N1ZSByZXBvcnRlZCBhdCBvcGFtLW1vbm9yZXBvIHRvIGNvbnN0cnVjdCANCmEgdGVzdCBz dWl0ZSBvbiBob3cgImR1bmUgcGtnIiBzaG91bGQgbm90IGZhaWwuIE5vdGUgdGhhdCBpbiAN Cm9wYW0tbW9ub3JlcG8gdGhlcmUgd2VyZSBxdWl0ZSBzb21lIGlzc3VlcyB3aXRoIHNwZWNp ZmljIHZlcnNpb25zIG9mIHRoZSANCm9wYW0tcmVwb3NpdG9yeSAoc3VyZWx5IGFsbCBvZiBp dCBpcyByZXRyaWV2YWJsZSBhbmQgcmVjb25zdHJ1Y3RpYmxlKS4NCg0KSSBhbSBhIGJpdCB3 b3JyaWVkLCBzaW5jZSB0aGUgbWlyYWdlMyAtPiBtaXJhZ2U0IGNoYW5nZSAoY2hhbmdlIG9m IA0KY29tcGlsYXRpb24gc3RyYXRlZ3kpIGhhZCBxdWl0ZSBzb21lIGltcGFjdCBvbiBvdXIg cmVwcm9kdWNpYmxlIGJ1aWxkIA0Kc3lzdGVtIChodHRwczovL2J1aWxkcy5yb2J1ci5jb29w LCBodHRwczovL2dpdGh1Yi5jb20vcm9idXItY29vcC9vcmIpIC0gDQpub3cgd2hlbiBvcGFt LW1vbm9yZXBvIHdpbGwgYmUgZGVwcmVjYXRlZCBpbiBmYXZvdXIgb2YgImR1bmUgcGtnIiwg bXkgDQp3b3JyeSBpcyB0aGF0IHRoZXJlJ3MgYWdhaW4gcXVpdGUgc29tZSB3b3JrIG5lZWRl ZCBvbiBvdXIgZW5kLiBJdCB0dXJucyANCm91dCwgb25seSBtaXJhZ2UgNC4yIHdhcyBpbiBh IHNoYXBlIHdoZXJlIHdlIGNvdWxkIHVzZSBpdCBmb3IgDQpyZXByb2R1Y2libGUgYnVpbGRz Lg0KDQpCdXQgSSdtIHN1cmUgeW91J3JlIGF3YXJlIG9mIHRoZSBpc3N1ZXMgdGhhdCB3ZSBl bmNvdW50ZXJlZCBhbmQgcHVzaGVkIA0KdXBzdHJlYW0gdG8gZS5nLiBtaXJhZ2UsIGFuZCBo b3cgYWxsIHRoZSBiaXRzIA0KKG1pcmFnZS9vcGFtL29yYi9vcGFtLW1vbm9yZXBvKSBjdXJy ZW50bHkgZml0IHRvZ2V0aGVyLCBhbmQgaG93ICJkdW5lIA0KcGtnIiB3aWxsIGZpdCBpbi4N Cg0KDQo+IFJlZ2FyZGluZyBtaXJhZ2UvZnVuY3RvcmlhLCBteSBnZW5lcmFsIGZlZWxpbmcg aXMgdGhhdCB3aGlsZSB0aGUgQ0xJIHRvb2wgd2FzIGluaXRpYWxseSB2YWx1YWJsZSBmb3Ig Z2F0aGVyaW5nIGFuIGVjb3N5c3RlbSBvZiBsaWJyYXJpZXMsIG5vd2FkYXlzLCBpdCBpcyBs ZXNzIGNsZWFyIGlmIHRoaXMgaXMgc3RpbGwgcmVxdWlyZWQuIFJpZ2h0IG5vdywgbW9zdCBv ZiB0aGUgdG9vbCdzIGNvbXBsZXhpdHkgaXMgaGFuZGxpbmcgdGhlIGluc3RhbGxhdGlvbiBv ZiBwYWNrYWdlcyBuZWVkZWQgZm9yIGEgc3BlY2lmaWMgdGFyZ2V0L2NvbWJpbmF0aW9uIG9m IGRldmljZXMuIFRoaXMgd2lsbCBubyBsb25nZXIgYmUgbmVlZGVkIGlmIHRoZSBidWlsZCBz eXN0ZW0gY2FuIGRvIHRoaXMgaW5zdGVhZC4gSWRlYWxseSwgYW55IE9DYW1sIGFwcGxpY2F0 aW9uIChmb2xsb3dpbmcgYSBmZXcgZGVzaWduIHByaW5jaXBsZXMpIGNvdWxkIGJlIGNvbXBp bGVkIHRvIGEgdW5pa2VybmVsIHNpbXBseSB1c2luZyBEdW5lLCBhcyBlbnZpc2lvbmVkIGJ5 IHRoZSBbV29ya2Zsb3cgVzEyXShodHRwczovL29jYW1sLm9yZy9kb2NzL3BsYXRmb3JtLXJv YWRtYXAjdzEyLWNvbXBpbGUtdG8tbWlyYWdlb3MpIG9mIHRoZSBPQ2FtbCBSb2FkbWFwLiBI b3dldmVyLCB0aGVyZSBpcyBubyBleGlzdGluZyBkZXNpZ24gb24gaG93IHRoaXMgc2hvdWxk IHdvcmsgYXQgdGhpcyBzdGFnZS4gU28sIGJlZm9yZSBzdGFydGluZyB0aGlzLCBpcyB0aGF0 IHRoZSByaWdodCBkaXJlY3Rpb24gZm9yIHRoZSBtaXJhZ2UgdG9vbD8NCg0KDQpNeSBleHBl cmllbmNlIHdpdGggTWlyYWdlIC0gdGhlIHRvb2wgLSBpcyB0aGF0IGl0IGRvZXMgdmFyaW91 cyB0aGluZ3MgYXQgDQpvbmNlOg0KLSBmaWd1cmluZyBvdXQgZGVwZW5kZW5jaWVzIGFuZCBy ZXF1aXJlbWVudHMgb2YgTWlyYWdlT1MgZGV2aWNlcywgDQpwdXR0aW5nIHRoZW0gaW50byBh IGJvb3Qgb3JkZXIgKHdoYXQgaXMgZ2VuZXJhdGVkIGFzIG1haW4ubWwpDQotIHNlbGVjdGlu ZyB0YXJnZXQtc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zIChzdGlsbCwgSSB0aG91Z2h0IHNv bWVvbmUgDQp3YW50ZWQgdG8gcmV2aXNlIHRoaXMgdG8gdXNlICJkdW5lIHZhcmlhbnRzIiwg YnV0IGhhdmVuJ3Qgc2VlbiBhbnkgDQpkZW1vbnN0cmF0aW9uIHRoZXJlb2YpDQotIGNvbW1h bmQgbGluZSBhcmd1bWVudHMgYXQgY29uZmlndXJlIGFuZCBib290IHRpbWUgKGhlcmUsIHRo ZXJlIGhhcyANCmJlZW4gdmFyaW91cyByZWNlbnQgZGlzY3Vzc2lvbnMsIA0KaHR0cHM6Ly9n aXRodWIuY29tL21pcmFnZS9taXJhZ2UvaXNzdWVzLzE0MjIsIGFuZCBhIGh1Z2UgYW1vdW50 IG9mIA0KcmVzaHVmZmxpbmcgYW5kIGltcGxlbWVudGF0aW9uIHdvcmsgYnkgeW91cnNlbGYg LS0gd2hpY2ggdW5mb3J0dW5hdGVseSANCmRvZXNuJ3Qgc2VlbSB0byBiZSByZWFkeSB5ZXQg KG1lcmdlZCBvbnRvIHRoZSBtYWluIGJyYW5jaCwgYnV0IHRha2UgYSANCmxvb2sgYXQgdGhl IHJlZ3Jlc3Npb25zIGh0dHBzOi8vZ2l0aHViLmNvbS9taXJhZ2UvbWlyYWdlL2lzc3Vlcy8x NDc5IA0KaHR0cHM6Ly9naXRodWIuY29tL21pcmFnZS9taXJhZ2UvaXNzdWVzLzE0ODMpLCBh bmQgbG9va3Mgc2xpZ2h0bHkgYWJhbmRvbmVkDQotIGNyb3NzLWNvbXBpbGluZy9saW5raW5n ICh1c2luZyBvY2FtbC1zb2xvNSB3aXRoIHNvbG81IA0KY3Jvc3MtY29tcGlsYXRpb24gc2hl bGwtc2NyaXB0LCBhbmQgb3BhbS1tb25vcmVwbyB0byBjb25zdHJ1Y3QgYSBtb25vcmVwbykN Cg0KT3V0IG9mIHRoZXNlIDQgaXRlbXMsIEknbSBub3Qgc3VyZSB3aGF0ICJkdW5lIC14IG1p cmFnZSIgd2lsbCBhdHRlbXB0IHRvIA0Kc29sdmUuIE15IGdvYWwgaXMgdG8gbWFrZSBtaXJh Z2UgLSB0aGUgdG9vbCAtIGxlc3Mgc21hcnQgYWJvdXQgd2hhdCBpdCANCmF0dGVtcHRzIHRv IGFjaGlldmUsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgbW92aW5nIHRoZXNlIGJpdHMgaW50 byBkdW5lIA0Kd291bGQgYmUgYmVuZWZpY2lhbC4NCg0KDQo+ICMjIyBUYXJnZXRzDQo+IA0K PiBUaGUgcHJpbmNpcGFsIHRhcmdldCBiYWNrZW5kIGZvciBNaXJhZ2VPUyBub3dhZGF5cyBp cyBTb2xvNS4gVGhpcyBpcyBhIHNvbGlkIGJhY2tlbmQsIHdoaWNoIGhhcyBiZWVuIGF1ZGl0 ZWQgYW5kIG9wdGltaXNlZCBmb3Igc2VjdXJpdHkuIEl0IGlzIGFsc28gcmVsYXRpdmVseSBz aW1wbGUgdG8gYWRkIG5ldyBkZXZpY2VzIGdpdmVuIHRoZSBieS1kZXNpZ24gbG93LWNvbXBs ZXhpdHkgYXBwcm9hY2ggb2YgaXRzIGRldmljZSBtb2RlbC4gSG93ZXZlciwgd2hpbGUgc29s bzUgaXMgdG9kYXkgdGhlIG1vc3Qgc2VjdXJlIHVuaWtlcm5lbCAicnVudGltZSIsIEkgYWxz byBmZWVsIGl0IGhhcyBpc3N1ZXMgaGluZGVyaW5nIHBvdGVudGlhbCBjaGFuZ2VzLiBGb3Ig b25lLCBpdCBpcyBzbG93IC0tIHRoZSBkZXZpY2UgbW9kZWwgaXMgbm90IG1lYW50IGZvciBo aWdoLXNwZWVkIEkvTywNCg0KDQpUaGVyZSBoYXZlIGJlZW4gY29udHJpYnV0aW9ucyBhbmQg YXR0ZW1wdHMgdG8gaW1wbGVtZW50IHRoYXQgLSBzZWUgDQpodHRwczovL2dpdGh1Yi5jb20v c29sbzUtbmV0bWFwL3NvbG81L3RyZWUvbmV0bWFwIGFzIGV4YW1wbGUuIEkgZG9uJ3QgDQpx dWl0ZSBnZXQgdGhlICJoYXMgaXNzdWVzIGhpbmRlcmluZyBwb3RlbnRpYWwgY2hhbmdlcyIu DQoNCg0KPiBhbmQgdGhlcmUgaXMgbm8gc3VwcG9ydCBmb3IgU01QOyBmb3IgbW9zdCB1c2Ug Y2FzZXMsIGl0IGlzIG5vdCBhbiBpc3N1ZSwgYnV0IGZvciBvdGhlcnMgd2UgYXJlIGxvb2tp bmcgYXQsIGl0IGNhbiBiZS4NCg0KDQpUaGVyZSBoYXMgYmVlbiBpbiB0aGUgZWFybHkgZGF5 cyBzb21lIGZvcmsgZnJvbSBzb2xvNSBjYWxsZWQgaGVybWl0Y29yZSANCnRoYXQgYWRkZWQg U01QLiBJJ20gY3VyaW91cyB3aHkgeW91IGRpZG4ndCBwaWNrIHRoYXQgdXAgZm9yIHlvdXIg bWFpbC4NCg0KDQo+IFRoZSBvdGhlciBvbmUgaXMgdGhhdCB0aGUgZGV2aWNlIG1vZGVsIGlz IHZlcnkgc2ltcGxlIChmb3IgZ29vZCByZWFzb25zKSBhbmQgY2hhbGxlbmdpbmcgdG8gZXh0 ZW5kIHRvIG5ldyBkZXZpY2VzIChzZWUgYmVsb3cgZm9yIG1vcmUgZGV0YWlsKS4gSW4gYW4g aWRlYWwgd29ybGQsIHRoaXMgY291bGQgYmUgZml4YWJsZSwgYnV0IHRoZXJlIGFyZSBhbHNv IHZlcnkgZmV3IGNvdXJhZ2VvdXMgYWN0aXZlIG1haW50YWluZXJzLCBzbyBhbnkgY2hhbmdl cyAtIGxpa2UgbW92aW5nIHRvIE9DYW1sNSAtIGFyZSBjb21wbGV4IHRvIG1ha2UuDQoNCg0K SG1tLCBvbmUgdGhpbmcgY2xlYXJseSBpcyBzb2xvNSBsYWNraW5nIG1haW50YWluZXJzIGFu ZCBjb250cmlidXRvcnMuIA0KVGhlIG90aGVyIHRoaW5nIGlzIHRoYXQgb2NhbWwtc29sbzUg d2l0aCBpdHMgbWluaW1hbCAobm8pbGliYyBzdXJlbHkgDQpuZWVkcyBhZGFwdGlvbiBmb3Ig dGhlIE9DYW1sNSBydW50aW1lIHJld3JpdGUgKHNlZSB0aGUgUFIgdGhhdCBoYXMgYmVlbiAN CmFyb3VuZCBmb3IgYWdlcykuIE5vdywgd2hlbiB5b3Ugc3dpdGNoIHRvIHVuaWtyYWZ0LCBJ J20gbm90IGVudGlyZWx5IA0Kc3VyZSB3aGF0IHlvdXIgdHJhZGVvZmYgaXM/IERvZXMgdW5p a3JhZnQgc3VwcG9ydCBTTVA/IERpZCB5b3UgZXZhbHVhdGUgDQppbiBkZXRhaWwgdGhlIHRy dXN0ZWQgY29kZSBiYXNlIGRpZmZlcmVuY2VzIGJldHdlZW4gc29sbzUgYW5kIHVuaWtyYWZ0 Pw0KDQoNCj4gIyMjIERldmljZXMgYW5kIExpYnJhcmllcw0KPiANCj4gVGhlcmUgYXJlIHRo cmVlIGFyZWFzIHRoYXQgd2Ugd291bGQgbGlrZSB0byBmb2N1cyBvbiAob3IgY29udGludWUg dG8gZm9jdXMgb24pIGluIHRoZSBuZXh0IGNvdXBsZSBvZiB5ZWFycy4NCj4gDQo+IEZpcnN0 LCB3ZSBzdGlsbCBiZWxpZXZlIHRoZXJlIGFyZSBiZXR0ZXIgYWJzdHJhY3Rpb25zIGZvciBz dG9yaW5nIGRhdGEgdGhhbiBQT1NJWC4gSGVuY2UsIHdlIGFyZSBjb250aW51aW5nIHRvIGRl dmVsb3AgYW5kIGltcHJvdmUgSXJtaW4uIFdlIGFyZSBjdXJyZW50bHkgcG9ydGluZyBgaXJt aW4tcGFja2AgdG8gTWlyYWdlT1MgKHRoZSBiYWNrZW5kIG9mIElybWluIHVzZWQgYnkgdGhl IFRlem9zIGJsb2NrY2hhaW4gdG8gc3RvcmUgaXRzIGxlZGdlciBoaXN0b3J5KSB2aWEgdGhl IFtOb3RhZnNdKGh0dHBzOi8vZ2l0aHViLmNvbS90YXJpZGVzL25vdGFmcykgcHJvamVjdC4g Tm90YWZzIGlzIGEgcHNldWRvIGZpbGVzeXN0ZW0gZm9yIE1pcmFnZSBibG9jayBkZXZpY2Vz LiBJdCBjYW4gaGFuZGxlIGEgc21hbGwgbnVtYmVyIG9mIGxhcmdlIGZpbGVzLiBXaGlsZSB0 aGUgbGltaXRlZCBudW1iZXIgb2YgZmlsZW5hbWVzIGlzIHVuc2F0aXNmeWluZyBmb3IgZ2Vu ZXJhbCB1c2FnZSwgaXQgY2FuIGJlIHVzZWQgdG8gcnVuIHRoZSBpcm1pbi1wYWNrIGJhY2tl bmQgb2YgSXJtaW4sIHdoaWNoIG9ubHkgcmVxdWlyZXMgYSBkb3plbiBodWdlIGZpbGVzLiBC eSBydW5uaW5nIElybWluLCBvbmUgZ2V0cyBmb3IgZnJlZSBhIGZpbGVzeXN0ZW0tb24tc3Rl cm9pZCBmb3IgTWlyYWdlT1M6IGl0IHN1cHBvcnRzIGFuIGFyYml0cmFyaWx5IGxhcmdlIG51 bWJlciBvZiBmaWxlbmFtZXM7IGlzIG9wdGltaXNlZCBmb3Igc21hbGwgYW5kIGxhcmdlIGZp bGUgY29udGVudHM7IHBlcmZvcm1zIGZpbGUgZGVkdXBsaWNhdGlvbjsgaW5jbHVkZXMgYSBn aXQtbGlrZSBoaXN0b3J5IHdpdGggYnJhbmNoaW5nIGFuZCBtZXJnaW5nLCAuLi4gYW5kIGl0 IGV2ZW4gcHJvdmlkZXMgYSBnYXJiYWdlIGNvbGxlY3RvciB0byBhdm9pZCBydW5uaW5nIG91 dCBvZiBkaXNrIHNwYWNlIChieSBkZWxldGluZyBvbGRlciBjb21taXRzKS4gU2luY2UgdGhl IElybWluIGZpbGVzeXN0ZW0gaXMgdmVyc2lvbmVkIGJ5IE1lcmtsZSBoYXNoZXMsIG9uZSBj YW4gaW1hZ2luZSBkZXBsb3lpbmcgcmVwcm9kdWNpYmxlIHVuaWtlcm5lbHMgb24gcmVwcm9k dWNpYmxlIGZpbGVzeXN0ZW0gc3RhdGVzIQ0KDQoNCk1ha2VzIG1lIGN1cmlvdXMgd2hhdCB5 b3UgdHJ5IHRvIGFjaGlldmUgd2l0aCBpdC4gQSAicmVwcm9kdWNpYmxlIA0KZmlsZXN5c3Rl bSIgbWVhbnMgd2hhdCBleGFjdGx5PyBXaGF0IGlzIHRoZSBkaWZmZXJlbmNlIHRvIGEgZ2l0 IA0KcmVwb3NpdG9yeSBvZiB5b3VyICJpcm1pbi1wYWNrIiAoc28gd2h5IHVzZSBpcm1pbi9u b3RhZnMgaW5zdGVhZCBvZiBhIA0KZ2l0IHJlcG9zaXRvcnkpPyBIb3cgZG8geW91IGdldCBh IHJvYnVzdCBmaWxlIHN5c3RlbSB3aXRob3V0ICJmc3luYyI/IA0KV2hhdCBpcyB0aGUgcGVy Zm9ybWFuY2Ugb2Ygbm90YWZzIGNvbXBhcmVkIHRvIGEgZ2l0IHJlcG9zaXRvcnk/DQoNCg0K DQpCZXN0LA0KDQpIYW5uZXMNCg== From mirageos-devel-bounces@lists.xenproject.org Tue Dec 19 15:02:16 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 19 Dec 2023 15:02:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.656956.1025486 (Exim 4.92) (envelope-from ) id 1rFbbj-0002zd-SP; Tue, 19 Dec 2023 15:02:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 656956.1025486; Tue, 19 Dec 2023 15:02:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFbbj-0002zW-P6; Tue, 19 Dec 2023 15:02:07 +0000 Received: by outflank-mailman (input) for mailman id 656956; Tue, 19 Dec 2023 15:02:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFbbi-0002zQ-5S for mirageos-devel@lists.xenproject.org; Tue, 19 Dec 2023 15:02:06 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 90bdd32b-9e7f-11ee-9b0f-b553b5be7939; Tue, 19 Dec 2023 16:02:02 +0100 (CET) Received: from [192.168.42.12] (i59F5CAF8.versanet.de [89.245.202.248]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id 3F23E203E3 for ; Tue, 19 Dec 2023 16:02:01 +0100 (CET) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: 90bdd32b-9e7f-11ee-9b0f-b553b5be7939 Message-ID: <545624c1-0115-5d7c-ec87-6949240c1b10@mehnert.org> Date: Tue, 19 Dec 2023 16:02:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-US To: mirageos-devel@lists.xenproject.org References: <384B75D1-6B7C-4946-81D9-BE5E0D87A3E2@gazagnaire.org> From: Hannes Mehnert Subject: Re: MirageOS and my recent involvement In-Reply-To: <384B75D1-6B7C-4946-81D9-BE5E0D87A3E2@gazagnaire.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 17/12/2023 11:33, Thomas Gazagnaire wrote: >> Some repositories in the mirage organization are suffering from bitrot, and/or lack of cleanups or reviews (such as the ocaml-solo5 PR waiting since a long time for proper reviews that would enable to use OCaml 5) -- my personal experience with OCaml 5 from a resource perspective is not very good, that's why I don't really care about that too much (and am happy that 4.14 is under long-term support). > > Do you have some reproducible case for the OCaml5 resource usage? 5.1.1 is shipping with a few improvements and it would be great to see if that fixes what you have observed. Short answer is no. Longer answer is that I've no incentive to move to OCaml 5.1.1. There's still no memtrace/statmemprof, thus debugging any memory issues is tedious. "Reproducible cases" - well, I observed for example a dream webserver (builder-web), builder, albatross -- all over a week of time (graphing memory usage, and CPU usage) - and when using OCaml 5, they used nearly double the amount of memory. Since then, I put an upper bound on ocaml < 5 into the opam files that are used for building their reproducible binary packages. So, these cases are reproducible by deploying them as real systems, and looking at them over time. Best, Hannes From mirageos-devel-bounces@lists.xenproject.org Wed Dec 20 16:42:06 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 20 Dec 2023 16:42:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.658191.1027278 (Exim 4.92) (envelope-from ) id 1rFzdr-0008R5-Do; Wed, 20 Dec 2023 16:41:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 658191.1027278; Wed, 20 Dec 2023 16:41:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFzdr-0008Qy-Af; Wed, 20 Dec 2023 16:41:55 +0000 Received: by outflank-mailman (input) for mailman id 658191; Wed, 20 Dec 2023 16:41:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFzdp-0008Qq-Jp for mirageos-devel@lists.xenproject.org; Wed, 20 Dec 2023 16:41:53 +0000 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ac5b979c-9f56-11ee-9b0f-b553b5be7939; Wed, 20 Dec 2023 17:41:50 +0100 (CET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 723E9E0004 for ; Wed, 20 Dec 2023 16:41:49 +0000 (UTC) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: ac5b979c-9f56-11ee-9b0f-b553b5be7939 From: Thomas Gazagnaire Content-Type: multipart/alternative; boundary="Apple-Mail=_879FAA94-797A-459C-9DDB-49331D1B05AE" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: Updates on Tarides Plans with MirageOS - Request for Feedback Date: Wed, 20 Dec 2023 17:41:39 +0100 References: To: mirageos-devel In-Reply-To: Message-Id: <6EEFFF85-25B7-4290-B256-89C00BF4BE66@gazagnaire.org> X-Mailer: Apple Mail (2.3774.200.91.1.1) X-GND-Sasl: thomas@gazagnaire.org --Apple-Mail=_879FAA94-797A-459C-9DDB-49331D1B05AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for your answers. I=E2=80=99m trying to give more details bellow. > I am a bit worried, since the mirage3 -> mirage4 change (change of = compilation strategy) had quite some impact on our reproducible build = system (https://builds.robur.coop, https://github.com/robur-coop/orb) - = now when opam-monorepo will be deprecated in favour of "dune pkg", my = worry is that there's again quite some work needed on our end. It turns = out, only mirage 4.2 was in a shape where we could use it for = reproducible builds. > But I'm sure you're aware of the issues that we encountered and pushed = upstream to e.g. mirage, and how all the bits = (mirage/opam/orb/opam-monorepo) currently fit together, and how "dune = pkg" will fit in. This is a legitimate worry. To avoid falling in the same traps a for the = opam-monorepo situation: - the feature is designed by the Dune maintainers, with support and = contributions from the opam-monorepo and opam maintainers. So the = maintenance story is much clearer and upstream are willing to do the = changes to make this work properly. - the feature is expected to be used by all OCaml users (not just the = Mirage and a few others). So there is a better incentive to make it = succeed than opam-monorepo. - the goal is to teach Dune how to compile any opam package, even it it = doesn=E2=80=99t use Dune (so no need for an overlay and vendoring = anymore) I expect the situation to probably be broken a little bit in the first = alpha as it=E2=80=99s a major change but to be improved quickly as users = start to pick it up and to be maintained consistently over-time as = it=E2=80=99s a first-class feature in OCaml Platform UX. You can browse the =E2=80=9Cpackage management=E2=80=9D tag on GH to see = progress: = https://github.com/ocaml/dune/issues?q=3Dlabel%3A%22package+management%22.= There is a lot going on, but here a few highlights: - how Dune is planning to build opam packages (with support for = x-compilation via Dune workspace, like opam-monorepo does): = https://github.com/ocaml/dune/issues/7096 - how all the opam features are integrated into Dune build plans: = https://github.com/ocaml/dune/issues/8096 - Keep the tag/commit of opam-repository remote in the lock files for = reproducibility: https://github.com/ocaml/dune/issues/8463 - How to make the Dune rules for building opam packages reproducible: = https://github.com/ocaml/dune/issues/8240 I don=E2=80=99t think the integration with Orb has been discussed in = details at this stage - however `dune pkg` uses the opam library and = already need to have precise dependencies specification to make caching = of build rules work reliably. So I suspect that won=E2=80=99t be too = difficult; but yes I realize this means planning work to update orb. = I=E2=80=99ve opened https://github.com/ocaml/dune/issues/9548 to discuss = the scope of the work. >> Regarding mirage/functoria, my general feeling is that while the CLI = tool was initially valuable for gathering an ecosystem of libraries, = nowadays, it is less clear if this is still required. Right now, most of = the tool's complexity is handling the installation of packages needed = for a specific target/combination of devices. This will no longer be = needed if the build system can do this instead. Ideally, any OCaml = application (following a few design principles) could be compiled to a = unikernel simply using Dune, as envisioned by the [Workflow = W12](https://ocaml.org/docs/platform-roadmap#w12-compile-to-mirageos) of = the OCaml Roadmap. However, there is no existing design on how this = should work at this stage. So, before starting this, is that the right = direction for the mirage tool? > My experience with Mirage - the tool - is that it does various things = at once: > - figuring out dependencies and requirements of MirageOS devices, = putting them into a boot order (what is generated as main.ml) > - selecting target-specific implementations (still, I thought someone = wanted to revise this to use "dune variants", but haven't seen any = demonstration thereof) > - command line arguments at configure and boot time (here, there has = been various recent discussions, = https://github.com/mirage/mirage/issues/1422, and a huge amount of = reshuffling and implementation work by yourself -- which unfortunately = doesn't seem to be ready yet (merged onto the main branch, but take a = look at the regressions https://github.com/mirage/mirage/issues/1479 = https://github.com/mirage/mirage/issues/1483), and looks slightly = abandoned > - cross-compiling/linking (using ocaml-solo5 with solo5 = cross-compilation shell-script, and opam-monorepo to construct a = monorepo) >=20 > Out of these 4 items, I'm not sure what "dune -x mirage" will attempt = to solve. My goal is to make mirage - the tool - less smart about what = it attempts to achieve, but I don't think that moving these bits into = dune would be beneficial. Good list :-) 1. I agree we need some kind of metadata here. But I=E2=80=99m not sure = having a complex eDSL is the right approach anymore. We might as well = extract the metadata (what packages exists, what devices do they define, = what parameters do they take) and a more simple way to combine then. = I=E2=80=99m not convinced we need to expose this to end-users in the way = it is today. 2. Dune variant was indeed supposed to fix this - it has a few = limitations (the main one being the removal of x-modules inlining) but = my hope is that it is the way to do multi-platform development in OCaml = in the longer term. 3. I am not convinced that exposing a complex CLI is the way to go. = I=E2=80=99d be in favor of letting people write configuration files (so = you can store them in your repo), either using a standard format (did I = hear yaml :p) or just put this in your dune file. But this is long-term. = In the short term I plan to unblock my patches by finding some time over = Christmas to work on this. Longer-term, we probably need a combination = of macros/MetaOCaml instead of re-implementing our own magic. Would be = nice to explore the design space a bit more here. 4. This is exactly what `dune -x mirage` will replace initially (with = maybe some integration for target/device parameters in 3) >> ### Targets >> The principal target backend for MirageOS nowadays is Solo5. This is = a solid backend, which has been audited and optimised for security. It = is also relatively simple to add new devices given the by-design = low-complexity approach of its device model. However, while solo5 is = today the most secure unikernel "runtime", I also feel it has issues = hindering potential changes. For one, it is slow -- the device model is = not meant for high-speed I/O, > There have been contributions and attempts to implement that - see = https://github.com/solo5-netmap/solo5/tree/netmap as example. I don't = quite get the "has issues hindering potential changes=E2=80=9D. I=E2=80=99ve listed a few of these issues later (slow I/O, lack of = maintenance). I don=E2=80=99t say fixing this is not possible, I=E2=80=99m= just saying that I feel we don=E2=80=99t have the maintenance momentum = to do this right now. But I=E2=80=99m happy to be proven wrong :-)=20 Regarding Netmap and other Solo5 extensions, I=E2=80=99m interested to = hear what went ok and what went wrong? Why wasn=E2=80=99t this merged? = Takayuki - do you think the Netmap approach was the right way to go = there? How does Netmap perform in a virtualized environment? I think = people also discussed using a DPDK-eBPF based IO at one point. How does = it fit? (I haven=E2=80=99t followed closely what was happening in this = space). A good topic to discuss during our next Mirage call :-) >> and there is no support for SMP; for most use cases, it is not an = issue, but for others we are looking at, it can be. > There has been in the early days some fork from solo5 called = hermitcore that added SMP. I'm curious why you didn't pick that up for = your mail. I didn=E2=80=99t know HermitCore was based on solo5? Nowadays they = compile Rust to Unikraft. >> The other one is that the device model is very simple (for good = reasons) and challenging to extend to new devices (see below for more = detail). In an ideal world, this could be fixable, but there are also = very few courageous active maintainers, so any changes - like moving to = OCaml5 - are complex to make. > Hmm, one thing clearly is solo5 lacking maintainers and contributors. = The other thing is that ocaml-solo5 with its minimal (no)libc surely = needs adaption for the OCaml5 runtime rewrite (see the PR that has been = around for ages). Now, when you switch to unikraft, I'm not entirely = sure what your tradeoff is? Does unikraft support SMP? Did you evaluate = in detail the trusted code base differences between solo5 and unikraft? There are two timeline here. On the short-term: I fully agree we should = start by moving solo5 to single-core OCaml5 - that PR has been lingering = for too long. I=E2=80=99ll try to see if some people familiar with the = OCaml 5 runtime could review this early next year. And on the medium/longer term, I would like to explore alternative = options to solo5 (and maybe come back to solo5 if the options are not = great). So far Unikraft has demonstrated a nice momentum, with lots of = maintainers (and lots of quality contributions). Wealso have funding to = explore the integration with the unikraft team (the Grant we got = accepted was in collaboration with UPB where Unikfraft is developed). = And yes, there is support for SMP (this is pretty recent, so unclear how = stable this is) - for instance there is work happening here: = https://github.com/unikraft/lib-pthread-embedded I haven=E2=80=99t looked at their codebase directly yet, but I=E2=80=99ve = heard lots of good comments regarding the general quality and robustness = of their C code. However I=E2=80=99ve also heard that their current = focus is on portability and performance. The security roadmap is = progressing = (https://unikraft.org/docs/concepts/security#unikraft-security-features = / https://github.com/orgs/unikraft/projects/32/views/1) but again = unclear what is the ETA and quality. I would expect this to be part of = the evaluation if Unikraft is a good fit or not for Mirage. >> ### Devices and Libraries >> There are three areas that we would like to focus on (or continue to = focus on) in the next couple of years. >> First, we still believe there are better abstractions for storing = data than POSIX. Hence, we are continuing to develop and improve Irmin. = We are currently porting `irmin-pack` to MirageOS (the backend of Irmin = used by the Tezos blockchain to store its ledger history) via the = [Notafs](https://github.com/tarides/notafs) project. Notafs is a pseudo = filesystem for Mirage block devices. It can handle a small number of = large files. While the limited number of filenames is unsatisfying for = general usage, it can be used to run the irmin-pack backend of Irmin, = which only requires a dozen huge files. By running Irmin, one gets for = free a filesystem-on-steroid for MirageOS: it supports an arbitrarily = large number of filenames; is optimised for small and large file = contents; performs file deduplication; includes a git-like history with = branching and merging, ... and it even provides a garbage collector to = avoid running out of disk space (by deleting older commits). Since the = Irmin filesystem is versioned by Merkle hashes, one can imagine = deploying reproducible unikernels on reproducible filesystem states! > Makes me curious what you try to achieve with it. A "reproducible = filesystem" means what exactly? What is the difference to a git = repository of your "irmin-pack" (so why use irmin/notafs instead of a = git repository)? How do you get a robust file system without "fsync"? = What is the performance of notafs compared to a git repository? Irmin and Git have the same general data model - they both use a Merkel = graph of objects. There are a few differences though: - Git support SHA1 only (for now - although ocaml-git is functorised = over the hash implementation, if you want to interface with actual Git = repositories - like storing you data on GitHub - you don=E2=80=99t have = much choice). Irmin-pack can use whatever hashes - Tezos uses BLAKE2b = for instance. - Git has limited support for large directories as he space and speed = performance of traversing a directory is linear in the number of = files/sub-directories. This is problematic when you start updating files = in these large subdirectories, as every write will duplicate the node = and cause excessive space usage. Irmin-pack use something that looks = like (deterministic and well distributed) inodes to represent = directories so the space and speed complexity is logarithmic.=20 - Both solutions have limited support for large files. But if you are = storing a large file in Git you are screwed. While with Irmin you can = switch to an alternate way to represent large blobs (for instance using = a rope-like data structure) - The storage strategy is also a bit different: - Git has an interesting storage model: it has a =E2=80=9Cminor = heap=E2=80=9D (with recent objects that are stored uncompressed) and a = =E2=80=9Cmajor heap=E2=80=9D (with optimized pack files that stores = compressed objects). Running a GC will compact the minor heap into a new = pack file. This is a =E2=80=9Cstop-the-world=E2=80=9D operation and so = you can=E2=80=99t read or write new objects concurrently. The GC can = also trigger a repack, that will compact the major heap (and unpack / = repack the existing pack files by removing unreachable objects). This is = again =E2=80=9Cstop-the-world=E2=80=9D and very costly I/O operation. - Irmin-pack has just one heap with a concurrent GC - you can = continue to read and write efficiently in the store while the GC is = running in the background, and the GC is efficient enough that it is = actually not noticeable. This works very well if your history is mostly = linear and if you want to keep the last X commits and discard the rest. = If you want a different GC strategy, this won=E2=80=99t work so well. - The in-memory caching story is also different: - Git (and ocaml-git) has no notion of read and write cache - every = operation directly goes through the store. You can decide to have an = in-memory or on-disk Git store, but doing a bit of both is complicated. - Irmin has an in-memory cache (Irmin.Tree) that lazily read objects = and cache write object until the next commit. This is a great way to = batch write operations to avoid writing garbage on disk. - tangiently related, but we have ongoing experiments to parallelized = and have a direct-style irmin-pack using eio that are quite promising as = that data model scales very well (I suspect that=E2=80=99s also the case = for Git, but concurrent/parallel writes on the file system for the = =E2=80=9Cminor heap=E2=80=9D might not scale as well) =E2=80=94 we=E2=80=99= re planning to talk more about this early next year when = https://github.com/mirage/irmin/tree/eio got merged. And I=E2=80=99ll let the notafs authors answer about the performance = where they are back from holidays :-) Regarding fsync: - Irmin-pack always store consistent data on disk - so if you computer = crashes in the middle of some operations, you are supposed to be able to = restart =E2=80=94 with maybe an outdated version of your file but at = least a consistent one. So at least we should have consistency (if not, = that=E2=80=99s a bug). - Durability is harder as it=E2=80=99s pretty unclear what is the actual = semantics for block device synchronization - and I don=E2=80=99t think = Mirage (and virtio and the Linux kernel(s)) implement this semantic = consistently. Maybe that=E2=80=99s a good time to resurrect the write = barrier/durable patches in = https://github.com/mirage/mirage-block/compare/main...g2p:mirage-block:bar= rier-and-discard but we need to have an idea on how all the existing = (virtual) block device implementation are supposed to behave? Happy to = hear what are people opinions here. Best, Thomas= --Apple-Mail=_879FAA94-797A-459C-9DDB-49331D1B05AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Thanks for your answers. = I=E2=80=99m trying to give more details bellow.

I am a bit worried, since the mirage3 -> mirage4 = change (change of compilation strategy) had quite some impact on our = reproducible build system (https://builds.robur.coop, = https://github.com/robur-coop/orb) - now when opam-monorepo will be = deprecated in favour of "dune pkg", my worry is that there's again quite = some work needed on our end. It turns out, only mirage 4.2 was in a = shape where we could use it for reproducible = builds.

But I'm sure you're aware of the issues that we = encountered and pushed upstream to e.g. mirage, and how all the bits = (mirage/opam/orb/opam-monorepo) currently fit together, and how "dune = pkg" will fit in.

This is a = legitimate worry. To avoid falling in the same traps a for the = opam-monorepo situation:
- the feature is designed by the Dune maintainers, = with support and contributions from the opam-monorepo and opam = maintainers. So the maintenance story is much clearer and upstream are = willing to do the changes to make this work properly.
- the feature = is expected to be used by all OCaml users (not just the Mirage and a few = others). So there is a better incentive to make it succeed than = opam-monorepo.
- the goal is to teach Dune how to compile any opam = package, even it it doesn=E2=80=99t use Dune (so no need for an overlay = and vendoring anymore)

I expect the situation to  probably be broken = a little bit in the first alpha as it=E2=80=99s a major change but to be = improved quickly as users start to pick it up and to be maintained = consistently over-time as it=E2=80=99s a first-class feature in OCaml = Platform UX.

You can browse the =E2=80=9Cpackage management=E2=80= =9D tag on GH to see = progress: https://github.com/ocaml/dune/issues?q=3Dlabel%3A%22package= +management%22. There is a lot going on, but here a few = highlights:
- how Dune is planning to build opam packages = (with support for x-compilation via Dune workspace, like opam-monorepo = does): https://github.com/ocaml/dune/issues/7096
- how = all the opam features are integrated into Dune build = plans: https://github.com/ocaml/dune/issues/8096
- Keep = the tag/commit of opam-repository remote in the lock files for = reproducibility: https://github.com/ocaml/dune/issues/8463
- = How to make the Dune rules for building opam packages = reproducible: https://github.com/ocaml/dune/issues/8240
I don=E2=80=99t think the integration with Orb has been = discussed in details at this stage - however `dune pkg` uses the opam = library and already need to have precise dependencies specification to = make caching of build rules work reliably. So I suspect that won=E2=80=99t= be too difficult; but yes I realize this means planning work to update = orb. I=E2=80=99ve = opened https://github.com/ocaml/dune/issues/9548 to = discuss the scope of the = work.

Regarding = mirage/functoria, my general feeling is that while the CLI tool was = initially valuable for gathering an ecosystem of libraries, nowadays, it = is less clear if this is still required. Right now, most of the tool's = complexity is handling the installation of packages needed for a = specific target/combination of devices. This will no longer be needed if = the build system can do this instead. Ideally, any OCaml application = (following a few design principles) could be compiled to a unikernel = simply using Dune, as envisioned by the [Workflow = W12](https://ocaml.org/docs/platform-roadmap#w12-compile-to-mirageos) of = the OCaml Roadmap. However, there is no existing design on how this = should work at this stage. So, before starting this, is that the right = direction for the mirage tool?
My experience with Mirage - = the tool - is that it does various things at once:
- figuring out = dependencies and requirements of MirageOS devices, putting them into a = boot order (what is generated as main.ml)
- selecting target-specific = implementations (still, I thought someone wanted to revise this to use = "dune variants", but haven't seen any demonstration thereof)
- = command line arguments at configure and boot time (here, there has been = various recent discussions, = https://github.com/mirage/mirage/issues/1422, and a huge amount of = reshuffling and implementation work by yourself -- which unfortunately = doesn't seem to be ready yet (merged onto the main branch, but take a = look at the regressions https://github.com/mirage/mirage/issues/1479 = https://github.com/mirage/mirage/issues/1483), and looks slightly = abandoned
- cross-compiling/linking (using ocaml-solo5 with solo5 = cross-compilation shell-script, and opam-monorepo to construct a = monorepo)

Out of these 4 items, I'm not sure what "dune -x = mirage" will attempt to solve. My goal is to make mirage - the tool - = less smart about what it attempts to achieve, but I don't think that = moving these bits into dune would be = beneficial.

Good list = :-)
1. I agree we need some kind of metadata here. But I=E2=80=99m not = sure having a complex eDSL is the right approach anymore. We might as = well extract the metadata (what packages exists, what devices do they = define, what parameters do they take) and a more simple way to combine = then. I=E2=80=99m not convinced we need to expose this to end-users in = the way it is today.
2. Dune variant was indeed supposed to fix this - = it has a few limitations (the main one being the removal of x-modules = inlining) but my hope is that it is the way to do multi-platform = development in OCaml in the longer term.
3. I am not convinced that exposing = a complex CLI is the way to go. I=E2=80=99d be in favor of letting = people write configuration files (so you can store them in your repo), = either using a standard format (did I hear yaml :p) or just put this in = your dune file. But this is long-term. In the short term I plan to = unblock my patches by finding some time over Christmas to work on this. = Longer-term, we probably need a combination of macros/MetaOCaml instead = of re-implementing our own magic. Would be nice to explore the design = space a bit more here.
4. This is exactly what `dune -x mirage` will = replace initially (with maybe some integration for target/device = parameters in 3)

### Targets
The = principal target backend for MirageOS nowadays is Solo5. This is a solid = backend, which has been audited and optimised for security. It is also = relatively simple to add new devices given the by-design low-complexity = approach of its device model. However, while solo5 is today the most = secure unikernel "runtime", I also feel it has issues hindering = potential changes. For one, it is slow -- the device model is not meant = for high-speed I/O,
There have been contributions and = attempts to implement that - see = https://github.com/solo5-netmap/solo5/tree/netmap as example. I don't = quite get the "has issues hindering potential = changes=E2=80=9D.

I=E2=80=99ve = listed a few of these issues later (slow I/O, lack of maintenance). I = don=E2=80=99t say fixing this is not possible, I=E2=80=99m just saying = that I feel we don=E2=80=99t have the maintenance momentum to do this = right now. But I=E2=80=99m happy to be proven wrong = :-) 

Regarding Netmap and other Solo5 = extensions, I=E2=80=99m interested to hear what went ok and what went = wrong? Why wasn=E2=80=99t this merged? Takayuki - do you think the = Netmap approach was the right way to go there? How does Netmap perform = in a virtualized environment? I think people also discussed using a = DPDK-eBPF based IO at one point. How does it fit? (I haven=E2=80=99t = followed closely what was happening in this space). A good topic to = discuss during our next Mirage call = :-)

and there is no = support for SMP; for most use cases, it is not an issue, but for others = we are looking at, it can be.
There has been in the early = days some fork from solo5 called hermitcore that added SMP. I'm curious = why you didn't pick that up for your = mail.

I didn=E2=80=99t = know HermitCore was based on solo5? Nowadays they compile Rust to = Unikraft.

The other one is that the device model is very simple (for = good reasons) and challenging to extend to new devices (see below for = more detail). In an ideal world, this could be fixable, but there are = also very few courageous active maintainers, so any changes - like = moving to OCaml5 - are complex to make.
Hmm, one thing = clearly is solo5 lacking maintainers and contributors. The other thing = is that ocaml-solo5 with its minimal (no)libc surely needs adaption for = the OCaml5 runtime rewrite (see the PR that has been around for ages). = Now, when you switch to unikraft, I'm not entirely sure what your = tradeoff is? Does unikraft support SMP? Did you evaluate in detail the = trusted code base differences between solo5 and = unikraft?

There are two = timeline here. On the short-term: I fully agree we should start by = moving solo5 to single-core OCaml5 - that PR has been lingering for too = long. I=E2=80=99ll try to see if some people familiar with the OCaml 5 = runtime could review this early next year.

And = on the medium/longer term, I would like to explore alternative options = to solo5 (and maybe come back to solo5 if the options are not = great).

So far Unikraft has demonstrated a nice = momentum, with lots of maintainers (and lots of quality contributions). = Wealso have funding to explore the integration with the unikraft team = (the Grant we got accepted was in collaboration with UPB where Unikfraft = is developed). And yes, there is support for SMP (this is pretty recent, = so unclear how stable this is) - for instance there is work happening = here: = https://github.com/unikraft/lib-pthread-embedded

= I haven=E2=80=99t looked at their codebase directly yet, but I=E2=80=99ve = heard lots of good comments regarding the general quality and robustness = of their C code. However I=E2=80=99ve also heard that their current = focus is on portability and performance. The security roadmap is = progressing = (https://unikraft.org/docs/concepts/security#unikraft-security-features = /  https://github.com/orgs/unikraft/projects/32/views/1) but again = unclear what is the ETA and quality. I would expect this to be part of = the evaluation if Unikraft is a good fit or not for = Mirage.

### Devices and Libraries
There are three areas that we = would like to focus on (or continue to focus on) in the next couple of = years.
First, we still believe there are better abstractions for = storing data than POSIX. Hence, we are continuing to develop and improve = Irmin. We are currently porting `irmin-pack` to MirageOS (the backend of = Irmin used by the Tezos blockchain to store its ledger history) via the = [Notafs](https://github.com/tarides/notafs) project. Notafs is a pseudo = filesystem for Mirage block devices. It can handle a small number of = large files. While the limited number of filenames is unsatisfying for = general usage, it can be used to run the irmin-pack backend of Irmin, = which only requires a dozen huge files. By running Irmin, one gets for = free a filesystem-on-steroid for MirageOS: it supports an arbitrarily = large number of filenames; is optimised for small and large file = contents; performs file deduplication; includes a git-like history with = branching and merging, ... and it even provides a garbage collector to = avoid running out of disk space (by deleting older commits). Since the = Irmin filesystem is versioned by Merkle hashes, one can imagine = deploying reproducible unikernels on reproducible filesystem = states!
Makes me curious what you try to achieve with it. A = "reproducible filesystem" means what exactly? What is the difference to = a git repository of your "irmin-pack" (so why use irmin/notafs instead = of a git repository)? How do you get a robust file system without = "fsync"? What is the performance of notafs compared to a git = repository?

Irmin and Git = have the same general data model - they both use a Merkel graph of = objects. There are a few differences though:

- = Git support SHA1 only (for now - although ocaml-git is functorised over = the hash implementation, if you want to interface with actual Git = repositories - like storing you data on GitHub - you don=E2=80=99t have = much choice). Irmin-pack can use whatever hashes - Tezos uses BLAKE2b = for instance.
- Git has limited support for large directories = as he space and speed performance of traversing a directory is linear in = the number of files/sub-directories. This is problematic when you start = updating files in these large subdirectories, as every write will = duplicate the node and cause excessive space usage. Irmin-pack use = something that looks like (deterministic and well distributed) inodes to = represent directories so the space and speed complexity is = logarithmic. 
- Both solutions have limited support for = large files. But if you are storing a large file in Git you are screwed. = While with Irmin you can switch to an alternate way to represent large = blobs (for instance using a rope-like data structure)
- The = storage strategy is also a bit different:
    - Git = has an interesting storage model: it has a =E2=80=9Cminor heap=E2=80=9D = (with recent objects that are stored uncompressed) and a =E2=80=9Cmajor = heap=E2=80=9D (with optimized pack files that stores compressed = objects). Running a GC will compact the minor heap into a new pack file. = This is a =E2=80=9Cstop-the-world=E2=80=9D operation and so you can=E2=80=99= t read or write new objects concurrently. The GC can also trigger a = repack, that will compact the major heap (and unpack / repack the = existing pack files by removing unreachable objects). This is again = =E2=80=9Cstop-the-world=E2=80=9D and very costly I/O = operation.
    - Irmin-pack has just one heap with a = concurrent GC - you can continue to read and write efficiently in the = store while the GC is running in the background, and the GC is efficient = enough that it is actually not noticeable. This works very well if your = history is mostly linear and if you want to keep the last X commits and = discard the rest. If you want a different GC strategy, this won=E2=80=99t = work so well.
- The in-memory caching story is also = different:
   - Git (and ocaml-git) has no notion of = read and write cache - every operation directly goes through the store. = You can decide to have an in-memory or on-disk Git store, but doing a = bit of both is complicated.
   - Irmin has an = in-memory cache (Irmin.Tree) that lazily read objects and cache write = object until the next commit. This is a great way to batch write = operations to avoid writing garbage on disk.
- tangiently = related, but we have ongoing experiments to parallelized and have a = direct-style irmin-pack using eio that are quite promising as that data = model scales very well (I suspect that=E2=80=99s also the case for Git, = but concurrent/parallel writes on the file system for the =E2=80=9Cminor = heap=E2=80=9D might not scale as well) =E2=80=94 we=E2=80=99re planning = to talk more about this early next year = when https://github.com/mirage/irmin/tree/eio got = merged.

And I=E2=80=99ll let the notafs = authors answer about the performance where they are back from holidays = :-)

Regarding fsync:
- Irmin-pack = always store consistent data on disk - so if you computer crashes in the = middle of some operations, you are supposed to be able to restart =E2=80=94= with maybe an outdated version of your file but at least a consistent = one. So at least we should have consistency (if not, that=E2=80=99s a = bug).
- Durability is harder as it=E2=80=99s pretty unclear = what is the actual semantics for block device synchronization - and I = don=E2=80=99t think Mirage (and virtio and the Linux kernel(s)) = implement this semantic consistently. Maybe that=E2=80=99s a good time = to resurrect the write barrier/durable patches in = https://github.com/mirage/mirage-block/compare/main...g2p:mirage-block:bar= rier-and-discard but we need to have an idea on how all the existing = (virtual) block device implementation are supposed to behave? Happy to = hear what are people opinions = here.

Best,
Thomas
= --Apple-Mail=_879FAA94-797A-459C-9DDB-49331D1B05AE-- From mirageos-devel-bounces@lists.xenproject.org Wed Dec 20 16:43:15 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 20 Dec 2023 16:43:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.658195.1027283 (Exim 4.92) (envelope-from ) id 1rFzf7-0000JI-L9; Wed, 20 Dec 2023 16:43:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 658195.1027283; Wed, 20 Dec 2023 16:43:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFzf7-0000JB-HW; Wed, 20 Dec 2023 16:43:13 +0000 Received: by outflank-mailman (input) for mailman id 658195; Wed, 20 Dec 2023 16:43:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rFzf5-0000J2-Ku for mirageos-devel@lists.xenproject.org; Wed, 20 Dec 2023 16:43:11 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dbe87dea-9f56-11ee-98eb-6d05b1d4d9a1; Wed, 20 Dec 2023 17:43:10 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-40c38de1ee4so59579205e9.0 for ; Wed, 20 Dec 2023 08:43:10 -0800 (PST) Received: from smtpclient.apple ([2a01:e34:eca6:2fe0:dd80:66a8:b827:3358]) by smtp.gmail.com with ESMTPSA id g15-20020a05600c4ecf00b0040b36ad5413sm170076wmq.46.2023.12.20.08.43.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2023 08:43:08 -0800 (PST) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: dbe87dea-9f56-11ee-98eb-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703090589; x=1703695389; darn=lists.xenproject.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/Lq5wZO1Oq8gqRfIxORGBLv1srSk5bvr/IRkSlczCQU=; b=AH1CX88YRXNhS5kmk9j5gcDhfexmkrCbJEcRKo+LpttwgfxBdlR5yK2abS0gxWgjYr cMo9bWlrNuwcHu85yIu8X8Z44H8vJ5lmxSuiOIDSRSEkbCNBT3xFeyS1P1KOUBsB+OIH J8P2AWZToEGOP7emk2YytJgKtpHIiAgP/c6EwPDK6gDEMEAoPSvwcbR7YGKvhYpqLqjG E3QxmaDZb72Zz0vSlZK7m15hrAfYvPQwfj9VXs+Ax3a940TJqMV19uVmmWrFlfyLhvru DxPrqc3+ESctNhQaZdNjW/IJbm0wFjiP8ImfM9Lo9Tzgyq8ix/BtFy/dCae0zQ/7L6Gd k9lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703090589; x=1703695389; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/Lq5wZO1Oq8gqRfIxORGBLv1srSk5bvr/IRkSlczCQU=; b=hrqs/uo/oomoQBsqF6vOwqk7FdV1d2mvgv7hEraUXE3QtHUL5BqjjdQjrfmLUR7O9g 2if2BaKaIfySMTVUDylFI20KKfrVWk2VXG9Mnbh1hKV7Xb2I1nN4igtEi51HhYGTdgSP KCVucsbbhen+5cWEbWTsJucwyTDCAczAiQYIpoGPTGOE2lEJCKDIQJqXeOUoW9jxWP0e R+P/a2ipRB+4JS/os8s1/E7DqxrtvKv6axhGsbuSYrIVoCCDepD/hR01wbAC6ZkoVmFc wKztPjzXIfpxIPqEM151e79RT5Usk/HoWLNAHjWvhfFxrItTqwyUuI8LQyQzSeLY51wL WsNw== X-Gm-Message-State: AOJu0Ywmzv6iN4iN9gjZt0fsZ8QQK5oThT7HPQOCP/gZW8vcP5t+Ed2D O70b79hRk6DBgSJmdTfPSq4= X-Google-Smtp-Source: AGHT+IGXMVNQ+oi1zrw+dmzxbNg12loCMkeLR8sKCovDTRBvuvwQgzH3wJJEnrkLo8e2Nu661AWokw== X-Received: by 2002:a05:600c:1e8d:b0:40d:3aff:e067 with SMTP id be13-20020a05600c1e8d00b0040d3affe067mr129379wmb.20.1703090589301; Wed, 20 Dec 2023 08:43:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: Updates on Tarides Plans with MirageOS - Request for Feedback From: Thomas Gazagnaire In-Reply-To: Date: Wed, 20 Dec 2023 17:42:57 +0100 Cc: mirageos-devel@lists.xenproject.org Content-Transfer-Encoding: quoted-printable Message-Id: <488FDEA9-ABA1-423E-852E-598FF8BDE3FB@gmail.com> References: To: Takayuki Imada X-Mailer: Apple Mail (2.3774.200.91.1.1) Dear Takayuki, Many thanks for your response. > I'm interested in some topics below, and happy to be engaged in one or = two of them though I am a weekend hobbyist. :-) >=20 > 1. Solo5 improvement > 2. Unikraft back-end > -> I like the Solo5 philosophy (simple, small, and secured). However = ... the current Solo5 implementation has some problems as you mentioned. > So, having an alternative back-end seems a good way. > 3. MirageOS device APIs (mainly targeting PCIe devices?) > -> I have previously tried "MirageOS + Solo5 hvt + Netmap + 10GbE = with SR-IOV". My experience on that will be helpful to this topic! That=E2=80=99s really appreciated. We will keep you in the loop. What do = you recommend reading to learn more about your experience with Netmap? Best, Thomas > On 2023/12/16 3:18, Thomas Gazagnaire wrote: >> Hello there, >> Over the last year, Tarides has been engaging with partners in the = space sector to adapt MirageOS for use in space environments. Following = participation in Cyber@StationF and initial discussions with Thales = Alenia Space in late 2022, we have begun the development of SpaceOS. = This operating system, leveraging numerous MirageOS components, is = designed to meet the new requirements of multi-mission, multi-user = satellite missions (what people also call "NewSpace"). >> SpaceOS's development has led to Tarides joining a consortium of = academic and commercial entities in the space industry. We have = successfully obtained our first grant (with the [ORCHIDE project, part = of the EU HORIZON CL4-2023-SPACE-01-11 = programme,](https://ec.europa.eu/info/funding-tenders/opportunities/portal= /screen/how-to-participate/org-details/999999999/project/101135595/program= /43108390/details)) and have several others under review. The goal for = SpaceOS is to remain as open-source as possible, aligning with the = MirageOS community's approach to software development (with a few = exceptions in scenarios involving proprietary hardware or software = vendors). >> Hence, Tarides is planning active development work on MirageOS in the = coming years in conjunction with the early development stages of = SpaceOS. We have ambitious plans in mind and are reaching out to the = MirageOS community to gather input and perspectives during this phase. = We welcome your thoughts on this matter, whether these are agreements, = disagreements, or general comments. Please share your feedback on this = mailing list (preferred) or through private communication. >> ### Tooling >> Over the past five years, our efforts have focused on integrating = Mirage-specific tooling into the OCaml Platform. We plan to continue in = this direction. This integration is intended to benefit both Mirage = developers (by reducing the maintenance burden on the core MirageOS = team) and the broader OCaml user base (as they could benefit from = MirageOS workflow -- especially cross-compilation -- in other = situations). >> A significant part of this effort was transitioning from custom = x-compilation runes to using Dune workspace via `opam -monorepo`. This = migration was not always painless (to say the least), but we learned a = few things that are now being applied to the new "package management" = feature of Dune 4. Thus, we plan to continue to work on migrating from = `opam-monorepo` to the `dune pkg` command to ensure it works for = MirageOS users. This new command addresses the limitations identified in = opam-monorepo, especially for packages not built with Dune. An alpha = version is currently available (try `dune pkg` with Dune 3.12), and we = anticipate a complete release in Q1 2024. We really want to ensure this = is a drop-in replacement for Mirage's use of `opam-monorepo`, so we will = work with upstream to ensure that is the case (and so we can deprecate = opam-monorepo in Q2 2024). >> Regarding mirage/functoria, my general feeling is that while the CLI = tool was initially valuable for gathering an ecosystem of libraries, = nowadays, it is less clear if this is still required. Right now, most of = the tool's complexity is handling the installation of packages needed = for a specific target/combination of devices. This will no longer be = needed if the build system can do this instead. Ideally, any OCaml = application (following a few design principles) could be compiled to a = unikernel simply using Dune, as envisioned by the [Workflow = W12](https://ocaml.org/docs/platform-roadmap#w12-compile-to-mirageos) of = the OCaml Roadmap. However, there is no existing design on how this = should work at this stage. So, before starting this, is that the right = direction for the mirage tool? >> ### Targets >> The principal target backend for MirageOS nowadays is Solo5. This is = a solid backend, which has been audited and optimised for security. It = is also relatively simple to add new devices given the by-design = low-complexity approach of its device model. However, while solo5 is = today the most secure unikernel "runtime", I also feel it has issues = hindering potential changes. For one, it is slow -- the device model is = not meant for high-speed I/O, and there is no support for SMP; for most = use cases, it is not an issue, but for others we are looking at, it can = be. The other one is that the device model is very simple (for good = reasons) and challenging to extend to new devices (see below for more = detail). In an ideal world, this could be fixable, but there are also = very few courageous active maintainers, so any changes - like moving to = OCaml5 - are complex to make. >> Thus, we are evaluating alternate backends with the main criteria to = reduce the maintenance cost. Despite its currently limited security = features, one interesting possibility is shifting towards alternative = backends like unikraft. Christiano spent a bit of time looking at this = earlier this year (with a prototype of the OCaml 5 runtime x-compiler to = Unikraft [here](https://github.com/haesbaert/unikraft-ocaml) and a = roadmap for Unikraft security = [here](https://github.com/orgs/unikraft/projects/32/views/1)). Same as = above, we are interested to hear what people think and if anyone is = interested in collaborating with us in porting MirageOS to unikraft (and = contributing to Unikfraft' security roadmap). >> ### Devices and Libraries >> There are three areas that we would like to focus on (or continue to = focus on) in the next couple of years. >> First, we still believe there are better abstractions for storing = data than POSIX. Hence, we are continuing to develop and improve Irmin. = We are currently porting `irmin-pack` to MirageOS (the backend of Irmin = used by the Tezos blockchain to store its ledger history) via the = [Notafs](https://github.com/tarides/notafs) project. Notafs is a pseudo = filesystem for Mirage block devices. It can handle a small number of = large files. While the limited number of filenames is unsatisfying for = general usage, it can be used to run the irmin-pack backend of Irmin, = which only requires a dozen huge files. By running Irmin, one gets for = free a filesystem-on-steroid for MirageOS: it supports an arbitrarily = large number of filenames; is optimised for small and large file = contents; performs file deduplication; includes a git-like history with = branching and merging, ... and it even provides a garbage collector to = avoid running out of disk space (by deleting older commits). Since the = Irmin filesystem is versioned by Merkle hashes, one can imagine = deploying reproducible unikernels on reproducible filesystem states! >> We are also interested in developing new network protocols for space = applications, which could benefit from MirageOS's capabilities. We are = likely targeting the [Space Communication = Protocol](https://en.wikipedia.org/wiki/Space_Communications_Protocol_Spec= ifications), which seems an interesting domain as there does not seem to = exist any open-source, robust implementation of these protocols. >> Finally, the API for devices supported by MirageOS currently maps to = what is available on virtualised infrastructure (i.e. virtual block = devices and virtual network interface). We are interested in = investigating how to extend this, for instance, by reviving the = PCI-passthrough experimentations done a few years ago by Florian, or by = investigating new multi-tenancy device frameworks like = [vAccel](https://vaccel.org/) to (securely?) share GPGPUs or FPGAs = between users. Alternatively, we could use Owl using CPU. We also = welcome anyone with any experience in this area to discuss existing = alternatives. >> ### OS Distribution >> Finally, we are considering options for building a flexible OS = distribution, which might include elements like = [LinuxKit/MirageSDK](https://github.com/linuxkit/linuxkit/tree/master/proj= ects/miragesdk). This concept combines a secure Linux kernel with a = collection of Mirage-based system services and an extended version of = Albatross for orchestration, all customisable based on specific needs. = We are in the early stages of this discussion and welcome any input or = expressions of interest in furthering these ideas. >> Best, >> Thomas From mirageos-devel-bounces@lists.xenproject.org Thu Dec 21 13:59:41 2023 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 21 Dec 2023 13:59:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.658932.1028339 (Exim 4.92) (envelope-from ) id 1rGJaB-0006QI-Ak; Thu, 21 Dec 2023 13:59:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 658932.1028339; Thu, 21 Dec 2023 13:59:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rGJaB-0006QB-7V; Thu, 21 Dec 2023 13:59:27 +0000 Received: by outflank-mailman (input) for mailman id 658932; Thu, 21 Dec 2023 13:59:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rGJa9-0006Q5-Q0 for mirageos-devel@lists.xenproject.org; Thu, 21 Dec 2023 13:59:25 +0000 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [2607:f8b0:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 244df904-a009-11ee-9b0f-b553b5be7939; Thu, 21 Dec 2023 14:59:22 +0100 (CET) Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-6dbb20471b0so585152a34.1 for ; Thu, 21 Dec 2023 05:59:22 -0800 (PST) Received: from [192.168.0.10] (27-140-183-241.rev.home.ne.jp. [27.140.183.241]) by smtp.gmail.com with ESMTPSA id n2-20020a632702000000b005c2967852c5sm1647466pgn.30.2023.12.21.05.59.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Dec 2023 05:59:20 -0800 (PST) X-BeenThere: mirageos-devel@lists.xenproject.org List-Id: Developer list for MirageOS List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mirageos-devel-bounces@lists.xenproject.org Precedence: list Sender: "MirageOS-devel" X-Inumbo-ID: 244df904-a009-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703167161; x=1703771961; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=68HIMdXrPjqFaWkd/g0Y6Pnr8soJnlSNDzkEmxwhICg=; b=krVaGDigieIb7gqwBX8H8bhIYowVsRmGJ3AP2si9scYFBDRBnwTGHmlBOjzIDTfsHT gDRFEEHp9biNHvzcPAQIlz7yIOvYwLMiW/48q98rEDpcNMoSsZ/HQGrb/JFSltPH3kTR Qyanb5I23Kt4WeOQLO5FHi1RKg5RHYcq5CFv3RwmALFN5HX5UlUTsbNwl9vvPuZodT5B mUyi2o5mQWLfsZ7D0iWp5RyZEy/donX6KetXfbUCBTYdSHxcjbvdoixjS8s1yHtwn/j9 +VebD+RO6LotMP1a3vtpkeaWxo7Ju0D0523ymUapE1wZkmQ9OzGIYUccovTHzIecH6ab NHJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703167161; x=1703771961; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=68HIMdXrPjqFaWkd/g0Y6Pnr8soJnlSNDzkEmxwhICg=; b=NiYuhBIwHmDF7GmsmLfBMDDaSQu1GMHBUFfNDtQb4c/sBj7JCExsPq6tgkMEaXt3XE SsZuCyY5irt2OOxjC8G1XaoYZ7wd7b4j9VmfS84fOlbjz5d1HZuXAJaeOUpIS89swZeT Fwzzz7OW70jGB+AM7RwVmAMieVxrkBRxCtaCLu4BTPO72kNBCnMjjSlymEj4HZRl9wMH c6bYuYvqeUiD/g4fzsDpml34hLBq/GU68uCgFzpOlyz73a23zLe68UEIH81Q3llhgnMl fPmU3lt+GCd1Xkgf5tEyc1cU4jsEbzZUOlYN0NqzUi2CUT5nBEinnFzHxKJ50Kcsl5Fm J7Gg== X-Gm-Message-State: AOJu0YwpY9yONqvK5BYJxCF0p/lLBm1xFk5BzImKsuIpZFCq8voZnrFr I9nPoZWSh397OWPPyXzPg/s= X-Google-Smtp-Source: AGHT+IHw7+AoVPYjdwByhLIWnqXZ3WoicPPbj4Z6qe1t0dqpTQo1WH7X7r6Iy2FMcBaXPedTjdQJ+w== X-Received: by 2002:a05:6830:8c:b0:6da:3a7b:4dca with SMTP id a12-20020a056830008c00b006da3a7b4dcamr13473287oto.55.1703167161382; Thu, 21 Dec 2023 05:59:21 -0800 (PST) Message-ID: Date: Thu, 21 Dec 2023 22:59:17 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Updates on Tarides Plans with MirageOS - Request for Feedback Content-Language: en-US To: Thomas Gazagnaire Cc: mirageos-devel@lists.xenproject.org References: <488FDEA9-ABA1-423E-852E-598FF8BDE3FB@gmail.com> From: Takayuki Imada In-Reply-To: <488FDEA9-ABA1-423E-852E-598FF8BDE3FB@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBUaG9tYXMsDQoNCiA+IFRoYXTigJlzIHJlYWxseSBhcHByZWNpYXRlZC4gV2Ugd2ls bCBrZWVwIHlvdSBpbiB0aGUgbG9vcC4gV2hhdCBkbyB5b3UgcmVjb21tZW5kIHJlYWRpbmcg dG8gbGVhcm4gbW9yZSBhYm91dCB5b3VyIGV4cGVyaWVuY2Ugd2l0aCBOZXRtYXA/DQpBIHBl cmZvcm1hbmNlIHNpZGUgcmVwb3J0IGNhbiBiZSBmb3VuZCBhdCBodHRwczovL2RsLmFjbS5v cmcvZG9pLzEwLjExNDUvMzI2NDU2MC4zMjY0NTYxLg0KDQpBcyBmb3IgdGhlIEFQSSBkZXNp Z24sIEkgaGF2ZSB0cmllZCB0byBrZWVwIHRoZSBvcmlnaW5hbCBNaXJhZ2VPUyBhbmQgU29s bzUgaW1wbGVtZW50YXRpb24uDQpXaGF0IEkgaGF2ZSBkb25lIGlzIGp1c3QgcmVwbGFjaW5n ICJ0aGUgb3JpZ2luYWwgdGFwLWJhc2VkIG5ldHdvcmsgaGFuZGxpbmcgaW4gdGhlIFNvbG81 IGh2dCBiaW5kaW5nIGFuZCB0ZW5kZXIiIGJ5ICJhbm90aGVyIG5ldG1hcC1iYXNlZCBvbmUi Lg0KRGVzaWduIGNvbmNlcHQ6DQogICAtIENvbXBhdGlibGUgQVBJcyBpbXBsZW1lbnRlZCB0 byBvcGVyYXRlIHdpdGggdGhlIG9yaWdpbmFsKHVubW9kaWZpZWQpIE5ldGlmIHByb3ZpZGVk IGJ5IG1pcmFnZS1uZXQtc29sbzUNCiAgIC0gSW50ZXJydXB0IGhhbmRsaW5nIGluIHRoZSBT b2xvNSBodnQgdGVuZGVyIHNpZGUgKGNvbmZvcm1pbmcgdGhlIG9yaWdpbmFsIFNvbG81IGh2 dCBJL08gaGFuZGxpbmcpDQogICAtIE5vIGRldmljZSBkcml2ZXJzIGZvciBQQ0llIGFuZCBh IHRhcmdldCBOSUMgaW1wbGVtZW50ZWQgaW4gdGhlIFVuaWtlcm5lbCBzaWRlIChpbiBvcmRl ciB0byByZWR1Y2UgdGhlIGltcGxlbWVudGF0aW9uIGNvc3QpDQoNClRlc3QgY29kZSAoYmlu ZGluZykgOiBodHRwczovL2dpdGh1Yi5jb20vc29sbzUtbmV0bWFwL3NvbG81L2Jsb2IvbmV0 bWFwL2tlcm5lbC91a3ZtL25ldG1hcC5jDQogICAgICAgICAgICh0ZW5kZXIpICA6IGh0dHBz Oi8vZ2l0aHViLmNvbS9zb2xvNS1uZXRtYXAvc29sbzUvYmxvYi9uZXRtYXAvdWt2bS91a3Zt X21vZHVsZV9uZXRtYXAuYw0KDQpLaW5kIHJlZ2FyZHMsDQoNCi0tIA0KVGFrYXl1a2kgSW1h ZGENCg0KDQpPbiAyMDIzLzEyLzIxIDE6NDIsIFRob21hcyBHYXphZ25haXJlIHdyb3RlOg0K PiBEZWFyIFRha2F5dWtpLA0KPiANCj4gTWFueSB0aGFua3MgZm9yIHlvdXIgcmVzcG9uc2Uu DQo+IA0KPj4gSSdtIGludGVyZXN0ZWQgaW4gc29tZSB0b3BpY3MgYmVsb3csIGFuZCBoYXBw eSB0byBiZSBlbmdhZ2VkIGluIG9uZSBvciB0d28gb2YgdGhlbSB0aG91Z2ggSSBhbSBhIHdl ZWtlbmQgaG9iYnlpc3QuIDotKQ0KPj4NCj4+ICAgMS4gU29sbzUgaW1wcm92ZW1lbnQNCj4+ ICAgMi4gVW5pa3JhZnQgYmFjay1lbmQNCj4+ICAgLT4gSSBsaWtlIHRoZSBTb2xvNSBwaGls b3NvcGh5IChzaW1wbGUsIHNtYWxsLCBhbmQgc2VjdXJlZCkuIEhvd2V2ZXIgLi4uIHRoZSBj dXJyZW50IFNvbG81IGltcGxlbWVudGF0aW9uIGhhcyBzb21lIHByb2JsZW1zIGFzIHlvdSBt ZW50aW9uZWQuDQo+PiAgICAgIFNvLCBoYXZpbmcgYW4gYWx0ZXJuYXRpdmUgYmFjay1lbmQg c2VlbXMgYSBnb29kIHdheS4NCj4+ICAgMy4gTWlyYWdlT1MgZGV2aWNlIEFQSXMgKG1haW5s eSB0YXJnZXRpbmcgUENJZSBkZXZpY2VzPykNCj4+ICAgLT4gSSBoYXZlIHByZXZpb3VzbHkg dHJpZWQgIk1pcmFnZU9TICsgU29sbzUgaHZ0ICsgTmV0bWFwICsgMTBHYkUgd2l0aCBTUi1J T1YiLiBNeSBleHBlcmllbmNlIG9uIHRoYXQgd2lsbCBiZSBoZWxwZnVsIHRvIHRoaXMgdG9w aWMhDQo+IA0KPiBUaGF04oCZcyByZWFsbHkgYXBwcmVjaWF0ZWQuIFdlIHdpbGwga2VlcCB5 b3UgaW4gdGhlIGxvb3AuIFdoYXQgZG8geW91IHJlY29tbWVuZCByZWFkaW5nIHRvIGxlYXJu IG1vcmUgYWJvdXQgeW91ciBleHBlcmllbmNlIHdpdGggTmV0bWFwPw0KPiANCj4gQmVzdCwN Cj4gVGhvbWFzDQo+IA0KPj4gT24gMjAyMy8xMi8xNiAzOjE4LCBUaG9tYXMgR2F6YWduYWly ZSB3cm90ZToNCj4+PiBIZWxsbyB0aGVyZSwNCj4+PiBPdmVyIHRoZSBsYXN0IHllYXIsIFRh cmlkZXMgaGFzIGJlZW4gZW5nYWdpbmcgd2l0aCBwYXJ0bmVycyBpbiB0aGUgc3BhY2Ugc2Vj dG9yIHRvIGFkYXB0IE1pcmFnZU9TIGZvciB1c2UgaW4gc3BhY2UgZW52aXJvbm1lbnRzLiBG b2xsb3dpbmcgcGFydGljaXBhdGlvbiBpbiBDeWJlckBTdGF0aW9uRiBhbmQgaW5pdGlhbCBk aXNjdXNzaW9ucyB3aXRoIFRoYWxlcyBBbGVuaWEgU3BhY2UgaW4gbGF0ZSAyMDIyLCB3ZSBo YXZlIGJlZ3VuIHRoZSBkZXZlbG9wbWVudCBvZiBTcGFjZU9TLiBUaGlzIG9wZXJhdGluZyBz eXN0ZW0sIGxldmVyYWdpbmcgbnVtZXJvdXMgTWlyYWdlT1MgY29tcG9uZW50cywgaXMgZGVz aWduZWQgdG8gbWVldCB0aGUgbmV3IHJlcXVpcmVtZW50cyBvZiBtdWx0aS1taXNzaW9uLCBt dWx0aS11c2VyIHNhdGVsbGl0ZSBtaXNzaW9ucyAod2hhdCBwZW9wbGUgYWxzbyBjYWxsICJO ZXdTcGFjZSIpLg0KPj4+IFNwYWNlT1MncyBkZXZlbG9wbWVudCBoYXMgbGVkIHRvIFRhcmlk ZXMgam9pbmluZyBhIGNvbnNvcnRpdW0gb2YgYWNhZGVtaWMgYW5kIGNvbW1lcmNpYWwgZW50 aXRpZXMgaW4gdGhlIHNwYWNlIGluZHVzdHJ5LiBXZSBoYXZlIHN1Y2Nlc3NmdWxseSBvYnRh aW5lZCBvdXIgZmlyc3QgZ3JhbnQgKHdpdGggdGhlIFtPUkNISURFIHByb2plY3QsIHBhcnQg b2YgdGhlIEVVIEhPUklaT04gQ0w0LTIwMjMtU1BBQ0UtMDEtMTEgcHJvZ3JhbW1lLF0oaHR0 cHM6Ly9lYy5ldXJvcGEuZXUvaW5mby9mdW5kaW5nLXRlbmRlcnMvb3Bwb3J0dW5pdGllcy9w b3J0YWwvc2NyZWVuL2hvdy10by1wYXJ0aWNpcGF0ZS9vcmctZGV0YWlscy85OTk5OTk5OTkv cHJvamVjdC8xMDExMzU1OTUvcHJvZ3JhbS80MzEwODM5MC9kZXRhaWxzKSkgYW5kIGhhdmUg c2V2ZXJhbCBvdGhlcnMgdW5kZXIgcmV2aWV3LiBUaGUgZ29hbCBmb3IgU3BhY2VPUyBpcyB0 byByZW1haW4gYXMgb3Blbi1zb3VyY2UgYXMgcG9zc2libGUsIGFsaWduaW5nIHdpdGggdGhl IE1pcmFnZU9TIGNvbW11bml0eSdzIGFwcHJvYWNoIHRvIHNvZnR3YXJlIGRldmVsb3BtZW50 ICh3aXRoIGEgZmV3IGV4Y2VwdGlvbnMgaW4gc2NlbmFyaW9zIGludm9sdmluZyBwcm9wcmll dGFyeSBoYXJkd2FyZSBvciBzb2Z0d2FyZSB2ZW5kb3JzKS4NCj4+PiBIZW5jZSwgVGFyaWRl cyBpcyBwbGFubmluZyBhY3RpdmUgZGV2ZWxvcG1lbnQgd29yayBvbiBNaXJhZ2VPUyBpbiB0 aGUgY29taW5nIHllYXJzIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGVhcmx5IGRldmVsb3Bt ZW50IHN0YWdlcyBvZiBTcGFjZU9TLiBXZSBoYXZlIGFtYml0aW91cyBwbGFucyBpbiBtaW5k IGFuZCBhcmUgcmVhY2hpbmcgb3V0IHRvIHRoZSBNaXJhZ2VPUyBjb21tdW5pdHkgdG8gZ2F0 aGVyIGlucHV0IGFuZCBwZXJzcGVjdGl2ZXMgZHVyaW5nIHRoaXMgcGhhc2UuIFdlIHdlbGNv bWUgeW91ciB0aG91Z2h0cyBvbiB0aGlzIG1hdHRlciwgd2hldGhlciB0aGVzZSBhcmUgYWdy ZWVtZW50cywgZGlzYWdyZWVtZW50cywgb3IgZ2VuZXJhbCBjb21tZW50cy4gUGxlYXNlIHNo YXJlIHlvdXIgZmVlZGJhY2sgb24gdGhpcyBtYWlsaW5nIGxpc3QgKHByZWZlcnJlZCkgb3Ig dGhyb3VnaCBwcml2YXRlIGNvbW11bmljYXRpb24uDQo+Pj4gIyMjIFRvb2xpbmcNCj4+PiBP dmVyIHRoZSBwYXN0IGZpdmUgeWVhcnMsIG91ciBlZmZvcnRzIGhhdmUgZm9jdXNlZCBvbiBp bnRlZ3JhdGluZyBNaXJhZ2Utc3BlY2lmaWMgdG9vbGluZyBpbnRvIHRoZSBPQ2FtbCBQbGF0 Zm9ybS4gV2UgcGxhbiB0byBjb250aW51ZSBpbiB0aGlzIGRpcmVjdGlvbi4gVGhpcyBpbnRl Z3JhdGlvbiBpcyBpbnRlbmRlZCB0byBiZW5lZml0IGJvdGggTWlyYWdlIGRldmVsb3BlcnMg KGJ5IHJlZHVjaW5nIHRoZSBtYWludGVuYW5jZSBidXJkZW4gb24gdGhlIGNvcmUgTWlyYWdl T1MgdGVhbSkgYW5kIHRoZSBicm9hZGVyIE9DYW1sIHVzZXIgYmFzZSAoYXMgdGhleSBjb3Vs ZCBiZW5lZml0IGZyb20gTWlyYWdlT1Mgd29ya2Zsb3cgLS0gZXNwZWNpYWxseSBjcm9zcy1j b21waWxhdGlvbiAtLSBpbiBvdGhlciBzaXR1YXRpb25zKS4NCj4+PiBBIHNpZ25pZmljYW50 IHBhcnQgb2YgdGhpcyBlZmZvcnQgd2FzIHRyYW5zaXRpb25pbmcgZnJvbSBjdXN0b20geC1j b21waWxhdGlvbiBydW5lcyB0byB1c2luZyBEdW5lIHdvcmtzcGFjZSB2aWEgYG9wYW0gLW1v bm9yZXBvYC4gVGhpcyBtaWdyYXRpb24gd2FzIG5vdCBhbHdheXMgcGFpbmxlc3MgKHRvIHNh eSB0aGUgbGVhc3QpLCBidXQgd2UgbGVhcm5lZCBhIGZldyB0aGluZ3MgdGhhdCBhcmUgbm93 IGJlaW5nIGFwcGxpZWQgdG8gdGhlIG5ldyAicGFja2FnZSBtYW5hZ2VtZW50IiBmZWF0dXJl IG9mIER1bmUgNC4gVGh1cywgd2UgcGxhbiB0byBjb250aW51ZSB0byB3b3JrIG9uIG1pZ3Jh dGluZyBmcm9tIGBvcGFtLW1vbm9yZXBvYCB0byB0aGUgYGR1bmUgcGtnYCBjb21tYW5kIHRv IGVuc3VyZSBpdCB3b3JrcyBmb3IgTWlyYWdlT1MgdXNlcnMuIFRoaXMgbmV3IGNvbW1hbmQg YWRkcmVzc2VzIHRoZSBsaW1pdGF0aW9ucyBpZGVudGlmaWVkIGluIG9wYW0tbW9ub3JlcG8s IGVzcGVjaWFsbHkgZm9yIHBhY2thZ2VzIG5vdCBidWlsdCB3aXRoIER1bmUuIEFuIGFscGhh IHZlcnNpb24gaXMgY3VycmVudGx5IGF2YWlsYWJsZSAodHJ5IGBkdW5lIHBrZ2Agd2l0aCBE dW5lIDMuMTIpLCBhbmQgd2UgYW50aWNpcGF0ZSBhIGNvbXBsZXRlIHJlbGVhc2UgaW4gUTEg MjAyNC4gV2UgcmVhbGx5IHdhbnQgdG8gZW5zdXJlIHRoaXMgaXMgYSBkcm9wLWluIHJlcGxh Y2VtZW50IGZvciBNaXJhZ2UncyB1c2Ugb2YgYG9wYW0tbW9ub3JlcG9gLCBzbyB3ZSB3aWxs IHdvcmsgd2l0aCB1cHN0cmVhbSB0byBlbnN1cmUgdGhhdCBpcyB0aGUgY2FzZSAoYW5kIHNv IHdlIGNhbiBkZXByZWNhdGUgb3BhbS1tb25vcmVwbyBpbiBRMiAyMDI0KS4NCj4+PiBSZWdh cmRpbmcgbWlyYWdlL2Z1bmN0b3JpYSwgbXkgZ2VuZXJhbCBmZWVsaW5nIGlzIHRoYXQgd2hp bGUgdGhlIENMSSB0b29sIHdhcyBpbml0aWFsbHkgdmFsdWFibGUgZm9yIGdhdGhlcmluZyBh biBlY29zeXN0ZW0gb2YgbGlicmFyaWVzLCBub3dhZGF5cywgaXQgaXMgbGVzcyBjbGVhciBp ZiB0aGlzIGlzIHN0aWxsIHJlcXVpcmVkLiBSaWdodCBub3csIG1vc3Qgb2YgdGhlIHRvb2wn cyBjb21wbGV4aXR5IGlzIGhhbmRsaW5nIHRoZSBpbnN0YWxsYXRpb24gb2YgcGFja2FnZXMg bmVlZGVkIGZvciBhIHNwZWNpZmljIHRhcmdldC9jb21iaW5hdGlvbiBvZiBkZXZpY2VzLiBU aGlzIHdpbGwgbm8gbG9uZ2VyIGJlIG5lZWRlZCBpZiB0aGUgYnVpbGQgc3lzdGVtIGNhbiBk byB0aGlzIGluc3RlYWQuIElkZWFsbHksIGFueSBPQ2FtbCBhcHBsaWNhdGlvbiAoZm9sbG93 aW5nIGEgZmV3IGRlc2lnbiBwcmluY2lwbGVzKSBjb3VsZCBiZSBjb21waWxlZCB0byBhIHVu aWtlcm5lbCBzaW1wbHkgdXNpbmcgRHVuZSwgYXMgZW52aXNpb25lZCBieSB0aGUgW1dvcmtm bG93IFcxMl0oaHR0cHM6Ly9vY2FtbC5vcmcvZG9jcy9wbGF0Zm9ybS1yb2FkbWFwI3cxMi1j b21waWxlLXRvLW1pcmFnZW9zKSBvZiB0aGUgT0NhbWwgUm9hZG1hcC4gSG93ZXZlciwgdGhl cmUgaXMgbm8gZXhpc3RpbmcgZGVzaWduIG9uIGhvdyB0aGlzIHNob3VsZCB3b3JrIGF0IHRo aXMgc3RhZ2UuIFNvLCBiZWZvcmUgc3RhcnRpbmcgdGhpcywgaXMgdGhhdCB0aGUgcmlnaHQg ZGlyZWN0aW9uIGZvciB0aGUgbWlyYWdlIHRvb2w/DQo+Pj4gIyMjIFRhcmdldHMNCj4+PiBU aGUgcHJpbmNpcGFsIHRhcmdldCBiYWNrZW5kIGZvciBNaXJhZ2VPUyBub3dhZGF5cyBpcyBT b2xvNS4gVGhpcyBpcyBhIHNvbGlkIGJhY2tlbmQsIHdoaWNoIGhhcyBiZWVuIGF1ZGl0ZWQg YW5kIG9wdGltaXNlZCBmb3Igc2VjdXJpdHkuIEl0IGlzIGFsc28gcmVsYXRpdmVseSBzaW1w bGUgdG8gYWRkIG5ldyBkZXZpY2VzIGdpdmVuIHRoZSBieS1kZXNpZ24gbG93LWNvbXBsZXhp dHkgYXBwcm9hY2ggb2YgaXRzIGRldmljZSBtb2RlbC4gSG93ZXZlciwgd2hpbGUgc29sbzUg aXMgdG9kYXkgdGhlIG1vc3Qgc2VjdXJlIHVuaWtlcm5lbCAicnVudGltZSIsIEkgYWxzbyBm ZWVsIGl0IGhhcyBpc3N1ZXMgaGluZGVyaW5nIHBvdGVudGlhbCBjaGFuZ2VzLiBGb3Igb25l LCBpdCBpcyBzbG93IC0tIHRoZSBkZXZpY2UgbW9kZWwgaXMgbm90IG1lYW50IGZvciBoaWdo LXNwZWVkIEkvTywgYW5kIHRoZXJlIGlzIG5vIHN1cHBvcnQgZm9yIFNNUDsgZm9yIG1vc3Qg dXNlIGNhc2VzLCBpdCBpcyBub3QgYW4gaXNzdWUsIGJ1dCBmb3Igb3RoZXJzIHdlIGFyZSBs b29raW5nIGF0LCBpdCBjYW4gYmUuIFRoZSBvdGhlciBvbmUgaXMgdGhhdCB0aGUgZGV2aWNl IG1vZGVsIGlzIHZlcnkgc2ltcGxlIChmb3IgZ29vZCByZWFzb25zKSBhbmQgY2hhbGxlbmdp bmcgdG8gZXh0ZW5kIHRvIG5ldyBkZXZpY2VzIChzZWUgYmVsb3cgZm9yIG1vcmUgZGV0YWls KS4gSW4gYW4gaWRlYWwgd29ybGQsIHRoaXMgY291bGQgYmUgZml4YWJsZSwgYnV0IHRoZXJl IGFyZSBhbHNvIHZlcnkgZmV3IGNvdXJhZ2VvdXMgYWN0aXZlIG1haW50YWluZXJzLCBzbyBh bnkgY2hhbmdlcyAtIGxpa2UgbW92aW5nIHRvIE9DYW1sNSAtIGFyZSBjb21wbGV4IHRvIG1h a2UuDQo+Pj4gVGh1cywgd2UgYXJlIGV2YWx1YXRpbmcgYWx0ZXJuYXRlIGJhY2tlbmRzIHdp dGggdGhlIG1haW4gY3JpdGVyaWEgdG8gcmVkdWNlIHRoZSBtYWludGVuYW5jZSBjb3N0LiBE ZXNwaXRlIGl0cyBjdXJyZW50bHkgbGltaXRlZCBzZWN1cml0eSBmZWF0dXJlcywgb25lIGlu dGVyZXN0aW5nIHBvc3NpYmlsaXR5IGlzIHNoaWZ0aW5nIHRvd2FyZHMgYWx0ZXJuYXRpdmUg YmFja2VuZHMgbGlrZSB1bmlrcmFmdC4gQ2hyaXN0aWFubyBzcGVudCBhIGJpdCBvZiB0aW1l IGxvb2tpbmcgYXQgdGhpcyBlYXJsaWVyIHRoaXMgeWVhciAod2l0aCBhIHByb3RvdHlwZSBv ZiB0aGUgT0NhbWwgNSBydW50aW1lIHgtY29tcGlsZXIgdG8gVW5pa3JhZnQgW2hlcmVdKGh0 dHBzOi8vZ2l0aHViLmNvbS9oYWVzYmFlcnQvdW5pa3JhZnQtb2NhbWwpIGFuZCBhIHJvYWRt YXAgZm9yIFVuaWtyYWZ0IHNlY3VyaXR5IFtoZXJlXShodHRwczovL2dpdGh1Yi5jb20vb3Jn cy91bmlrcmFmdC9wcm9qZWN0cy8zMi92aWV3cy8xKSkuIFNhbWUgYXMgYWJvdmUsIHdlIGFy ZSBpbnRlcmVzdGVkIHRvIGhlYXIgd2hhdCBwZW9wbGUgdGhpbmsgYW5kIGlmIGFueW9uZSBp cyBpbnRlcmVzdGVkIGluIGNvbGxhYm9yYXRpbmcgd2l0aCB1cyBpbiBwb3J0aW5nIE1pcmFn ZU9TIHRvIHVuaWtyYWZ0IChhbmQgY29udHJpYnV0aW5nIHRvIFVuaWtmcmFmdCcgc2VjdXJp dHkgcm9hZG1hcCkuDQo+Pj4gIyMjIERldmljZXMgYW5kIExpYnJhcmllcw0KPj4+IFRoZXJl IGFyZSB0aHJlZSBhcmVhcyB0aGF0IHdlIHdvdWxkIGxpa2UgdG8gZm9jdXMgb24gKG9yIGNv bnRpbnVlIHRvIGZvY3VzIG9uKSBpbiB0aGUgbmV4dCBjb3VwbGUgb2YgeWVhcnMuDQo+Pj4g Rmlyc3QsIHdlIHN0aWxsIGJlbGlldmUgdGhlcmUgYXJlIGJldHRlciBhYnN0cmFjdGlvbnMg Zm9yIHN0b3JpbmcgZGF0YSB0aGFuIFBPU0lYLiBIZW5jZSwgd2UgYXJlIGNvbnRpbnVpbmcg dG8gZGV2ZWxvcCBhbmQgaW1wcm92ZSBJcm1pbi4gV2UgYXJlIGN1cnJlbnRseSBwb3J0aW5n IGBpcm1pbi1wYWNrYCB0byBNaXJhZ2VPUyAodGhlIGJhY2tlbmQgb2YgSXJtaW4gdXNlZCBi eSB0aGUgVGV6b3MgYmxvY2tjaGFpbiB0byBzdG9yZSBpdHMgbGVkZ2VyIGhpc3RvcnkpIHZp YSB0aGUgW05vdGFmc10oaHR0cHM6Ly9naXRodWIuY29tL3RhcmlkZXMvbm90YWZzKSBwcm9q ZWN0LiBOb3RhZnMgaXMgYSBwc2V1ZG8gZmlsZXN5c3RlbSBmb3IgTWlyYWdlIGJsb2NrIGRl dmljZXMuIEl0IGNhbiBoYW5kbGUgYSBzbWFsbCBudW1iZXIgb2YgbGFyZ2UgZmlsZXMuIFdo aWxlIHRoZSBsaW1pdGVkIG51bWJlciBvZiBmaWxlbmFtZXMgaXMgdW5zYXRpc2Z5aW5nIGZv ciBnZW5lcmFsIHVzYWdlLCBpdCBjYW4gYmUgdXNlZCB0byBydW4gdGhlIGlybWluLXBhY2sg YmFja2VuZCBvZiBJcm1pbiwgd2hpY2ggb25seSByZXF1aXJlcyBhIGRvemVuIGh1Z2UgZmls ZXMuIEJ5IHJ1bm5pbmcgSXJtaW4sIG9uZSBnZXRzIGZvciBmcmVlIGEgZmlsZXN5c3RlbS1v bi1zdGVyb2lkIGZvciBNaXJhZ2VPUzogaXQgc3VwcG9ydHMgYW4gYXJiaXRyYXJpbHkgbGFy Z2UgbnVtYmVyIG9mIGZpbGVuYW1lczsgaXMgb3B0aW1pc2VkIGZvciBzbWFsbCBhbmQgbGFy Z2UgZmlsZSBjb250ZW50czsgcGVyZm9ybXMgZmlsZSBkZWR1cGxpY2F0aW9uOyBpbmNsdWRl cyBhIGdpdC1saWtlIGhpc3Rvcnkgd2l0aCBicmFuY2hpbmcgYW5kIG1lcmdpbmcsIC4uLiBh bmQgaXQgZXZlbiBwcm92aWRlcyBhIGdhcmJhZ2UgY29sbGVjdG9yIHRvIGF2b2lkIHJ1bm5p bmcgb3V0IG9mIGRpc2sgc3BhY2UgKGJ5IGRlbGV0aW5nIG9sZGVyIGNvbW1pdHMpLiBTaW5j ZSB0aGUgSXJtaW4gZmlsZXN5c3RlbSBpcyB2ZXJzaW9uZWQgYnkgTWVya2xlIGhhc2hlcywg b25lIGNhbiBpbWFnaW5lIGRlcGxveWluZyByZXByb2R1Y2libGUgdW5pa2VybmVscyBvbiBy ZXByb2R1Y2libGUgZmlsZXN5c3RlbSBzdGF0ZXMhDQo+Pj4gV2UgYXJlIGFsc28gaW50ZXJl c3RlZCBpbiBkZXZlbG9waW5nIG5ldyBuZXR3b3JrIHByb3RvY29scyBmb3Igc3BhY2UgYXBw bGljYXRpb25zLCB3aGljaCBjb3VsZCBiZW5lZml0IGZyb20gTWlyYWdlT1MncyBjYXBhYmls aXRpZXMuIFdlIGFyZSBsaWtlbHkgdGFyZ2V0aW5nIHRoZSBbU3BhY2UgQ29tbXVuaWNhdGlv biBQcm90b2NvbF0oaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvU3BhY2VfQ29tbXVu aWNhdGlvbnNfUHJvdG9jb2xfU3BlY2lmaWNhdGlvbnMpLCB3aGljaCBzZWVtcyBhbiBpbnRl cmVzdGluZyBkb21haW4gYXMgdGhlcmUgZG9lcyBub3Qgc2VlbSB0byBleGlzdCBhbnkgb3Bl bi1zb3VyY2UsIHJvYnVzdCBpbXBsZW1lbnRhdGlvbiBvZiB0aGVzZSBwcm90b2NvbHMuDQo+ Pj4gRmluYWxseSwgdGhlIEFQSSBmb3IgZGV2aWNlcyBzdXBwb3J0ZWQgYnkgTWlyYWdlT1Mg Y3VycmVudGx5IG1hcHMgdG8gd2hhdCBpcyBhdmFpbGFibGUgb24gdmlydHVhbGlzZWQgaW5m cmFzdHJ1Y3R1cmUgKGkuZS4gdmlydHVhbCBibG9jayBkZXZpY2VzIGFuZCB2aXJ0dWFsIG5l dHdvcmsgaW50ZXJmYWNlKS4gV2UgYXJlIGludGVyZXN0ZWQgaW4gaW52ZXN0aWdhdGluZyBo b3cgdG8gZXh0ZW5kIHRoaXMsIGZvciBpbnN0YW5jZSwgYnkgcmV2aXZpbmcgdGhlIFBDSS1w YXNzdGhyb3VnaCBleHBlcmltZW50YXRpb25zIGRvbmUgYSBmZXcgeWVhcnMgYWdvIGJ5IEZs b3JpYW4sIG9yIGJ5IGludmVzdGlnYXRpbmcgbmV3IG11bHRpLXRlbmFuY3kgZGV2aWNlIGZy YW1ld29ya3MgbGlrZSBbdkFjY2VsXShodHRwczovL3ZhY2NlbC5vcmcvKSB0byAoc2VjdXJl bHk/KSBzaGFyZSBHUEdQVXMgb3IgRlBHQXMgYmV0d2VlbiB1c2Vycy4gQWx0ZXJuYXRpdmVs eSwgd2UgY291bGQgdXNlIE93bCB1c2luZyBDUFUuIFdlIGFsc28gd2VsY29tZSBhbnlvbmUg d2l0aCBhbnkgZXhwZXJpZW5jZSBpbiB0aGlzIGFyZWEgdG8gZGlzY3VzcyBleGlzdGluZyBh bHRlcm5hdGl2ZXMuDQo+Pj4gIyMjIE9TIERpc3RyaWJ1dGlvbg0KPj4+IEZpbmFsbHksIHdl IGFyZSBjb25zaWRlcmluZyBvcHRpb25zIGZvciBidWlsZGluZyBhIGZsZXhpYmxlIE9TIGRp c3RyaWJ1dGlvbiwgd2hpY2ggbWlnaHQgaW5jbHVkZSBlbGVtZW50cyBsaWtlIFtMaW51eEtp dC9NaXJhZ2VTREtdKGh0dHBzOi8vZ2l0aHViLmNvbS9saW51eGtpdC9saW51eGtpdC90cmVl L21hc3Rlci9wcm9qZWN0cy9taXJhZ2VzZGspLiBUaGlzIGNvbmNlcHQgY29tYmluZXMgYSBz ZWN1cmUgTGludXgga2VybmVsIHdpdGggYSBjb2xsZWN0aW9uIG9mIE1pcmFnZS1iYXNlZCBz eXN0ZW0gc2VydmljZXMgYW5kIGFuIGV4dGVuZGVkIHZlcnNpb24gb2YgQWxiYXRyb3NzIGZv ciBvcmNoZXN0cmF0aW9uLCBhbGwgY3VzdG9taXNhYmxlIGJhc2VkIG9uIHNwZWNpZmljIG5l ZWRzLiBXZSBhcmUgaW4gdGhlIGVhcmx5IHN0YWdlcyBvZiB0aGlzIGRpc2N1c3Npb24gYW5k IHdlbGNvbWUgYW55IGlucHV0IG9yIGV4cHJlc3Npb25zIG9mIGludGVyZXN0IGluIGZ1cnRo ZXJpbmcgdGhlc2UgaWRlYXMuDQo+Pj4gQmVzdCwNCj4+PiBUaG9tYXMNCj4gDQo=