From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id QJojFrwD+WNkcAAAbAwnHQ (envelope-from ) for ; Fri, 24 Feb 2023 19:36:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 0KUyFrwD+WOTNgAA9RJhRA (envelope-from ) for ; Fri, 24 Feb 2023 19:36:44 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 173297DF9 for ; Fri, 24 Feb 2023 19:36:44 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVcvc-0002QB-Qu; Fri, 24 Feb 2023 13:36:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVcvb-0002Q3-Vg for guix-devel@gnu.org; Fri, 24 Feb 2023 13:36:19 -0500 Received: from mx1.librem.one ([138.201.176.93]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVcvZ-0002BI-UW for guix-devel@gnu.org; Fri, 24 Feb 2023 13:36:19 -0500 Received: from smtp.librem.one (unknown [192.241.214.14]) by mx1.librem.one (Postfix) with ESMTPS id B081181E75; Fri, 24 Feb 2023 10:36:10 -0800 (PST) To: jbranso@dismail.de, "Peter Polidoro" Cc: "Csepp" , guix-devel@gnu.org Subject: Re: Oniro or Guix on Zephyr kernel? References: <87wn47vzol.fsf@polidoro.io> <875ybsxwpc.fsf@polidoro.io> <87o7pkxd5j.fsf@riseup.net> <87zg938c8m.fsf@dismail.de> <98cf0d68448c06df4bba4c9211d87faa@dismail.de> Date: Fri, 24 Feb 2023 13:36:06 -0500 In-Reply-To: <98cf0d68448c06df4bba4c9211d87faa@dismail.de> (jbranso@dismail.de's message of "Fri, 24 Feb 2023 16:52:31 +0000") Message-ID: <87wn46ud0p.fsf@librem.one> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Content-Type: text/plain Received-SPF: pass client-ip=138.201.176.93; envelope-from=mitchellschmeisser@librem.one; helo=mx1.librem.one X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Mitchell Schmeisser From: Mitchell Schmeisser via "Development of GNU Guix and the GNU System distribution." Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1677263804; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:content-type:content-type: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=22AvZRvV32RIjtfBHczxyX3TYPv9ZL9ENaOmtvSFQCA=; b=mZ+RzKz5MNMuCEwMDNDQe2KIrk/d1X7hV/OMMrMR9sgas18d0q+GPK+k3E2fwOtWL6mR2M 0+Hu3DeJdgfouPVWTT0C/j8XALOgfuiyykv66jDH1nUzHcNa8OnI0lZPchlNE25GK/1DU1 FXDUGcUFamE25D9wDUZGULPuqBK7XhOjDxDKC2da7xvG1fRl7w5pZcMGIpKDPlWd63Pt0k i0v/Hn+ZCZsa89GgQEpXo8X1TGHPpuOmU67OXDsO0QxeE1ZWhAEwjgFsseJz+gubktXu02 KiZgJVE/h3fdTBYoWo7BFsnzji0SG0YM0w/NT1t2G8+O4KnbbUWKCP872dIncQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1677263804; a=rsa-sha256; cv=none; b=Ed2bvl7GnGeEqPZWlkxCIjmlSvkAQHo07swRyduf3POHtNfF2MXr3uOu2EL24dFREf1qwC 7u4JMw8uyWE2WJTujWthh/94camptUxf5wUd8b3Ndq3qA1ta5V5zBoo7Wi34JYfyVvmE0B Rt6eWI+O8UbnDY0Cugdg01s1Rni7Vf6btvkB0T68Wsxw/9aOD9k04PgoG5HYBiQPvgyu6Q Hg+5JtyqfZJc3bFQ6O0ORzriIsgp26Oi93dcxb+wGYT/gqpwso+369Qaby0RGGQjV74vvE UUGSBGuSe5V7sTos5LPqU33SE6b/pezr3Oojz2qTzFouRzT/075v66iOlMSjug== X-Spam-Score: 1.02 X-Migadu-Queue-Id: 173297DF9 Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 1.02 X-TUID: 8dcRgquuBfZ+ jbranso@dismail.de writes: > February 24, 2023 10:41 AM, "Peter Polidoro" wrote: > >>> Actually, my new friend Mitchell just created a blog post about > using >>> GNU Guix for Zephyr kernels: >>> >>> https://gnucode.me/building-toolchains-with-guix.html >> >> Great blog post, thank you! It makes me a little hesitant about Zephyr if they have just given up >> on other people building their SDK, but I am very glad all of you smart people are working on a >> Guix alternative. >> >> I am still curious if other parts of Guix System could be useful in embedded environments if all of >> the packages are cross-compiled. >> >> I am not sure of the detailed plans for Oniro, but I assume that it will provide some sort of >> abstraction layer and user space on top of either the Linux kernel or the embedded Zephyr kernel. >> Would it be possible to make some subset of Guix System into something equivalent or is an entirely >> new operating system really necessary for that purpose? Are most of the resource requirements for >> Guix System, 1 Gig of ram, etc, due to the package builder and Guix/Nix daemon? If it was possible >> to declare an instance of Guix System that did not include those and only used cross-compiled >> packages, could some portion of Guix System function in a similar way as Oniro, or is that a >> nonsense question? > > I'm probably not the best person to ask about that. I am adding in Mitchell to the discussion. > > Mitchell, what do you think? Could we use a subset of guix system in embedded environments? > > Thanks, > > Joshua >> It makes me a little hesitant about Zephyr if they have just >> given up on other people building their SDK In the embedded world this is not that uncommon. Building cross toolchains is very difficult and many Zephyr users are developing on Windows where you don't ever build anything yourself. A lot of embedded developers still pay top dollar for proprietary toolchains. >> I am not sure of the detailed plans for Oniro I do not know what this is. >> I am still curious if other parts of Guix System could be useful in embedded environments if all of >> the packages are cross-compiled. The short answer is Guix can run on embedded linux environments given sufficient resources, but Guix will never run on the Zephyr kernel*. Zephyr is targeted at extremely resource constrained devices (think arduino or a TV remote). Many of these devices don't have an MMU and do not have such a firm separation between kernel and user space. It is an entirely different world from the one currently modeled by Guix. My main reason for doing this was because Guix has already replaced every other package manager on the system. It felt wrong to use west's dependency management and the SDK installer is a binary distribution. Guix already has packages for `arm-none-eabi-toolchain` so mostly this is just copy and pasted and adjusted to match the cmake expectations of the world. I also thought relying on West to build production software was not the best because it was too easy for me to accidentally modify the environment. The only I could be sure about what I was deploying was to do as Guix does (but worse) and clone the stuff down fresh from the internet (all 3GB+ of it...) and "bootstrap" the environment. Reproducibility issues pop up from time to time in the zephyr project and I thought this work could give some sense of formality to their build system. >> Guix System, 1 Gig of ram, etc, due to the package builder and Guix/Nix daemon? If it was possible >> to declare an instance of Guix System that did not include those and only used cross-compiled >> packages, could some portion of Guix System function in a similar way as Oniro, or is that a >> nonsense question? What I understand your question to be is "Can we use Guix to describe an embedded operating system which does not run Guix?" and I think the answer is probably. I don't think the guix daemon is technically required for the shepherd to boot (being the daemon is a shepherd process itself). I don't think it's a good idea because you need the daemon in order to use `guix deploy`. Otherwise you have to make an installation image and it can become "involved." * Actually the zephyr kernel can drive large systems as well but if you want to run Guix on it you are better off using linux. Look at this video for some inspiration on how Guix can be used to manage these systems. https://archive.fosdem.org/2020/schedule/event/ggaaattyp/