From mirageos-devel-bounces@lists.xenproject.org Mon Feb 03 11:13:14 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 03 Feb 2025 11:13:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.880536.1290609 (Exim 4.92) (envelope-from ) id 1teuNy-000497-H8; Mon, 03 Feb 2025 11:13:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 880536.1290609; Mon, 03 Feb 2025 11:13:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1teuNy-000490-Dr; Mon, 03 Feb 2025 11:13:02 +0000 Received: by outflank-mailman (input) for mailman id 880536; Mon, 03 Feb 2025 11:13:01 +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 1teuNw-00048u-Nu for mirageos-devel@lists.xenproject.org; Mon, 03 Feb 2025 11:13:01 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d233b162-e21f-11ef-99a4-01e77a169b0f; Mon, 03 Feb 2025 12:12:58 +0100 (CET) Received: from [192.168.42.80] (i5C74C04B.versanet.de [92.116.192.75]) (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 023363501 for ; Mon, 3 Feb 2025 12:12:55 +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: d233b162-e21f-11ef-99a4-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mehnert.org; s=mail; t=1738581176; bh=GmuPAayo/WPf5fEACnjhmB10xRrfFWXZZvzs82j1F3M=; h=Date:To:From:Subject; b=SSkCdTpFCNi91HSILDv30rH6BUJHP6qUctKi5T53IMF/lcnRKJ0NmCCjFUUQpMnz+ tvPTIZAmNd9zg2rTkE7C+GFz7SKWYZ9wdaxTk76xx8N5v1ahmcThTV6uRI+H+Dsbjb 7ySlfwDB/9kSj6xTg3Rko9q4hD5IEgIHdjh9gO2Yl3vrJlPJIym70VGm994ROZGjuj Gy6GJDRESOSOF4Ggu+4qvzhr2k+L1NrCVFUKLPHXVD0tEcEhGS3SHy32TeZPKUjab8 ITRQvG27+K5u3EFJfKd9ITECq6EqrJPk0yoXUoCZveBBS1LwN7eoR2InEPasjCzfzx ZI2sPXIcLQmzA== Message-ID: <3fa263d5-2268-4178-a672-a7e83e4daeb6@mehnert.org> Date: Mon, 3 Feb 2025 12:12:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: mirageos-devel Content-Language: en-US From: Hannes Mehnert Subject: Retreat May 13th - 20th 2025 Autocrypt: addr=hannes@mehnert.org; keydata= xsFLBEIw1AoBEADAtXwEV8F1DBpE9lnBTbHDNeZwDVp84MhxxIT5GUexGgbOWGSEWHhC3rYe FfGRUxF4M9P4fwxpxCS5YCvxoijWHeEf8nG5IkztVv5cw63E443XWHcCMc80YAwglZ2cSP4U GTNeKb9rqVPckk/PL348BYRawhzvZK+Bc+bUvbtPCfUXT1BWIxAR1dzsfpAQVNZ4bA06xOoP QJYVNgl/lWOmQgnSgb0dE2zsgddKTOj05ru7Q7LobB7WAUTRJVkZcXnrvI1SOt/WbPTyqF8l RBh94xCqFhv4SlqZVOTXxo9gw3LpDv/cYXRl/m7+/7Wljl3ziQ9cawA6O1mbw8nm7Sfa+TZl qo+5lXEenXG+MCbH0XnnL2I4BO6HSGDtKX6htTG2xs6w4r9mVxTGJuJcGrC0dxuz5j4jylt/ KOVn9IaRKzhj8ga7kWffMp+JYdrn43732weoFFJxm78mD2ij4UbJtNkQIIcTv8IBJajHy2P3 h1NuBIwwb7RmBav4oo0CKWoasIHFwjMSBpCzJ8QOHeO/F3TY3DZp7FTwViUgSXVJoewO9yFG ctX7MC27/F1IonU9/SJW0j+F3Vz32SfxUBrDnLYpO7/vwA8w+xmWLnl0iJN/8injz5+CigsP e7O66t4MtC9BVCuLu7a/ikH5nW0q6RyTW8of9eZIsuEyqF1ZPwAGKc0jSGFubmVzIE1laG5l cnQgPGhhbm5lc0BtZWhuZXJ0Lm9yZz7CwXQEEwECAB4FAkIw1A0CGwMGCwkIBwMCAxUCAwMW AgECHgECF4AACgkQvIlliN98KO5HYg//UD6gk4sFcNop/EQivcnpfPnHrrUddsBl9bovQSXb zIh5HY/8xhO5i87n5Aox9jYLcZwa6HJ3ElHMOa+n9AY4/+H8bd+BiHWTgEhEzcZqcYwyP2S2 0X/e/m/+1XYs5tldKNZb7ruYRv6rNyUAF1H8EtYNaJpmGtXYurkMhWhEgeP9YB7svmkUN+JO og91tNhN1Wd10/JfKIytNcpXmW6zij0f3MJw/kdwIsmfSUMPaiEli+eB7nU0uLZWf4C3MWTT NmwNznEya5K9McH1Wc/lO9+oB+zRXFBUM/v9YaiyPZo0JcwSRdVYKvKteyqnL/lnx7vtkOnA EC/bcmMvlWLI+Q4Vw2cr2FKcIpJVwswZ5snFqgDr4O5JB88aEAzPFzyWWeBlVqXc0DbDu8jD YmG3yp/xn5UJQSRy6eUcXICNjJyIwekUCznRmhtGwkGFCFEZH/s2fQ7nETxZcuiE4meRnVQE 9lOafI5D+dlsG3SlyN1x0YvrPismep7PwA6FX3cDyz2iUUj4xICLvRLU6kq892KuFmv75pop VAZjJMQqc8BG3oN2YkDcO4NEuOT9/r9muk/WH5Mqcs2BJEG6+yiQ13uMS5TxXiPFp3vKRlq0 MFnm7YRZr5aK6B/WGLOHnRRb2OdAzUgsj4Qiyqvh8Ab+x9wjLwGePxlA1akrF2hQItfOwUsE QjDUdAEQAOHG4vdGxU3eH5hYDLYRsQP6ofoU36pV8iFEtZRJ833L5p9GP2xFUGVDH8yTdkdf QR1prsCJXA7sE/gYBf3k9lGicJQmYNo3uW9Ngz787BhiQJyW/JXcutyTt9b/AZmfJaDo1p0C 8IEtoG7wt4+giFwAJ1brTJtyxlKOGcjWiKh1/dTh13muXSOPcCmhNs4Zm0YNjrhW9nIn1iik lpMRJCCxY1RNcU2VZXfTqq63UTaIrZ1lgYXWilnTdpXt5UEDYBw8Ee6tpPfQflC02e8hbDeD JEP9MTM9pmmPOwZQXP36hTryakKt1Kpw3hgC+Yx9q4wwaZ4XIiWUgopT5mlI+LhnzCgO05YN NcPrbsr6Js34gC3odNicD+C1jSdOXCqAPZZNiVx0PBjRv+LbBZhUkjQJxidvXmrp55pLm+Ua IVl3E/HpFY8kTaJBHP7jvLp+W4J9tP64Ijk5Y9F0z93JwMspG671xuomFsRxUtyO6vldd7qH 1yVzDX7Dd0fAzMDOPQJW6zLiixCmA0McaZdeBXapMJDDoZAPY4pCbRyJJXe0tfv9ufzJrM8Z JHylONdBiIKWw0JldXkUvIGafl1JDOHjP1XoDWrSDO8yFhBR3uWxJy9u1s7aKvonQb5IcYU1 nPu1Olg3doPugXyC0V05MIa68iKw+Kv8KtDDWyibndoTAAYpwsFfBBgBAgAJBQJCMNR1AhsM AAoJELyJZYjffCjuelUP/jlCsxLzu3fZpuORY2LsOQMd4nFHSZLUjauLxDUn8jE//32IIJ0v QV9ab4k7JCLOuYJTTd9aYD6rkITZIVhAcsR/FQZNgVOvGTj6tAmNyn385vMz0p4bLOOy5T0C KMLKzzS4Rt4XgtzvH2xDXSHfPsqS/t/5WFkO+aLgcPALldWGQPgRu5DNoCLr989gCGu5vmd4 XwMRBt/LmJGI0v0EypL3eRmlGaUw5k6N1hStu4EETzdikAzXP5KTuloEXq/caYeUs/SIb5zi XVC1ISW0CIwj5ATbMh8DMG4splXCsajtnJjsKJATBZIWV4XoNqtgV+pQn1ShmW36nUfVGqzX AQ+9i/M+CCkxBrb85Bk8I1CA1nBHNk5SQqER40VRp6vcmuxvIBGi6t8dDWsDQ2q3kd4RjjDZ kYjSie7176bb9t5MfUGjA9WckHuyi+vjy3+sC/nRzByhXf+8iZsO2no3xWZkGUWI8F2hhpzW VsXqvC27LZvJk53fJbpuSueN8a7JKfbKPDqoDSsRaEtcM7ig475tqA/ZCzv6mdqhEV5buoLu cpW7UgYzjNQQXeYZygGWc7FTV3dqLmF1MY2+RlydQbUDjcj1CJ+UmKyxgoLyf7ru0sznr7Tp K4WDnVeJdWX1mqoSupF/u5LON1vpzh3OIl5NNAuV68Hb5On/ALC+DwFX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear everyone, we'll have another retreat this year in Marrakesh. The registration is open now, please take a look at https://retreat.mirageos.org -- sign up and spread the word. See you soon, Hannes From mirageos-devel-bounces@lists.xenproject.org Mon Feb 03 17:31:27 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 03 Feb 2025 17:31:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.880967.1291067 (Exim 4.92) (envelope-from ) id 1tf0I0-0002xs-Nz; Mon, 03 Feb 2025 17:31:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 880967.1291067; Mon, 03 Feb 2025 17:31:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tf0I0-0002xl-Ks; Mon, 03 Feb 2025 17:31:16 +0000 Received: by outflank-mailman (input) for mailman id 880967; Mon, 03 Feb 2025 17:31:15 +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 1tf0Hz-0002wM-5f for mirageos-devel@lists.xenproject.org; Mon, 03 Feb 2025 17:31:15 +0000 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [2607:f8b0:4864:20::d2f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a892414e-e254-11ef-a0e7-8be0dac302b0; Mon, 03 Feb 2025 18:31:13 +0100 (CET) Received: by mail-io1-xd2f.google.com with SMTP id ca18e2360f4ac-844d7f81dd1so131797339f.2 for ; Mon, 03 Feb 2025 09:31:11 -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: a892414e-e254-11ef-a0e7-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tarides-com.20230601.gappssmtp.com; s=20230601; t=1738603870; x=1739208670; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sKoervGpzJp3HlSw2r5nVHENpKQB3e8SsbtBl0St/9M=; b=cewg+Tn8NxhrZtfrQ6NZy7e8yFBEL3paciFjVgWT9rKokdDyCmoHsMiIwJwEKz1R03 8IzIiGuEq2BS+pYVYf0bEHYqidu0S7jQQUMuDbNtqfsUwSJ1LYlBXRvJb78yzizUGqqO PEcxpML4+Fg+oWaSV2jgkFiihaZFGN93swcvx2HLWh4n+O3WFkOI/2rTSeOi8QmTEdle 8KIMbpU5P5TkpXt+/+BSZ32JgyGHSjvK88J2WSK2KeU5jflFASeUeZm7SrOpdcZg4/7n 0oeFlMZEv6KS3JvBreLhpqEF4zx3FnQ9JGZLmrBzk5RFRZSad5JbEQEQGSw2KkvXLpxb +FsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738603870; x=1739208670; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sKoervGpzJp3HlSw2r5nVHENpKQB3e8SsbtBl0St/9M=; b=SqWkTdqQnj0iQ4PgLSOp7UHM5Tckq8OYEii15/K71s+NcjOou9wmmqMa/cnrqVt6Zw at9yNAuiLdYYngmp4sjbIf7nD7sZzyTCzrhfD8IHOGegUCn6vExKfHjL6aVusXmruDF4 izoQMmX3ycSHoY99MMz/Cpn89VoTRfScIC6BnURkRnGJuRww2SvX3zhWFhGuSfSj4+Ea gjzpuAtmI0cv+D4P662SHoIGSHAYk/iGdBSk+Tq8kTxKnQXEWcYeSlSg0Vvl7vdns4pN uIda3PwZkWzxd6e4lmjB2kgl/Hvk0TxXNsNUVvvWFrAlwb6nVVXCyjNHG6BjnEdlkdaC YwCQ== X-Forwarded-Encrypted: i=1; AJvYcCVflKGWZIzWmIoiHLN9OiyFlyHUZv+ME3ZseKhASj5zKIEv56rPuRk9oG+ef+7TVtjShq+12gRZgDg/fMqIsA==@lists.xenproject.org X-Gm-Message-State: AOJu0YzTiuhTKZobYYFS/vWqm/KT5UKYL+Dhnw/7+OaFDF/xd/ed6AJ6 wHrkRV/Fl0C4gAj6OUww+/omoKHSzVS88uVjmRVSc7v1mHpKHLFpVCAYVqFzikMZc0CtDZfT3d5 5PoIYM2oE0QeA7Fh5cTdepVHSeX6Fyhz3kjz/Zg== X-Gm-Gg: ASbGncunU9oUK1ukfp1skZO946YpbwsvIQ/3W1SZiAt4le7QVJQVtWAnLSzvwRv0Cn4 cNc0v9FqakTYWKIrGsxikgP03/pD4+eD2Bsnwbipr7JIGx6fwWcR92JDhBrQ7Ns5DVgcNdkLn8Q == X-Google-Smtp-Source: AGHT+IGO6xKnAD/pTraRcqf0dHrRDIPTJpx9JvJpqSC88f49QQuOFrgg6CR12k182DDpp+Qz6b2XbKG37uSQid9W6aM= X-Received: by 2002:a05:6e02:1d88:b0:3cf:cdb8:78fe with SMTP id e9e14a558f8ab-3cffe4745d8mr201233175ab.22.1738603869824; Mon, 03 Feb 2025 09:31:09 -0800 (PST) MIME-Version: 1.0 References: <3ebfc6e3-aeda-4729-a63d-02c139827945@mehnert.org> <70fbf854-41b5-4ba3-bb78-1f80548e88d6@mehnert.org> <0602b9f7-c549-45e5-8ecc-961afc22a9ec@mehnert.org> In-Reply-To: From: Samuel Hym Date: Mon, 3 Feb 2025 18:30:53 +0100 X-Gm-Features: AWEUYZnuFLYMbUD1faho0RLATU57IX4DZ_MSyCQP-TE2z2NHICtCchMq1ftStbQ Message-ID: Subject: Re: next meeting: Monday Feb 10, 10:00 - 12:00 CET To: pierre.alain@tuta.io Cc: Hannes Mehnert , Mirageos Devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, > My understanding of the issue was to munmap of a chunk inside an mmapped = region, which requires a full mmap/munmap implementation (we don't have cur= rently). I'm not sure where the code that causes the ABORT lives and maybe = it can be difficult to trigger the situation? `abort` would be triggered by a `free(x)` where `x` is not the result of a `malloc`. As I didn=E2=80=99t manage to create an example using the compactor that wo= uld run into such a situation and I couldn=E2=80=99t find at which point in the code that could be triggered, I reached out to Sadiq. He confirmed that our implementation is correct. What happens is that, as pools are allocated by the GC, they will probably follow each other in the virtual memory address space; the compactor might decide to release a pool in the middle of that sequence of pools, so we=E2=80=99ll end up with (coarse-grained) fragmentat= ion with our `malloc`/`free` implementation. But it will be valid nevertheless! (That=E2=80=99s a relief :-)) --=20 Samuel From mirageos-devel-bounces@lists.xenproject.org Mon Feb 03 19:45:57 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 03 Feb 2025 19:45:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.880979.1291083 (Exim 4.92) (envelope-from ) id 1tf2O9-0002BY-Lv; Mon, 03 Feb 2025 19:45:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 880979.1291083; Mon, 03 Feb 2025 19:45:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tf2O9-0002BR-Id; Mon, 03 Feb 2025 19:45:45 +0000 Received: by outflank-mailman (input) for mailman id 880979; Mon, 03 Feb 2025 19:45:44 +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 1tf2O7-0002BL-OY for mirageos-devel@lists.xenproject.org; Mon, 03 Feb 2025 19:45:44 +0000 Received: from smtp-2.srv.uis.cam.ac.uk (smtp-2.srv.uis.cam.ac.uk [128.232.132.148]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 72d7cfb7-e267-11ef-a0e7-8be0dac302b0; Mon, 03 Feb 2025 20:45:41 +0100 (CET) Received: from svr-postfix-0.cl.cam.ac.uk ([128.232.119.3]:8831) by smtp-2.srv.uis.cam.ac.uk with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1tf2O4-00000000OoQ-4PTH for mirageos-devel@lists.xenproject.org; Mon, 03 Feb 2025 19:45:40 +0000 Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.201]) (Authenticated sender: avsm2+fm) by svr-postfix-0.cl.cam.ac.uk (Postfix) with ESMTPSA id C36E440B53 for ; Mon, 3 Feb 2025 19:45:39 +0000 (UTC) Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id E3E5D1200079; Mon, 3 Feb 2025 14:45:38 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Mon, 03 Feb 2025 14:45:38 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Feb 2025 14:45:37 -0500 (EST) 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: 72d7cfb7-e267-11ef-a0e7-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20230918.smtp; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=54mgRb4WaQAWNAWnNLh7tXLEkTbJuOlUYT2DORzHgKM=; b=R7IpikPUfa1OCTJm7j9lhCynxQ D1BAANH+CcSGc+NOU7vRwTADJ71oqZAvIiIdrvSvJUKZ45DRvUHCvy8N+ipDjO/oOXi/w+H28i73v cNSsyTFJ7XrH77Di+Y+6f8Z7BPmjK6t616EZbJxu2xlK1bPFbvlH4/b1knvvTs+MeEs6RTfwiR7C7 93XxkZ+ElMW1OCHq6nXnOHqp4iAA+q7yp4HlKaMa/YJWHNsCo12/jY1mGa67kNt43oy8rUaItKN7S tIVNc6J+p9kYnoCqRyI+ML7u8dIiJC37L6Vq9odUeuNdEd5ZR1lZ9J0ET/LNk3AW45WWTm8xm9FXk n7a/6pQA==; X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: https://help.uis.cam.ac.uk/email-scanner-virus X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukeeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuffgjvefvfhfosegrtdhmrehhtdej necuhfhrohhmpeetnhhilhcuofgrughhrghvrghpvgguugihuceorghvshhmvdestghlrd gtrghmrdgrtgdruhhkqeenucggtffrrghtthgvrhhnpedvhfdugeehveffteehtdfhuddv keehhfeguddtjeekieejhfetuedvgfetkeevgfenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghvshhmvddomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidquddvhedvkeefud ejfedqvdekudeljeegieelqdgrvhhsmhdvpeeptghlrdgtrghmrdgrtgdruhhksehfmhdr tghlrdgtrghmrdgrtgdruhhkpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopehsrghmuhgvlhesthgrrhhiuggvshdrtghomhdprhgtphhtthho pehpihgvrhhrvgdrrghlrghinhesthhuthgrrdhiohdprhgtphhtthhopehhrghnnhgvsh esmhgvhhhnvghrthdrohhrghdprhgtphhtthhopehmihhrrghgvghoshdquggvvhgvlhes lhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg X-ME-Proxy: Feedback-ID: i9ebc46d9:Fastmail From: Anil Madhavapeddy Message-Id: <6150A039-59F3-478C-8783-50AE3C22E04E@cl.cam.ac.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_65151243-1E96-43BD-837D-B3BC92BD7EFD" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: next meeting: Monday Feb 10, 10:00 - 12:00 CET Date: Mon, 3 Feb 2025 19:45:26 +0000 In-Reply-To: Cc: pierre.alain@tuta.io, Hannes Mehnert , Mirageos Devel To: Samuel Hym References: <3ebfc6e3-aeda-4729-a63d-02c139827945@mehnert.org> <70fbf854-41b5-4ba3-bb78-1f80548e88d6@mehnert.org> <0602b9f7-c549-45e5-8ecc-961afc22a9ec@mehnert.org> X-Mailer: Apple Mail (2.3826.400.131.1.6) --Apple-Mail=_65151243-1E96-43BD-837D-B3BC92BD7EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2025, at 5:30=E2=80=AFPM, Samuel Hym = wrote: >=20 >> My understanding of the issue was to munmap of a chunk inside an = mmapped region, which requires a full mmap/munmap implementation (we = don't have currently). I'm not sure where the code that causes the ABORT = lives and maybe it can be difficult to trigger the situation? >=20 > `abort` would be triggered by a `free(x)` where `x` is not the result > of a `malloc`. > As I didn=E2=80=99t manage to create an example using the compactor = that would > run into such a situation and I couldn=E2=80=99t find at which point = in the > code that could be triggered, I reached out to Sadiq. He confirmed > that our implementation is correct. > What happens is that, as pools are allocated by the GC, they will > probably follow each other in the virtual memory address space; the > compactor might decide to release a pool in the middle of that > sequence of pools, so we=E2=80=99ll end up with (coarse-grained) = fragmentation > with our `malloc`/`free` implementation. But it will be valid > nevertheless! My suggestion to Sadiq when we were discussing the compactor a few = months ago was to not reinvent the wheel but to use = https://github.com/microsoft/mimalloc instead. It's a state of the art = malloc implementation with a very easy integration path to be directly = embedded into a Mirage runtime. I think it would probably work out = better than using a generic libc malloc in Unikraft (and certainly = better than newlib's malloc implementation). I put together a quick tree last year that just directly vendored = mimalloc, and the integration was pretty straightforward. As always, 80% = of the effort will be in the build system integration, which I didn't do = ;-) best, Anil= --Apple-Mail=_65151243-1E96-43BD-837D-B3BC92BD7EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 3, 2025, = at 5:30=E2=80=AFPM, Samuel Hym <samuel@tarides.com> = wrote:

My understanding of = the issue was to munmap of a chunk inside an mmapped region, which = requires a full mmap/munmap implementation (we don't have currently). = I'm not sure where the code that causes the ABORT lives and maybe it can = be difficult to trigger the situation?

`abort` would = be triggered by a `free(x)` where `x` is not the result
of a = `malloc`.
As I didn=E2=80=99t manage to create an example using the = compactor that would
run into such a situation and I couldn=E2=80=99t = find at which point in the
code that could be triggered, I reached = out to Sadiq. He confirmed
that our implementation is = correct.
What happens is that, as pools are allocated by the GC, they = will
probably follow each other in the virtual memory address space; = the
compactor might decide to release a pool in the middle of = that
sequence of pools, so we=E2=80=99ll end up with (coarse-grained) = fragmentation
with our `malloc`/`free` implementation. But it will be = valid
nevertheless!

My = suggestion to Sadiq when we were discussing the compactor a few months = ago was to not reinvent the wheel but to use https://github.com/microsof= t/mimalloc instead. It's a state of the art malloc = implementation with a very easy integration path to be directly embedded = into a Mirage runtime. I think it would probably work out better than = using a generic libc malloc in Unikraft (and certainly better than = newlib's malloc implementation).

I put together = a quick tree last year that just directly vendored mimalloc, and the = integration was pretty straightforward. As always, 80% of the effort = will be in the build system integration, which I didn't do = ;-)

best,
Anil
= --Apple-Mail=_65151243-1E96-43BD-837D-B3BC92BD7EFD-- From mirageos-devel-bounces@lists.xenproject.org Tue Feb 04 15:41:18 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 04 Feb 2025 15:41:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.881701.1291864 (Exim 4.92) (envelope-from ) id 1tfL2z-0005qN-1X; Tue, 04 Feb 2025 15:41:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 881701.1291864; Tue, 04 Feb 2025 15:41: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 1tfL2y-0005qG-UV; Tue, 04 Feb 2025 15:41:08 +0000 Received: by outflank-mailman (input) for mailman id 881701; Tue, 04 Feb 2025 15:41: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 1tfL2x-0005of-5y for mirageos-devel@lists.xenproject.org; Tue, 04 Feb 2025 15:41:07 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70d07857-e30e-11ef-a0e7-8be0dac302b0; Tue, 04 Feb 2025 16:41:03 +0100 (CET) Received: from [192.168.42.80] (i5C74C113.versanet.de [92.116.193.19]) (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 892F8E8BA for ; Tue, 4 Feb 2025 16:41:02 +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: 70d07857-e30e-11ef-a0e7-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mehnert.org; s=mail; t=1738683662; bh=4faAGFRVqdafUv4nfYzzqyN5/XUuhChLQNSOS4KpSNI=; h=Date:Subject:To:References:From:In-Reply-To; b=fMMLsWQrgRBQCCDnU9BXYdLv+YIt+eeWBX8Odh9Y6YtcUecvj6uQB3OY0miefU2+E LIWO0ChKNdO/555brGvgyLXt8pa7s+ujVxONjl2Zvtg4BFyqvRu69IyphZ+CyyW9M5 2abeBlsqIi84huW3B3thC4hQr/ld0PZZBjEYLBspS7C2RooJaXYGUBnOf2I2XWJFRv tOYcqmVzBBYy5DozRPCjE+rkt1GOC+I1Sx4oeikvrS7laXpr3Za1gkW9ylOg5H2yzu zPUbOJLgM2cPTUQumqjhP6nI0Vvzo0IA1WtNZDLtphFxjv4/DCk5o7uqdgmegke/2/ 17wEcyzB4OuVA== Message-ID: <483d34b5-6de0-48a7-b159-35764f079ecc@mehnert.org> Date: Tue, 4 Feb 2025 16:41:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: TIME, CLOCK, RANDOM - use the linking trick instead of functors To: mirageos-devel@lists.xenproject.org References: <9fc49844-2560-453f-b0fa-0f1ee51672c0@mehnert.org> Content-Language: en-US From: Hannes Mehnert Autocrypt: addr=hannes@mehnert.org; keydata= xsFLBEIw1AoBEADAtXwEV8F1DBpE9lnBTbHDNeZwDVp84MhxxIT5GUexGgbOWGSEWHhC3rYe FfGRUxF4M9P4fwxpxCS5YCvxoijWHeEf8nG5IkztVv5cw63E443XWHcCMc80YAwglZ2cSP4U GTNeKb9rqVPckk/PL348BYRawhzvZK+Bc+bUvbtPCfUXT1BWIxAR1dzsfpAQVNZ4bA06xOoP QJYVNgl/lWOmQgnSgb0dE2zsgddKTOj05ru7Q7LobB7WAUTRJVkZcXnrvI1SOt/WbPTyqF8l RBh94xCqFhv4SlqZVOTXxo9gw3LpDv/cYXRl/m7+/7Wljl3ziQ9cawA6O1mbw8nm7Sfa+TZl qo+5lXEenXG+MCbH0XnnL2I4BO6HSGDtKX6htTG2xs6w4r9mVxTGJuJcGrC0dxuz5j4jylt/ KOVn9IaRKzhj8ga7kWffMp+JYdrn43732weoFFJxm78mD2ij4UbJtNkQIIcTv8IBJajHy2P3 h1NuBIwwb7RmBav4oo0CKWoasIHFwjMSBpCzJ8QOHeO/F3TY3DZp7FTwViUgSXVJoewO9yFG ctX7MC27/F1IonU9/SJW0j+F3Vz32SfxUBrDnLYpO7/vwA8w+xmWLnl0iJN/8injz5+CigsP e7O66t4MtC9BVCuLu7a/ikH5nW0q6RyTW8of9eZIsuEyqF1ZPwAGKc0jSGFubmVzIE1laG5l cnQgPGhhbm5lc0BtZWhuZXJ0Lm9yZz7CwXQEEwECAB4FAkIw1A0CGwMGCwkIBwMCAxUCAwMW AgECHgECF4AACgkQvIlliN98KO5HYg//UD6gk4sFcNop/EQivcnpfPnHrrUddsBl9bovQSXb zIh5HY/8xhO5i87n5Aox9jYLcZwa6HJ3ElHMOa+n9AY4/+H8bd+BiHWTgEhEzcZqcYwyP2S2 0X/e/m/+1XYs5tldKNZb7ruYRv6rNyUAF1H8EtYNaJpmGtXYurkMhWhEgeP9YB7svmkUN+JO og91tNhN1Wd10/JfKIytNcpXmW6zij0f3MJw/kdwIsmfSUMPaiEli+eB7nU0uLZWf4C3MWTT NmwNznEya5K9McH1Wc/lO9+oB+zRXFBUM/v9YaiyPZo0JcwSRdVYKvKteyqnL/lnx7vtkOnA EC/bcmMvlWLI+Q4Vw2cr2FKcIpJVwswZ5snFqgDr4O5JB88aEAzPFzyWWeBlVqXc0DbDu8jD YmG3yp/xn5UJQSRy6eUcXICNjJyIwekUCznRmhtGwkGFCFEZH/s2fQ7nETxZcuiE4meRnVQE 9lOafI5D+dlsG3SlyN1x0YvrPismep7PwA6FX3cDyz2iUUj4xICLvRLU6kq892KuFmv75pop VAZjJMQqc8BG3oN2YkDcO4NEuOT9/r9muk/WH5Mqcs2BJEG6+yiQ13uMS5TxXiPFp3vKRlq0 MFnm7YRZr5aK6B/WGLOHnRRb2OdAzUgsj4Qiyqvh8Ab+x9wjLwGePxlA1akrF2hQItfOwUsE QjDUdAEQAOHG4vdGxU3eH5hYDLYRsQP6ofoU36pV8iFEtZRJ833L5p9GP2xFUGVDH8yTdkdf QR1prsCJXA7sE/gYBf3k9lGicJQmYNo3uW9Ngz787BhiQJyW/JXcutyTt9b/AZmfJaDo1p0C 8IEtoG7wt4+giFwAJ1brTJtyxlKOGcjWiKh1/dTh13muXSOPcCmhNs4Zm0YNjrhW9nIn1iik lpMRJCCxY1RNcU2VZXfTqq63UTaIrZ1lgYXWilnTdpXt5UEDYBw8Ee6tpPfQflC02e8hbDeD JEP9MTM9pmmPOwZQXP36hTryakKt1Kpw3hgC+Yx9q4wwaZ4XIiWUgopT5mlI+LhnzCgO05YN NcPrbsr6Js34gC3odNicD+C1jSdOXCqAPZZNiVx0PBjRv+LbBZhUkjQJxidvXmrp55pLm+Ua IVl3E/HpFY8kTaJBHP7jvLp+W4J9tP64Ijk5Y9F0z93JwMspG671xuomFsRxUtyO6vldd7qH 1yVzDX7Dd0fAzMDOPQJW6zLiixCmA0McaZdeBXapMJDDoZAPY4pCbRyJJXe0tfv9ufzJrM8Z JHylONdBiIKWw0JldXkUvIGafl1JDOHjP1XoDWrSDO8yFhBR3uWxJy9u1s7aKvonQb5IcYU1 nPu1Olg3doPugXyC0V05MIa68iKw+Kv8KtDDWyibndoTAAYpwsFfBBgBAgAJBQJCMNR1AhsM AAoJELyJZYjffCjuelUP/jlCsxLzu3fZpuORY2LsOQMd4nFHSZLUjauLxDUn8jE//32IIJ0v QV9ab4k7JCLOuYJTTd9aYD6rkITZIVhAcsR/FQZNgVOvGTj6tAmNyn385vMz0p4bLOOy5T0C KMLKzzS4Rt4XgtzvH2xDXSHfPsqS/t/5WFkO+aLgcPALldWGQPgRu5DNoCLr989gCGu5vmd4 XwMRBt/LmJGI0v0EypL3eRmlGaUw5k6N1hStu4EETzdikAzXP5KTuloEXq/caYeUs/SIb5zi XVC1ISW0CIwj5ATbMh8DMG4splXCsajtnJjsKJATBZIWV4XoNqtgV+pQn1ShmW36nUfVGqzX AQ+9i/M+CCkxBrb85Bk8I1CA1nBHNk5SQqER40VRp6vcmuxvIBGi6t8dDWsDQ2q3kd4RjjDZ kYjSie7176bb9t5MfUGjA9WckHuyi+vjy3+sC/nRzByhXf+8iZsO2no3xWZkGUWI8F2hhpzW VsXqvC27LZvJk53fJbpuSueN8a7JKfbKPDqoDSsRaEtcM7ig475tqA/ZCzv6mdqhEV5buoLu cpW7UgYzjNQQXeYZygGWc7FTV3dqLmF1MY2+RlydQbUDjcj1CJ+UmKyxgoLyf7ru0sznr7Tp K4WDnVeJdWX1mqoSupF/u5LON1vpzh3OIl5NNAuV68Hb5On/ALC+DwFX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hey, thanks for your feedback. The feedback is very positive for this change. Thomas mentioned we should avoid `~deps:[ dep noop ]` and automatically insert a delay unit argument (to Unikernel.start) if needed. I did so in the mirage PR (https://github.com/mirage/mirage/pull/1599/commits/c92714f934592ff8ff61bc81028fe77235ed158a) printing a message on console that this was done. The mirage-skeleton changes now look even cleaner. Unless there's some objection, I'd really like to push this forward. We can of course fix issues and clean up the code thereafter. Best, Hannes On 22/01/2025 10:04, pierre.alain@tuta.io wrote: > Jan 21, 2025, 23:48 by hannes@mehnert.org: > >> Dear everyone, >> >> as discussed on the retreat last year, and in May 2024 on this list, and further in the Mirage issue tracker, finally I went through the quite large corpus of packages to provide a showcase how this will look like (including working mirage-skeleton unikernels). >> >> So, if you haven't followed the discussion, the idea is to use the linking trick (where we use an OCaml interface for compilation, and when linking we provide the "right" implementation) -- so our libraries do not need to be concerned about the actual implementation. We use this for defining the interfaces for Mirage_sleep, Mirage_mtime, Mirage_ptime, and also for Mirage_crypto_rng -- previously we already applied this for Mirage_bootvar. >> >> The result is that we no longer need to functorize over the TIME/PCLOCK/MCLOCK/RANDOM "devices" in each unikernel. >> >> Et voila, take a deep breath and look at the diff (ignoring whitespaces) https://github.com/mirage/mirage-skeleton/pull/407/files?w=1 of our mirage-skeleton example unikernel repository. >> >> More details are in https://github.com/mirage/mirage/pull/1599, and even more in the individual packages https://github.com/hannesm/mirage-time-defunctorised (also https://github.com/mirage/mirage-sleep https://github.com/mirage/mirage-mtime https://github.com/mirage/mirage-ptime). >> >> It would be lovely to hear your thoughts on this. If it is positive, I'm keen to open PRs and cut releases while the code is still hot, since otherwise we may suffer from bitrot again. >> >> > Dear Hannes, > > Thank for that huge work! > > I'm really a huge fan for this move! From my POV, reading the code is not more difficult as before (I might say even easier :) ), and so I completely approve to merge the different PRs before time ran out and made them bitroted :) > > Best, > Pierre > From mirageos-devel-bounces@lists.xenproject.org Wed Feb 05 09:37:07 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 05 Feb 2025 09:37:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.882022.1292188 (Exim 4.92) (envelope-from ) id 1tfbq4-0004PW-2w; Wed, 05 Feb 2025 09:36:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 882022.1292188; Wed, 05 Feb 2025 09:36:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tfbq3-0004PP-Vx; Wed, 05 Feb 2025 09:36:55 +0000 Received: by outflank-mailman (input) for mailman id 882022; Wed, 05 Feb 2025 09:36:54 +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 1tfbq2-0004PJ-AR for mirageos-devel@lists.xenproject.org; Wed, 05 Feb 2025 09:36:54 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ba0024eb-e3a4-11ef-a0e7-8be0dac302b0; Wed, 05 Feb 2025 10:36:51 +0100 (CET) Received: from [192.168.42.80] (i5C74C2A7.versanet.de [92.116.194.167]) (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 AB3F3EBBC for ; Wed, 5 Feb 2025 10:36:49 +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: ba0024eb-e3a4-11ef-a0e7-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mehnert.org; s=mail; t=1738748209; bh=Ic+RULklVJL3jGJxJfukS9AvE9qaE6a8BZ2jysqHDis=; h=Date:Subject:To:References:From:In-Reply-To; b=Ct9UJrdJkk6GrKEB5FZz+d1CAXbIP0jcaXMlRhGLMYFf3RcikxE1/hV+uQE609Mwg LbUoVgbZtkkbUrOWSIwa/tuM+Ug1xYeqP5HJwiGiUFWFYDh9RL/sIX+ZYPdJqoPDVf P6BpVS/imbIuCcjp3O/oDcofZAJecFYoyuwPGyR/r+20JQqJaYVpGQ71Yf+iS0V5Oj f7Quh3Zmxugh6tPFsmBe1Mr2FKyw5hKuttL0/CbqdFwcpsio6HPEruU8PWoMsdQEIK w5kNMNSQXmxJUYGex2wBeEp8m6UOEAOdUvMJc8IWwKJfeAP84f7XL7Wrpn+hoRVSYA 9NTnApEqa6qBA== Message-ID: Date: Wed, 5 Feb 2025 10:36:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: next meeting: Monday Feb 10, 10:00 - 12:00 CET Content-Language: en-US To: mirageos-devel@lists.xenproject.org References: <3ebfc6e3-aeda-4729-a63d-02c139827945@mehnert.org> <70fbf854-41b5-4ba3-bb78-1f80548e88d6@mehnert.org> <0602b9f7-c549-45e5-8ecc-961afc22a9ec@mehnert.org> <6150A039-59F3-478C-8783-50AE3C22E04E@cl.cam.ac.uk> From: Hannes Mehnert Autocrypt: addr=hannes@mehnert.org; keydata= xsFLBEIw1AoBEADAtXwEV8F1DBpE9lnBTbHDNeZwDVp84MhxxIT5GUexGgbOWGSEWHhC3rYe FfGRUxF4M9P4fwxpxCS5YCvxoijWHeEf8nG5IkztVv5cw63E443XWHcCMc80YAwglZ2cSP4U GTNeKb9rqVPckk/PL348BYRawhzvZK+Bc+bUvbtPCfUXT1BWIxAR1dzsfpAQVNZ4bA06xOoP QJYVNgl/lWOmQgnSgb0dE2zsgddKTOj05ru7Q7LobB7WAUTRJVkZcXnrvI1SOt/WbPTyqF8l RBh94xCqFhv4SlqZVOTXxo9gw3LpDv/cYXRl/m7+/7Wljl3ziQ9cawA6O1mbw8nm7Sfa+TZl qo+5lXEenXG+MCbH0XnnL2I4BO6HSGDtKX6htTG2xs6w4r9mVxTGJuJcGrC0dxuz5j4jylt/ KOVn9IaRKzhj8ga7kWffMp+JYdrn43732weoFFJxm78mD2ij4UbJtNkQIIcTv8IBJajHy2P3 h1NuBIwwb7RmBav4oo0CKWoasIHFwjMSBpCzJ8QOHeO/F3TY3DZp7FTwViUgSXVJoewO9yFG ctX7MC27/F1IonU9/SJW0j+F3Vz32SfxUBrDnLYpO7/vwA8w+xmWLnl0iJN/8injz5+CigsP e7O66t4MtC9BVCuLu7a/ikH5nW0q6RyTW8of9eZIsuEyqF1ZPwAGKc0jSGFubmVzIE1laG5l cnQgPGhhbm5lc0BtZWhuZXJ0Lm9yZz7CwXQEEwECAB4FAkIw1A0CGwMGCwkIBwMCAxUCAwMW AgECHgECF4AACgkQvIlliN98KO5HYg//UD6gk4sFcNop/EQivcnpfPnHrrUddsBl9bovQSXb zIh5HY/8xhO5i87n5Aox9jYLcZwa6HJ3ElHMOa+n9AY4/+H8bd+BiHWTgEhEzcZqcYwyP2S2 0X/e/m/+1XYs5tldKNZb7ruYRv6rNyUAF1H8EtYNaJpmGtXYurkMhWhEgeP9YB7svmkUN+JO og91tNhN1Wd10/JfKIytNcpXmW6zij0f3MJw/kdwIsmfSUMPaiEli+eB7nU0uLZWf4C3MWTT NmwNznEya5K9McH1Wc/lO9+oB+zRXFBUM/v9YaiyPZo0JcwSRdVYKvKteyqnL/lnx7vtkOnA EC/bcmMvlWLI+Q4Vw2cr2FKcIpJVwswZ5snFqgDr4O5JB88aEAzPFzyWWeBlVqXc0DbDu8jD YmG3yp/xn5UJQSRy6eUcXICNjJyIwekUCznRmhtGwkGFCFEZH/s2fQ7nETxZcuiE4meRnVQE 9lOafI5D+dlsG3SlyN1x0YvrPismep7PwA6FX3cDyz2iUUj4xICLvRLU6kq892KuFmv75pop VAZjJMQqc8BG3oN2YkDcO4NEuOT9/r9muk/WH5Mqcs2BJEG6+yiQ13uMS5TxXiPFp3vKRlq0 MFnm7YRZr5aK6B/WGLOHnRRb2OdAzUgsj4Qiyqvh8Ab+x9wjLwGePxlA1akrF2hQItfOwUsE QjDUdAEQAOHG4vdGxU3eH5hYDLYRsQP6ofoU36pV8iFEtZRJ833L5p9GP2xFUGVDH8yTdkdf QR1prsCJXA7sE/gYBf3k9lGicJQmYNo3uW9Ngz787BhiQJyW/JXcutyTt9b/AZmfJaDo1p0C 8IEtoG7wt4+giFwAJ1brTJtyxlKOGcjWiKh1/dTh13muXSOPcCmhNs4Zm0YNjrhW9nIn1iik lpMRJCCxY1RNcU2VZXfTqq63UTaIrZ1lgYXWilnTdpXt5UEDYBw8Ee6tpPfQflC02e8hbDeD JEP9MTM9pmmPOwZQXP36hTryakKt1Kpw3hgC+Yx9q4wwaZ4XIiWUgopT5mlI+LhnzCgO05YN NcPrbsr6Js34gC3odNicD+C1jSdOXCqAPZZNiVx0PBjRv+LbBZhUkjQJxidvXmrp55pLm+Ua IVl3E/HpFY8kTaJBHP7jvLp+W4J9tP64Ijk5Y9F0z93JwMspG671xuomFsRxUtyO6vldd7qH 1yVzDX7Dd0fAzMDOPQJW6zLiixCmA0McaZdeBXapMJDDoZAPY4pCbRyJJXe0tfv9ufzJrM8Z JHylONdBiIKWw0JldXkUvIGafl1JDOHjP1XoDWrSDO8yFhBR3uWxJy9u1s7aKvonQb5IcYU1 nPu1Olg3doPugXyC0V05MIa68iKw+Kv8KtDDWyibndoTAAYpwsFfBBgBAgAJBQJCMNR1AhsM AAoJELyJZYjffCjuelUP/jlCsxLzu3fZpuORY2LsOQMd4nFHSZLUjauLxDUn8jE//32IIJ0v QV9ab4k7JCLOuYJTTd9aYD6rkITZIVhAcsR/FQZNgVOvGTj6tAmNyn385vMz0p4bLOOy5T0C KMLKzzS4Rt4XgtzvH2xDXSHfPsqS/t/5WFkO+aLgcPALldWGQPgRu5DNoCLr989gCGu5vmd4 XwMRBt/LmJGI0v0EypL3eRmlGaUw5k6N1hStu4EETzdikAzXP5KTuloEXq/caYeUs/SIb5zi XVC1ISW0CIwj5ATbMh8DMG4splXCsajtnJjsKJATBZIWV4XoNqtgV+pQn1ShmW36nUfVGqzX AQ+9i/M+CCkxBrb85Bk8I1CA1nBHNk5SQqER40VRp6vcmuxvIBGi6t8dDWsDQ2q3kd4RjjDZ kYjSie7176bb9t5MfUGjA9WckHuyi+vjy3+sC/nRzByhXf+8iZsO2no3xWZkGUWI8F2hhpzW VsXqvC27LZvJk53fJbpuSueN8a7JKfbKPDqoDSsRaEtcM7ig475tqA/ZCzv6mdqhEV5buoLu cpW7UgYzjNQQXeYZygGWc7FTV3dqLmF1MY2+RlydQbUDjcj1CJ+UmKyxgoLyf7ru0sznr7Tp K4WDnVeJdWX1mqoSupF/u5LON1vpzh3OIl5NNAuV68Hb5On/ALC+DwFX In-Reply-To: <6150A039-59F3-478C-8783-50AE3C22E04E@cl.cam.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the discussion, On 03/02/2025 20:45, Anil Madhavapeddy wrote: >> On Feb 3, 2025, at 5:30 PM, Samuel Hym wrote: >> >>> My understanding of the issue was to munmap of a chunk inside an mmapped region, which requires a full mmap/munmap implementation (we don't have currently). I'm not sure where the code that causes the ABORT lives and maybe it can be difficult to trigger the situation? >> >> `abort` would be triggered by a `free(x)` where `x` is not the result >> of a `malloc`. >> As I didn’t manage to create an example using the compactor that would >> run into such a situation and I couldn’t find at which point in the >> code that could be triggered, I reached out to Sadiq. He confirmed >> that our implementation is correct. By "correct", if I understand you correctly, it is "this abort will never be triggered"? >> What happens is that, as pools are allocated by the GC, they will >> probably follow each other in the virtual memory address space; the >> compactor might decide to release a pool in the middle of that >> sequence of pools, so we’ll end up with (coarse-grained) fragmentation >> with our `malloc`/`free` implementation. But it will be valid >> nevertheless! I don't quite understand the impact of that paragraph. "it will be valid nevertheless" - does this mean, we won't run into the "abort()"? > My suggestion to Sadiq when we were discussing the compactor a few months ago was to not reinvent the wheel but to use https://github.com/microsoft/mimalloc instead. It's a state of the art malloc implementation with a very easy integration path to be directly embedded into a Mirage runtime. I think it would probably work out better than using a generic libc malloc in Unikraft (and certainly better than newlib's malloc implementation). "work out better than using a generic libc malloc" - I'm sure this is a low-hanging optimization fruit -- at the moment, ocaml-solo5 uses dlmalloc (I'm not sure what Unikraft uses, neither what "newlib's malloc implementation" refers to). If I remember, Pierre did some experiments with another kind of malloc, mainly to hunt a memory issue for Xen? Of course, a full-blown jemalloc (https://github.com/jemalloc/jemalloc) may as well be beneficial in terms of performance. To me, the underlying question is about the tradeoff between code size and performance -- and performance should be taken into account with a concrete (unikernel) example [plus the variance in terms of bytes vs Bigarray, and allocation strategies]. > I put together a quick tree last year that just directly vendored mimalloc, and the integration was pretty straightforward. As always, 80% of the effort will be in the build system integration, which I didn't do ;-) True. Hannes From mirageos-devel-bounces@lists.xenproject.org Wed Feb 05 16:49:26 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 05 Feb 2025 16:49:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.882242.1292403 (Exim 4.92) (envelope-from ) id 1tfiaR-00011l-Ud; Wed, 05 Feb 2025 16:49:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 882242.1292403; Wed, 05 Feb 2025 16:49:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tfiaR-00011e-RY; Wed, 05 Feb 2025 16:49:15 +0000 Received: by outflank-mailman (input) for mailman id 882242; Wed, 05 Feb 2025 16:49:15 +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 1tfiaQ-00011Y-Rn for mirageos-devel@lists.xenproject.org; Wed, 05 Feb 2025 16:49:15 +0000 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [2607:f8b0:4864:20::12c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 20927170-e3e1-11ef-a0e7-8be0dac302b0; Wed, 05 Feb 2025 17:49:13 +0100 (CET) Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-3d01fe20598so18239535ab.3 for ; Wed, 05 Feb 2025 08:49:13 -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: 20927170-e3e1-11ef-a0e7-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tarides-com.20230601.gappssmtp.com; s=20230601; t=1738774152; x=1739378952; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4y67FSEo4FRuAWFtEefDbG120yQcy8JpUgSf3tN4P1A=; b=v3o13ywUtv52Duru3ecjG7jpJcqGu3Vo5gWpXOJZENBJX2OCRsXwGEgvsWL4Pq+9lJ DAHu5afRaZF6BJs3IN5OiAJ2P58BOhFVnZnCz93fsGkVyH40ZrGPINSEHeUh44BFYIhl KvMIiqIs+viqjdRoeYLZnfA3gFRNHCFqCJhrqmQxgtkvCCy3Z6cZhULYGK+8SXLi3J3t TZtNpr69G+tK6p4Z4EtKWG8ALd8MZ0L7lEhRC1w4NDZ6nTomTtwbzLM2k0c/2u3w+Mff C2hZ2kKWt2kgt5YXFqYgvu/NiRjjB4NOEoKpaTZTZbWFOAEYGMeT/1bWnPRuxAEJWyqY 3TWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738774152; x=1739378952; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4y67FSEo4FRuAWFtEefDbG120yQcy8JpUgSf3tN4P1A=; b=pfMnimTyOVKMeGcdON4+Vv1Zjux23YTpwJ7JN129kmq5iLWkSkqkbc1+SHn+1C2rc8 A613A37qANgmOXqtR/VwKmvOMVXLirb4lxvm7Fg+psLamszbx3imvvuYnrvF2rn3QzKv bREO2+8HZTNihH7l0EiK0F5egwOsQ+v1NDCYE0DZK0Z51usTp+yrTzyORhzr3x/w3HKd 4BIuXUbT10+HEUiEq+Xwq9jGaEwyUb0geEFvjH/2BB1klK61UZ00gCHH61YxybGdqE+a oLidQM/wgVb7vJ/WpyvpCgU25QtqU0ks2pZ11l/dngDrlJfqgcHi/MsaS1zCm2RDAkGI PmNA== X-Gm-Message-State: AOJu0YyTk0DtSG01RHK967eYUDzexvwZk11VzH3+zN31Gd1S0W/nDfDW 95A7VArnMOF+AdU1ty0aK0zzBWqh/ZN+2FIQC7JT7f3HnJxaA8hHna0bO3I/Mhh3F5yTYcfMvKi tfOX1288Gd4fAWquwbFxM0cnttf2M4vq52rotuOG0ZWZJEvy0M4k= X-Gm-Gg: ASbGncvWr9QxdEwk44ghX5XCB6NTwudPdRLEL8u926sOOF3iLUX5YEuYwIPs85HjeTW r/k+BQzLRJd9FkrMN7J5s0hOh3ImVACmx0Mv2zfEFQCpUy6CfCvySkPDUlrp+DJl3B2KgiCu0Bg == X-Google-Smtp-Source: AGHT+IH4l7ZbzlG9BHEFUhHig97gvzJHrQ3t3u//2yWhWcNo0fLXKFvZiGnQ79uEk/lZF2pitWy7+DXrHmCRGuZ1CuM= X-Received: by 2002:a05:6e02:b4d:b0:3cf:f8de:7662 with SMTP id e9e14a558f8ab-3d04f8f6c8dmr34824865ab.18.1738774151934; Wed, 05 Feb 2025 08:49:11 -0800 (PST) MIME-Version: 1.0 References: <3ebfc6e3-aeda-4729-a63d-02c139827945@mehnert.org> <70fbf854-41b5-4ba3-bb78-1f80548e88d6@mehnert.org> <0602b9f7-c549-45e5-8ecc-961afc22a9ec@mehnert.org> <6150A039-59F3-478C-8783-50AE3C22E04E@cl.cam.ac.uk> In-Reply-To: From: Samuel Hym Date: Wed, 5 Feb 2025 17:48:56 +0100 X-Gm-Features: AWEUYZmhTMxz5uHmAHiTpQN6Mm4dt0UnrZwLO4jBfTRqpokwo2Sb_gMXeOOqm6M Message-ID: Subject: Re: next meeting: Monday Feb 10, 10:00 - 12:00 CET To: Hannes Mehnert Cc: mirageos-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Le 05 f=C3=A9vrier 2025 =C3=A0 10h36, Hannes Mehnert disait : > > > He confirmed that our implementation is correct. > > By "correct", if I understand you correctly, it is "this abort will never= be > triggered"? That=E2=80=99s what I meant, indeed. > > > What happens is that, as pools are allocated by the GC, they will > > > probably follow each other in the virtual memory address space; the > > > compactor might decide to release a pool in the middle of that > > > sequence of pools, so we=E2=80=99ll end up with (coarse-grained) frag= mentation > > > with our `malloc`/`free` implementation. But it will be valid > > > nevertheless! > > I don't quite understand the impact of that paragraph. "it will be valid > nevertheless" - does this mean, we won't run into the "abort()"? Yes, no `abort`. I was just underlining the fact that it won=E2=80=99t compact our memory completely, as far as our `malloc`/`free` will see it. > (I'm not sure what Unikraft uses, neither what "newlib's malloc > implementation" refers to). Unikraft comes with various implementations, including a buddy allocator coming from Xen. > To me, the underlying question is about the tradeoff between code size an= d > performance -- and performance should be taken into account with a concre= te > (unikernel) example [plus the variance in terms of bytes vs Bigarray, and > allocation strategies]. Indeed! --=20 Samuel From mirageos-devel-bounces@lists.xenproject.org Mon Feb 10 10:13:16 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 10 Feb 2025 10:13:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.884531.1294237 (Exim 4.92) (envelope-from ) id 1thQmn-0000A6-S4; Mon, 10 Feb 2025 10:13:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 884531.1294237; Mon, 10 Feb 2025 10:13:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1thQmn-00009x-P4; Mon, 10 Feb 2025 10:13:05 +0000 Received: by outflank-mailman (input) for mailman id 884531; Mon, 10 Feb 2025 10:13:04 +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 1thQml-00009o-RE for mirageos-devel@lists.xenproject.org; Mon, 10 Feb 2025 10:13:04 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9b05f940-e797-11ef-a075-877d107080fb; Mon, 10 Feb 2025 11:13:01 +0100 (CET) Received: from [192.168.42.80] (i5C74C22D.versanet.de [92.116.194.45]) (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 41EEB5DCC for ; Mon, 10 Feb 2025 11:12:59 +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: 9b05f940-e797-11ef-a075-877d107080fb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mehnert.org; s=mail; t=1739182379; bh=UyRm/RKopNyTC4zKCqM6S+vnICskrUg7qHsfc/2Obqk=; h=Date:Subject:To:References:From:In-Reply-To; b=bGR3YjoXSMHH5NU5L49YZx7e20lQgUfCbSc1vSMcnRaJKoy1LvlFaracTjRCTj29Y ureWfmxQY0x1pEWWHCkI+STrcuYQ8TXvzQ1j9k11WFx83UJxVVT8ZBVPjmL+8Mw7G4 f/rHjkMxgZjNIEELpmOxqFlEnYVyAVHHTpjU1iDTXA/fIlFPJJbcKpxCW5wj1p1lcV KifezsQ4wlGWtW1GFD07BVKezFLhUlwanJ8IAhooM4zGp4NfyueCNH9AUQ2ZiGpVAF UwSglS1LBeyd9lylSBe9PC+k5sxIZpAUT7HnAPkdH+DKZlrSiLfq+eE8LWpzSKP56o iYOwWk6Xc9/yQ== Message-ID: <11c179c3-f9a4-4d87-b292-33a33ce2ef35@mehnert.org> Date: Mon, 10 Feb 2025 11:12:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: troubleshooting problems with opam-monorepo Content-Language: en-US To: mirageos-devel@lists.xenproject.org References: From: Hannes Mehnert Autocrypt: addr=hannes@mehnert.org; keydata= xsFLBEIw1AoBEADAtXwEV8F1DBpE9lnBTbHDNeZwDVp84MhxxIT5GUexGgbOWGSEWHhC3rYe FfGRUxF4M9P4fwxpxCS5YCvxoijWHeEf8nG5IkztVv5cw63E443XWHcCMc80YAwglZ2cSP4U GTNeKb9rqVPckk/PL348BYRawhzvZK+Bc+bUvbtPCfUXT1BWIxAR1dzsfpAQVNZ4bA06xOoP QJYVNgl/lWOmQgnSgb0dE2zsgddKTOj05ru7Q7LobB7WAUTRJVkZcXnrvI1SOt/WbPTyqF8l RBh94xCqFhv4SlqZVOTXxo9gw3LpDv/cYXRl/m7+/7Wljl3ziQ9cawA6O1mbw8nm7Sfa+TZl qo+5lXEenXG+MCbH0XnnL2I4BO6HSGDtKX6htTG2xs6w4r9mVxTGJuJcGrC0dxuz5j4jylt/ KOVn9IaRKzhj8ga7kWffMp+JYdrn43732weoFFJxm78mD2ij4UbJtNkQIIcTv8IBJajHy2P3 h1NuBIwwb7RmBav4oo0CKWoasIHFwjMSBpCzJ8QOHeO/F3TY3DZp7FTwViUgSXVJoewO9yFG ctX7MC27/F1IonU9/SJW0j+F3Vz32SfxUBrDnLYpO7/vwA8w+xmWLnl0iJN/8injz5+CigsP e7O66t4MtC9BVCuLu7a/ikH5nW0q6RyTW8of9eZIsuEyqF1ZPwAGKc0jSGFubmVzIE1laG5l cnQgPGhhbm5lc0BtZWhuZXJ0Lm9yZz7CwXQEEwECAB4FAkIw1A0CGwMGCwkIBwMCAxUCAwMW AgECHgECF4AACgkQvIlliN98KO5HYg//UD6gk4sFcNop/EQivcnpfPnHrrUddsBl9bovQSXb zIh5HY/8xhO5i87n5Aox9jYLcZwa6HJ3ElHMOa+n9AY4/+H8bd+BiHWTgEhEzcZqcYwyP2S2 0X/e/m/+1XYs5tldKNZb7ruYRv6rNyUAF1H8EtYNaJpmGtXYurkMhWhEgeP9YB7svmkUN+JO og91tNhN1Wd10/JfKIytNcpXmW6zij0f3MJw/kdwIsmfSUMPaiEli+eB7nU0uLZWf4C3MWTT NmwNznEya5K9McH1Wc/lO9+oB+zRXFBUM/v9YaiyPZo0JcwSRdVYKvKteyqnL/lnx7vtkOnA EC/bcmMvlWLI+Q4Vw2cr2FKcIpJVwswZ5snFqgDr4O5JB88aEAzPFzyWWeBlVqXc0DbDu8jD YmG3yp/xn5UJQSRy6eUcXICNjJyIwekUCznRmhtGwkGFCFEZH/s2fQ7nETxZcuiE4meRnVQE 9lOafI5D+dlsG3SlyN1x0YvrPismep7PwA6FX3cDyz2iUUj4xICLvRLU6kq892KuFmv75pop VAZjJMQqc8BG3oN2YkDcO4NEuOT9/r9muk/WH5Mqcs2BJEG6+yiQ13uMS5TxXiPFp3vKRlq0 MFnm7YRZr5aK6B/WGLOHnRRb2OdAzUgsj4Qiyqvh8Ab+x9wjLwGePxlA1akrF2hQItfOwUsE QjDUdAEQAOHG4vdGxU3eH5hYDLYRsQP6ofoU36pV8iFEtZRJ833L5p9GP2xFUGVDH8yTdkdf QR1prsCJXA7sE/gYBf3k9lGicJQmYNo3uW9Ngz787BhiQJyW/JXcutyTt9b/AZmfJaDo1p0C 8IEtoG7wt4+giFwAJ1brTJtyxlKOGcjWiKh1/dTh13muXSOPcCmhNs4Zm0YNjrhW9nIn1iik lpMRJCCxY1RNcU2VZXfTqq63UTaIrZ1lgYXWilnTdpXt5UEDYBw8Ee6tpPfQflC02e8hbDeD JEP9MTM9pmmPOwZQXP36hTryakKt1Kpw3hgC+Yx9q4wwaZ4XIiWUgopT5mlI+LhnzCgO05YN NcPrbsr6Js34gC3odNicD+C1jSdOXCqAPZZNiVx0PBjRv+LbBZhUkjQJxidvXmrp55pLm+Ua IVl3E/HpFY8kTaJBHP7jvLp+W4J9tP64Ijk5Y9F0z93JwMspG671xuomFsRxUtyO6vldd7qH 1yVzDX7Dd0fAzMDOPQJW6zLiixCmA0McaZdeBXapMJDDoZAPY4pCbRyJJXe0tfv9ufzJrM8Z JHylONdBiIKWw0JldXkUvIGafl1JDOHjP1XoDWrSDO8yFhBR3uWxJy9u1s7aKvonQb5IcYU1 nPu1Olg3doPugXyC0V05MIa68iKw+Kv8KtDDWyibndoTAAYpwsFfBBgBAgAJBQJCMNR1AhsM AAoJELyJZYjffCjuelUP/jlCsxLzu3fZpuORY2LsOQMd4nFHSZLUjauLxDUn8jE//32IIJ0v QV9ab4k7JCLOuYJTTd9aYD6rkITZIVhAcsR/FQZNgVOvGTj6tAmNyn385vMz0p4bLOOy5T0C KMLKzzS4Rt4XgtzvH2xDXSHfPsqS/t/5WFkO+aLgcPALldWGQPgRu5DNoCLr989gCGu5vmd4 XwMRBt/LmJGI0v0EypL3eRmlGaUw5k6N1hStu4EETzdikAzXP5KTuloEXq/caYeUs/SIb5zi XVC1ISW0CIwj5ATbMh8DMG4splXCsajtnJjsKJATBZIWV4XoNqtgV+pQn1ShmW36nUfVGqzX AQ+9i/M+CCkxBrb85Bk8I1CA1nBHNk5SQqER40VRp6vcmuxvIBGi6t8dDWsDQ2q3kd4RjjDZ kYjSie7176bb9t5MfUGjA9WckHuyi+vjy3+sC/nRzByhXf+8iZsO2no3xWZkGUWI8F2hhpzW VsXqvC27LZvJk53fJbpuSueN8a7JKfbKPDqoDSsRaEtcM7ig475tqA/ZCzv6mdqhEV5buoLu cpW7UgYzjNQQXeYZygGWc7FTV3dqLmF1MY2+RlydQbUDjcj1CJ+UmKyxgoLyf7ru0sznr7Tp K4WDnVeJdWX1mqoSupF/u5LON1vpzh3OIl5NNAuV68Hb5On/ALC+DwFX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 22/01/2025 18:11, Mindy Preston wrote: > Over the past few months, I have occasionally attempted to build some MirageOS projects but very frequently I encounter some time-consuming or work-halting problem with opam-monorepo, often a problem which seems non-deterministic. I have a few questions: > > (1) is this brittle for other people? Perhaps there’s something about the environments where I’ve tried this (arch linux on aarch64, ubuntu and a close cousin on x86_64, recent opam, vanilla compiler) that’s problem-prone? Is it possible that build steps involving opam-monorepo might cause inconsistent state if interrupted before completing, which is something I do all the time? It is brittle for me as well, over the years I opened various issues and there's not much opam-monorepo activity unfortunately. The latest issue I encounter is https://github.com/tarides/opam-monorepo/issues/406 -- and my workaround was to point my opam repository to something before 5.3: opam repository set-url default git+https://github.com/ocaml/opam-repository.git#2e81d1953c37347d78d994b71ede87c5f6f6e207 The running the `make lock pull` showed me some other error I was able to fix, and voila re-setting my opam-repository to opam repository set-url default https://opam.ocaml.org Worked than fine. But as you mention, it is very very brittle. In combination with very confusing error messages. > (3) I often work on a library and a unikernel that uses it in tandem, so the `scope` argument to package config is essential, but I had to go digging in functoria .mli’s to find it. Is there documentation that I should have read about this? If so, I will go read it and maybe that will enlighten me. I never use the "scope" argument. > I’ve also tripped over things that are already in issue trackers like ‘mirage clean’ not cleaning out the duniverse directory and the current problem with OCaml 5.3.0 not being usable at all. After looking into the latter problem, I’m worried about the maintenance status of `opam-monorepo` and the `opam-overlays` repository it uses. The last commits were some time ago for both repositories, and it doesn’t look like there are replies to recent issues and PRs. True. Sad story. Maybe time to find a different path. All we need is customly-built C stubs -- no need for recompiling all OCaml code for a unikernel. Eventually there are better ways than this "opam-monorepo". (Hint: there's https://github.com/mirage/ocaml-solo5/pull/144/commits/3eb1861fad33abc895a581521cd20d77247a0bf9 paving the way... but we still need some mechanism to tag packages that require building with the MirageOS/OCaml C cross-compiler.) Of course, help (in terms of bugfixes, triaging issues, updating the dune-opam-overlays) are very welcome. Hannes From mirageos-devel-bounces@lists.xenproject.org Mon Feb 10 12:08:15 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 10 Feb 2025 12:08:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.884859.1294602 (Exim 4.92) (envelope-from ) id 1thSa6-0005w8-Sx; Mon, 10 Feb 2025 12:08:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 884859.1294602; Mon, 10 Feb 2025 12:08:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1thSa6-0005w1-Q9; Mon, 10 Feb 2025 12:08:06 +0000 Received: by outflank-mailman (input) for mailman id 884859; Mon, 10 Feb 2025 12:08:05 +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 1thSa4-0005vv-KM for mirageos-devel@lists.xenproject.org; Mon, 10 Feb 2025 12:08:05 +0000 Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ad7fe9f6-e7a7-11ef-a075-877d107080fb; Mon, 10 Feb 2025 13:08:03 +0100 (CET) Received: from [192.168.42.80] (i5C74C22D.versanet.de [92.116.194.45]) (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 0AC74728E for ; Mon, 10 Feb 2025 13:08:02 +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: ad7fe9f6-e7a7-11ef-a075-877d107080fb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mehnert.org; s=mail; t=1739189282; bh=7YfOHDIJU9yjkbgM8yvIeY3/oJYKibBxjA08EYe/nEQ=; h=Date:Subject:To:References:From:In-Reply-To; b=p86Li5x0eJuPKzRoVu5Un4jgzn85yCT9EoKUpw58rmNsE+YmFznVrOH2EUHv/ZQ7u JprVV3e+g7hy0rdfclSI1TUx2zk8c1y3rUDyh7POA8C6k5+FJDuUb8FKlRj+LRlPDi HMLxWDGF9EbsSYtbCqCmoEG9P7QibPwxoQQ7glZeJaSwqhrbEolhEMQ5OuVvL+uO33 V80VOUSDaYRzqcb89tJxr8c7cS5Otxbx4Qwm5LLN5FONdAP1DVO+UQ7cjOfT1CYQuy BojO+G1OpTqeD9XLbGNntXkCpz0RGJW49/MmVHFP5uXBR3UVhVJTlyWtkld1bpemw6 fuFD4hiIF1sXA== Message-ID: Date: Mon, 10 Feb 2025 13:08:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: troubleshooting problems with opam-monorepo Content-Language: en-US To: mirageos-devel@lists.xenproject.org References: <11c179c3-f9a4-4d87-b292-33a33ce2ef35@mehnert.org> From: Hannes Mehnert Autocrypt: addr=hannes@mehnert.org; keydata= xsFLBEIw1AoBEADAtXwEV8F1DBpE9lnBTbHDNeZwDVp84MhxxIT5GUexGgbOWGSEWHhC3rYe FfGRUxF4M9P4fwxpxCS5YCvxoijWHeEf8nG5IkztVv5cw63E443XWHcCMc80YAwglZ2cSP4U GTNeKb9rqVPckk/PL348BYRawhzvZK+Bc+bUvbtPCfUXT1BWIxAR1dzsfpAQVNZ4bA06xOoP QJYVNgl/lWOmQgnSgb0dE2zsgddKTOj05ru7Q7LobB7WAUTRJVkZcXnrvI1SOt/WbPTyqF8l RBh94xCqFhv4SlqZVOTXxo9gw3LpDv/cYXRl/m7+/7Wljl3ziQ9cawA6O1mbw8nm7Sfa+TZl qo+5lXEenXG+MCbH0XnnL2I4BO6HSGDtKX6htTG2xs6w4r9mVxTGJuJcGrC0dxuz5j4jylt/ KOVn9IaRKzhj8ga7kWffMp+JYdrn43732weoFFJxm78mD2ij4UbJtNkQIIcTv8IBJajHy2P3 h1NuBIwwb7RmBav4oo0CKWoasIHFwjMSBpCzJ8QOHeO/F3TY3DZp7FTwViUgSXVJoewO9yFG ctX7MC27/F1IonU9/SJW0j+F3Vz32SfxUBrDnLYpO7/vwA8w+xmWLnl0iJN/8injz5+CigsP e7O66t4MtC9BVCuLu7a/ikH5nW0q6RyTW8of9eZIsuEyqF1ZPwAGKc0jSGFubmVzIE1laG5l cnQgPGhhbm5lc0BtZWhuZXJ0Lm9yZz7CwXQEEwECAB4FAkIw1A0CGwMGCwkIBwMCAxUCAwMW AgECHgECF4AACgkQvIlliN98KO5HYg//UD6gk4sFcNop/EQivcnpfPnHrrUddsBl9bovQSXb zIh5HY/8xhO5i87n5Aox9jYLcZwa6HJ3ElHMOa+n9AY4/+H8bd+BiHWTgEhEzcZqcYwyP2S2 0X/e/m/+1XYs5tldKNZb7ruYRv6rNyUAF1H8EtYNaJpmGtXYurkMhWhEgeP9YB7svmkUN+JO og91tNhN1Wd10/JfKIytNcpXmW6zij0f3MJw/kdwIsmfSUMPaiEli+eB7nU0uLZWf4C3MWTT NmwNznEya5K9McH1Wc/lO9+oB+zRXFBUM/v9YaiyPZo0JcwSRdVYKvKteyqnL/lnx7vtkOnA EC/bcmMvlWLI+Q4Vw2cr2FKcIpJVwswZ5snFqgDr4O5JB88aEAzPFzyWWeBlVqXc0DbDu8jD YmG3yp/xn5UJQSRy6eUcXICNjJyIwekUCznRmhtGwkGFCFEZH/s2fQ7nETxZcuiE4meRnVQE 9lOafI5D+dlsG3SlyN1x0YvrPismep7PwA6FX3cDyz2iUUj4xICLvRLU6kq892KuFmv75pop VAZjJMQqc8BG3oN2YkDcO4NEuOT9/r9muk/WH5Mqcs2BJEG6+yiQ13uMS5TxXiPFp3vKRlq0 MFnm7YRZr5aK6B/WGLOHnRRb2OdAzUgsj4Qiyqvh8Ab+x9wjLwGePxlA1akrF2hQItfOwUsE QjDUdAEQAOHG4vdGxU3eH5hYDLYRsQP6ofoU36pV8iFEtZRJ833L5p9GP2xFUGVDH8yTdkdf QR1prsCJXA7sE/gYBf3k9lGicJQmYNo3uW9Ngz787BhiQJyW/JXcutyTt9b/AZmfJaDo1p0C 8IEtoG7wt4+giFwAJ1brTJtyxlKOGcjWiKh1/dTh13muXSOPcCmhNs4Zm0YNjrhW9nIn1iik lpMRJCCxY1RNcU2VZXfTqq63UTaIrZ1lgYXWilnTdpXt5UEDYBw8Ee6tpPfQflC02e8hbDeD JEP9MTM9pmmPOwZQXP36hTryakKt1Kpw3hgC+Yx9q4wwaZ4XIiWUgopT5mlI+LhnzCgO05YN NcPrbsr6Js34gC3odNicD+C1jSdOXCqAPZZNiVx0PBjRv+LbBZhUkjQJxidvXmrp55pLm+Ua IVl3E/HpFY8kTaJBHP7jvLp+W4J9tP64Ijk5Y9F0z93JwMspG671xuomFsRxUtyO6vldd7qH 1yVzDX7Dd0fAzMDOPQJW6zLiixCmA0McaZdeBXapMJDDoZAPY4pCbRyJJXe0tfv9ufzJrM8Z JHylONdBiIKWw0JldXkUvIGafl1JDOHjP1XoDWrSDO8yFhBR3uWxJy9u1s7aKvonQb5IcYU1 nPu1Olg3doPugXyC0V05MIa68iKw+Kv8KtDDWyibndoTAAYpwsFfBBgBAgAJBQJCMNR1AhsM AAoJELyJZYjffCjuelUP/jlCsxLzu3fZpuORY2LsOQMd4nFHSZLUjauLxDUn8jE//32IIJ0v QV9ab4k7JCLOuYJTTd9aYD6rkITZIVhAcsR/FQZNgVOvGTj6tAmNyn385vMz0p4bLOOy5T0C KMLKzzS4Rt4XgtzvH2xDXSHfPsqS/t/5WFkO+aLgcPALldWGQPgRu5DNoCLr989gCGu5vmd4 XwMRBt/LmJGI0v0EypL3eRmlGaUw5k6N1hStu4EETzdikAzXP5KTuloEXq/caYeUs/SIb5zi XVC1ISW0CIwj5ATbMh8DMG4splXCsajtnJjsKJATBZIWV4XoNqtgV+pQn1ShmW36nUfVGqzX AQ+9i/M+CCkxBrb85Bk8I1CA1nBHNk5SQqER40VRp6vcmuxvIBGi6t8dDWsDQ2q3kd4RjjDZ kYjSie7176bb9t5MfUGjA9WckHuyi+vjy3+sC/nRzByhXf+8iZsO2no3xWZkGUWI8F2hhpzW VsXqvC27LZvJk53fJbpuSueN8a7JKfbKPDqoDSsRaEtcM7ig475tqA/ZCzv6mdqhEV5buoLu cpW7UgYzjNQQXeYZygGWc7FTV3dqLmF1MY2+RlydQbUDjcj1CJ+UmKyxgoLyf7ru0sznr7Tp K4WDnVeJdWX1mqoSupF/u5LON1vpzh3OIl5NNAuV68Hb5On/ALC+DwFX In-Reply-To: <11c179c3-f9a4-4d87-b292-33a33ce2ef35@mehnert.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit With the hope some opam-monorepo maintainer will read that and have some time, I just opened https://github.com/tarides/opam-monorepo/pull/407 which puts "ocaml-compiler" into the set of "do not check for dune compatibility". I'm afraid I don't know why there's now ocaml-base-compiler 5.3.0, ocaml-variants 5.3.0, ocaml 5.3.0, and ocaml-compiler 5.3.0. Hannes On 10/02/2025 11:12, Hannes Mehnert wrote: > Hi, > > On 22/01/2025 18:11, Mindy Preston wrote: >> Over the past few months, I have occasionally attempted to build some >> MirageOS projects but very frequently I encounter some time-consuming >> or work-halting problem with opam-monorepo, often a problem which >> seems non-deterministic. I have a few questions: >> >> (1) is this brittle for other people? Perhaps there’s something about >> the environments where I’ve tried this (arch linux on aarch64, ubuntu >> and a close cousin on x86_64, recent opam, vanilla compiler) that’s >> problem-prone?  Is it possible that build steps involving >> opam-monorepo might cause inconsistent state if interrupted before >> completing, which is something I do all the time? > > It is brittle for me as well, over the years I opened various issues and > there's not much opam-monorepo activity unfortunately. > > The latest issue I encounter is > https://github.com/tarides/opam-monorepo/issues/406 -- and my workaround > was to point my opam repository to something before 5.3: > > opam repository set-url default > git+https://github.com/ocaml/opam-repository.git#2e81d1953c37347d78d994b71ede87c5f6f6e207 > > The running the `make lock pull` showed me some other error I was able > to fix, and voila re-setting my opam-repository to > opam repository set-url default https://opam.ocaml.org > > Worked than fine. But as you mention, it is very very brittle. In > combination with very confusing error messages. > > >> (3) I often work on a library and a unikernel that uses it in tandem, >> so the `scope` argument to package config is essential, but I had to >> go digging in functoria .mli’s to find it. Is there documentation that >> I should have read about this? If so, I will go read it and maybe that >> will enlighten me. > > I never use the "scope" argument. > >> I’ve also tripped over things that are already in issue trackers like >> ‘mirage clean’ not cleaning out the duniverse directory and the >> current problem with OCaml 5.3.0 not being usable at all. After >> looking into the latter problem, I’m worried about the maintenance >> status of `opam-monorepo` and the `opam-overlays` repository it uses. >> The last commits were some time ago for both repositories, and it >> doesn’t look like there are replies to recent issues and PRs. > > True. Sad story. > > Maybe time to find a different path. All we need is customly-built C > stubs -- no need for recompiling all OCaml code for a unikernel. > Eventually there are better ways than this "opam-monorepo". (Hint: > there's > https://github.com/mirage/ocaml-solo5/pull/144/commits/3eb1861fad33abc895a581521cd20d77247a0bf9 paving the way... but we still need some mechanism to tag packages that require building with the MirageOS/OCaml C cross-compiler.) > > Of course, help (in terms of bugfixes, triaging issues, updating the > dune-opam-overlays) are very welcome. > > > Hannes > From mirageos-devel-bounces@lists.xenproject.org Mon Feb 10 17:46:37 2025 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 10 Feb 2025 17:46:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.884933.1294681 (Exim 4.92) (envelope-from ) id 1thXrX-000748-F6; Mon, 10 Feb 2025 17:46:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 884933.1294681; Mon, 10 Feb 2025 17:46: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 1thXrX-000741-BT; Mon, 10 Feb 2025 17:46:27 +0000 Received: by outflank-mailman (input) for mailman id 884933; Mon, 10 Feb 2025 17:46:25 +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 1thXrV-00073t-8S for mirageos-devel@lists.xenproject.org; Mon, 10 Feb 2025 17:46:25 +0000 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [2607:f8b0:4864:20::d35]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f156a7e1-e7d6-11ef-a075-877d107080fb; Mon, 10 Feb 2025 18:46:23 +0100 (CET) Received: by mail-io1-xd35.google.com with SMTP id ca18e2360f4ac-8550803e1afso223136239f.1 for ; Mon, 10 Feb 2025 09:46:23 -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: f156a7e1-e7d6-11ef-a075-877d107080fb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tarides-com.20230601.gappssmtp.com; s=20230601; t=1739209582; x=1739814382; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3wC3V1vUDkAATOH4PJ2FuKq6vOEdDQPPt4CtGQO7CiQ=; b=X2340Z6eSeiYf0VdPyIYAaPqzYB/0in9jijWYOdBv6R2sVMDlKvgU5nMb1Wwq/2zs8 HHe9A0UtlYIwUIDSEKK9p/jf+5n0JQUdUGjq7u3f+WrynLY7s8DX8zyTh3Qlmj7BQdcr tOD8Mb5C0idwmfLdjz6luoNdYzoZymRlhWDvCkTu+ld6J5DQFsrREfQZTbtPHqIyMzR4 KYGltB5t6MozuXr3vyfJtwMngMZfmI6Bgh3rDVGxu8mrTVjiTE91gED3LHchwx+5uzdO arD5yEGPVxAWDv6MAPngPZgKaxFFaTk8BxY5gUs2GbSqNII6Jmjts1RKzKK0FxKeGILu 6MZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739209582; x=1739814382; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3wC3V1vUDkAATOH4PJ2FuKq6vOEdDQPPt4CtGQO7CiQ=; b=qQ+7aOL0V/Fl7hNECS1GcTR7q91k3VVrqUgQxnrw7J+7UOf0CGG5zEltbMRHDS34iT bdxs2mHIIr/Xza/hwgkudwhwK9hZR+rfxXp0YGM8paPbvoJJQ+DSBRKivg+FM+qEQHox zFKvqQEdM7iPJSCUOIfNOIIt0IET2TXF8wXz1JnI88sCb/xFH+0JqZYznooJXkZdp8dY K6QYsgFoMVZAd9TjgGw3KyRRpyQ0Bh5FpFQDpoAeTjf+ZzERg5ogTsmyMO8bULaEFlDK SbhIipxdfFY2eslHeeaEVm3iKr5I0cqcSyMPEaSgi6Jc9/P/NpGGUuY6j9ShFbwf1x8X jeeQ== X-Gm-Message-State: AOJu0YxiLaXq2runCn2S1HPWzM1LalyDHS7ttpQT2/59TbcaDjpzIsF+ mvQKCaoA9h860VSLG4Tyuum/4cBSUDLwTMhQTaZE+Q+BWTS3obyAcbRKJFI0o4wXsyQ5A5Luv7Q 44vehwOETY/m+3gX95p3JBtpNUb0hwJ73njau2JjcouX9QMA6zZojVw== X-Gm-Gg: ASbGnctwvbTYlxWyL2jpDhuNnr42Cywfx6z+32WU0v/Kg+o1NsoELgHrmeDpwVXkteW WiwvHzNky3xonDvI8egNgTojAMywt3ZV5VYlauolh0/c7XQMjq7duYWv9UjuTMju1w0S0XTCaAg == X-Google-Smtp-Source: AGHT+IHoa5MYGceyOoEbCzrx2vnI927veEzgqnBYkBM013zaQjKw2DGxkkQZ369y2gc0JSvkj4oNIh237htX5rCZulg= X-Received: by 2002:a05:6602:7289:b0:84a:5133:9cdd with SMTP id ca18e2360f4ac-854fd8f81e4mr1431531839f.11.1739209582338; Mon, 10 Feb 2025 09:46:22 -0800 (PST) MIME-Version: 1.0 References: <11c179c3-f9a4-4d87-b292-33a33ce2ef35@mehnert.org> In-Reply-To: From: Samuel Hym Date: Mon, 10 Feb 2025 18:46:05 +0100 X-Gm-Features: AWEUYZlIUktABwzvzVNoveuKBHvA9KWjduBrcqg5EifQEevhy2nOYGIyJua3fwg Message-ID: Subject: Re: troubleshooting problems with opam-monorepo To: Hannes Mehnert Cc: mirageos-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" On Mon, 10 Feb 2025 at 13:08, Hannes Mehnert wrote: > I'm afraid I don't know why there's now ocaml-base-compiler 5.3.0, > ocaml-variants 5.3.0, ocaml 5.3.0, and ocaml-compiler 5.3.0. IIUC -compiler appeared as -base-compiler and -variants were mostly duplicates. The `ocaml` package is there to ensure that one of the various compiler packages (-base-compiler, -variants, but also the other possibilities) is installed. It was detailed in the corresponding PR. https://github.com/ocaml/opam-repository/pull/26594 -- Samuel