Re: [GSoC] Porting GuixSD to GNU Hurd draft

[Ludovic Courtès]

Hi Justus,

Justus Winter <4winter@informatik.uni-hamburg.de> skribis:

> Quoting Ludovic Courtès (2016-03-23 14:40:38)
>> > 2. 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.
>
> For me, 4. is the most important bit, so we can build packages in
> isolation.

I guess you mean isolation in guix-daemon.

>> 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?
>
> I'd go for specializing guix-daemon over trying too hard to implement
> Linux-compatible interfaces in the libc.

So this would become maybe half of the GSoC coding part maybe.  WDYT?

> I consider the filesystem-isolation part easy, UID isolation
> relatively easy, PID isolation is a bit tricky.  Currently one cannot
> simply start another proc server and expect it to work as it needs
> privileged kernel interfaces.  I created an RPC to allow nested proc
> servers for unprivileged subhurds.  That should do the trick, it is
> merely a matter of making it actually work I guess.

“Merely”, hmm…  :-)

So, let’s say PID isolation will be optional, and we can always adjust
later on.  Sounds good?

Manolis, make sure to read about how the various Hurd servers provides
these parts of POSIX personality: file systems, UIDs, PIDs, networking,
and so on.

As far as code integration code, I think we won’t bother syncing this
work with nix-daemon; guix-daemon has already diverged, and for instance
it does not have OS X sandbox support.

You’ll have to arrange to have the Hurd-specific bits in a separate
file, so that ‘#ifdef HURD’ are not scattered all over the place.

This is C(++) as you know.  WDYT, Manolis?

>> 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.
>
> qemu can boot multiboot operating systems.

Great, didn’t know that.

>> > Deliver a working GuixSD system image with Hurd as the kernel.
>
> Hurd is not a kernel.

I think we use “kernel” to mean “the thing(s) that libc talks to.”

>> 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.
>
> I consider isolation more important.

OK.

So, Manolis, what about reframing the agenda such that porting
guix-daemon to GNU/Hurd comes first (I’d consider it roughly half of the
programming effort), followed by GuixSD stuff?

Thanks,
Ludo’.