jbra...@dismail.de writes: > February 24, 2023 10:41 AM, "Peter Polidoro" <pe...@polidoro.io> 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/
