Re: Oniro or Guix on Zephyr kernel?

[Mitchell Schmeisser via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

jbranso@dismail.de writes:

> February 24, 2023 10:41 AM, "Peter Polidoro" <peter@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/