[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

From: Ludovic Courtès
Subject: Re: [GSoC] Porting GuixSD to GNU/Hurd Update
Date: Sat, 27 Aug 2016 23:35:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hello Manolis,

Manolis Ragkousis <manolis837@gmail.com> skribis:

> On Hurd though, because of the lack of mount(), the above could not
> work. But with the help of my libhurdutil library, which I wrote at the
> beginning of this project, I created 2 wrappers inside
> nix/libutil/call.(hh.cc) for mount() and umount2(), called nixMount()
> and nixUmount2(), and depending on the system the implementation
> changes. On Hurd I am using /hurd/firmlink to offer the same
> functionality to bind-mounts.
> It seems to work but I am testing it thoroughly so we don't have any
> unpleasant surprises in the future. We will have fully isolated builds
> on Hurd as soon as I am sure that my code works as expected and it's
> merged in Guix upstream.

Neat!  You did the right thing.

> Now on the GuixSD side, I will start on a big issue I had. If you check
> the daemon, and specifically nix/libstore/build.cc:2205-2228, you will
> see that when, for example, guix tries to create a 32 bit vm/image from
> a 64 bit machine, the daemon actually builds the 32 bit binaries on 32
> bit personality mode.

Indeed; hopefully we can address that.

> As a result it is not possible to build GuixSD/Hurd vm/images from
> Linux, for now. But this is not a big problem because we can do it from
> Guix running on Hurd :-). The approach I used, was to add a second hard
> drive on my Hurd vm, mount it, and try to directly deploy a GuixSD
> system on that drive.  Currently Guix can build most of the binaries for
> the system but it still needs work to actually boot into one. You can
> see the result of this work on the currect core-updates (and on my
> github repo for some hacky commits).

Woow!  We knew booting GuixSD on GNU/Hurd was an ambitious goal, so what
you describe is already impressive.

> I have also created a new module called (guix build syscalls-tools)
> which contains some of the code from (guix build syscalls) which will be
> used by a (guix build hurd) module, which will contain call wrappers for
> some Hurd libraries. This work is still in my github repo because it
> needs some work.

Nice stuff again.

> There was one more problem that appeared after we started using
> C_INCLUDE_PATH in our cross-builds. As it seems MiG needs glibc in order
> to be built.  That's why for now I patch cross-mig with the
> glibc-headers so I don't have to depend on the Linux ones. But I will
> talk more on this in a different email.
> I think that's enough for now. I avoid talking about things discussed in
> other mails, but if you want please feel free to ask me :-)
> To sum things up, we almost have build isolation working but GuixSD
> still needs some work to become bootable. From here on I will
> finish/test my guix-daemon code, and then I will continue on finishing
> the low-level call wrappers for the Hurd libraries, in order to get the
> bootable system. We are close :-).
> The repos which you can check any code not yet in upstream Guix or Hurd are:
> https://github.com/Phant0mas/Guix-on-Hurd
> https://github.com/Phant0mas/Hurd

Now we need to chew that, both on the Guix and Hurd sides.  Make sure to
ping us with sizable chunks of this code!  :-)

This is again an impressive piece of work, especially given its breadth:
From cross-compilation toolchain issues, to low-level Linux- and
Hurd-specific programming, and to high-level Scheme hacking.  Kudos!

Thank you Manolis!


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]