Hello!
Post by Manolis RagkousisAlthough I have uploaded and shared my draft to the GSoC website, I am
also resending it to the lists as per Ludovic's instruction.
Yeah, the GSoC website makes it possible to provide a link to a text
file, so let’s do that instead of using their SaaSS.
Post by Manolis Ragkousis2. The Project
The project consists of four main stages
1. Modify Guix so it will be able to create and mount the file-system needed to boot into a system with Hurd at its core.
2. Modify Guix so it can produce a working image, while isolating any cases of Linux assumptions.
3. Successfully boot into one such system using GNU Shepherd with pid 1.
4. Modify the new Guix system to take advantage of Hurd specific mechanisms.
Currently the tools Guix uses to interact with the filesystem exist inside the (guix build syscalls) module.
This module provides bindings to libc's syscall wrappers, which are only available on a GNU/Linux system.
In order to offer the same functionality on a GNU/Hurd system we must first write Guile bindings for the
relevant Hurd functions, like 'file_set_translator' in hurd/fs.defs
for example.
Note that technically the ‘file_set_translator’ function is in libc:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (dynamic-func "file_set_translator" (dynamic-link))
$1 = #<pointer 0x1675660>
--8<---------------cut here---------------end--------------->8---
Post by Manolis RagkousisThis module will be called (guix build hurd). This allows us to
re-implement the functionality of the 'settrans' command, as described
here[1], in Scheme and use that in place of 'mount()', where
applicable.
Good! (We might as well call it (hurd …) in fact: (hurd fs) would
correspond to fs.defs, (hurd io) for io.defs, and so on.)
Post by Manolis RagkousisAdditionally, we need to make sure that all modules in (guix build *) and (gnu build *) can offer the same
functionalities on a GNU/Hurd system. For example (gnu build vm) relies on QEMU's '-kernel' command-line
option, which is Linux-specific. On the other hand, in the case of modules like (gnu build linux-boot) or
(gnu build linux-initrd), which by design are Linux-specific, we will need to provide a separate module with
equivalent functionality. (gnu system *) modules will require changes as well, in order to be able to use
modifications that will happen in the (guix build *) and (gnu build *) modules.
I think it’s important to think about:
1. How functionality equivalent to linux-{initrd,boot} will be
implemented on the Hurd.
In my experience the equivalent thing is simpler on the Hurd,
esp. if relying on passive translators (see daemons/runsystem.sh in
the Hurd), though here we’ll probably explicitly activate
translators at boot time.
2. How to structure GuixSD code in a way that abstracts the underlying
OS kernel.
For instance, we could have a (guix build os) module providing an
API that works for both kernels, probably close to the Linux one,
and that would dispatch to the right implementation, the Linux or
Hurd one.
Both of these are quite a bit of design and implementation work that we
should not underestimate.
Post by Manolis RagkousisFinally, once GuixSD is successfully ported, we can cater to the last stage of taking advantage of Hurd specific
mechanisms.
1)Replacing (gnu build linux-container) with (gnu build subhurd) when on a GNU/Hurd system. Subhurds can offer
isolation similar to Linux containers as described here[3].
This is really super optional IMO. This module is only used by ‘guix
environment --container’, which is an optional feature.
Post by Manolis Ragkousis2)Modify the guix-daemon to run without root privileges by utilizing the Hurd architecture. The daemon needs root
privileges in order to setup chrooted environments for the builds. In the Hurd this can be done by setting up a
translator as described here[4].
This is more important, and already non-trivial work. If libc provided
‘mount’ with support for MS_BIND (which I think it should), it would
help a bit, but there’s still the problem of the other Linux name spaces
that are used (the CLONE_NEW* clone(2) flags.)
Thus it may make more sense to write this functionality in guix-daemon
using directly the Hurd interfaces. Separate PID name spaces, UID name
spaces, mount name spaces, etc. are fairly natural on the Hurd: it’s
“just” a matter of giving the child process ports to separate proc,
auth, etc. translators.
In itself this is also a bit of work. I wonder what the Hurd folks
think about priorities here?
Post by Manolis Ragkousis3)Guix uses symlink trees for user profiles. Instead we can use stowfs[5]. Stowfs creates a traditional Unix directory
structure from all the files in the individual package directories.
Fun but optional. ;-)
Post by Manolis Ragkousis3. Estimated Project Timeline
Before March 31
Finish merging the wip-hurd branch to upstream.
Note that this task depends on, ahem, other people as well. ;-)
Post by Manolis RagkousisWrite a (guix build hurd) module which will contain Guile bindings to the RPC stubs like hurd/fs.defs or hurd/exec.defs .
April 1 - April 15
Package missing dependencies (Hurd libs).
Re-implement 'settrans' in scheme.
Don’t just straight into low-level “details.” I’d recommend
familiarizing yourself with GuixSD on GNU/Linux, fiddling with bits of
code and so on (you can try safely in a VM with ‘guix system vm’), and
then, familiarizing yourself with the GNU/Hurd startup process (looking
at daemons/runsystem.sh already gives a good idea.)
Post by Manolis RagkousisApril 16 - May 1
At this point we will have the tools needed to build a Hurd based file-system. (Milestone 1)
“Hurd-based file system”?
Post by Manolis RagkousisMay 2 - May 22
Create (gnu build hurd-boot) and (gnu build hurd-initrd).
Start working on describing the GNU/Hurd system in (gnu system).
I know Debian at some point added initrd support to GNU Mach for some
reason, but fundamentally, the whole point of multiboot is to provide a
solution more flexible than initrds. So, hopefully, no initrds here.
Since there’s no initrd, there’s also no ‘switch_root’ dance (on
Linux-based system the initrd is the initial root file system, so you
need to switch to the real root file system as soon as you’re able to
mount it), which simplifies things.
Justus, Samuel, WDYT?
Post by Manolis RagkousisMay 23 - 12 June
Modify (gnu system *) modules as needed.
All the modules (guix build *) and (gnu build *) will be working as expected by now.
Try building a GuixSD image. (Milestone 2)
This is the crux of the matter. :-)
Before starting, it would be nice to have a rough idea of how GuixSD
startup will work on the Hurd, and what changes this entails.
For debugging purposes, it would be very helpful to say the least to
have a working ‘guix system vm’: it would allow you to test your changes
very quickly, without rebooting and so on.
This in itself requires some thought: currently (guix system vm) relies
on QEMU’s ‘-kernel’ option to boot the kernel Linux. For GNU/Hurd, we
instead need to boot a complete image with GRUB, like ‘guix system
vm-image’ does. You’ll have to investigate how to port this.
Post by Manolis Ragkousis13 June - 23 June
Solve any problems with booting into the system and running GNU Shepherd.
24 June - 9 July
Have a fully working GNU/Hurd system. (Milestone 3)
Make sure all the services/packages run correctly on the new GuixSD/Hurd system and solve any issues.
10 July - 8 August
Start working on getting Hurd specific mechanisms integrated to Guix.
What do you mean?
Post by Manolis Ragkousis9 August - 23 August
By now all the objectives will have been achieved.
Merge patches, code refactoring, documentation.
Deliver a working GuixSD system image with Hurd as the kernel.
Victory! :-)
I think this is super cool, and also super ambitious! I’d expect that
we’d be able to reach milestone #2 if everything goes well (and assuming
we don’t try to address isolation in guix-daemon), but milestone #3 is
most likely for later.
What do people think?
The main question is whether you should implement build isolation in
guix-daemon, in which case that would leave little time for the GuixSD
parts. I think I would rather let you focus on the GuixSD stuff as you
wrote, but I’d like to hear what the Hurd folks think.
Justus, Samuel: could you add yourselves as official co-mentors on
Google’s web site, if not already done? :-)
Thanks, Manolis!
Ludo’.