unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Justus Winter <4winter@informatik.uni-hamburg.de>
Cc: guix-devel@gnu.org, bug-hurd@gnu.org,
	Samuel Thibault <samuel.thibault@gnu.org>
Subject: Re: [GSoC] Porting GuixSD to GNU Hurd draft
Date: Thu, 24 Mar 2016 14:22:53 +0100	[thread overview]
Message-ID: <874mbw2eoi.fsf@gnu.org> (raw)
In-Reply-To: <20160323165550.2708.70954@thinkbox.jade-hamburg.de> (Justus Winter's message of "Wed, 23 Mar 2016 17:55:50 +0100")

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’.

  parent reply	other threads:[~2016-03-24 13:23 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-06 11:38 GSoC ideas Pjotr Prins
2016-02-06 12:36 ` Ludovic Courtès
2016-02-06 18:54   ` Christopher Allan Webber
2016-02-07 10:16     ` Efraim Flashner
2016-02-09 20:52       ` Ludovic Courtès
2016-03-25 20:32       ` myglc2
2016-02-08 10:45     ` Tomáš Čech
2016-02-08 11:37       ` Efraim Flashner
2016-02-08 17:24       ` Christopher Allan Webber
2016-02-08 18:45         ` Thompson, David
2016-02-08 19:47           ` Christopher Allan Webber
2016-02-08 20:43             ` Pjotr Prins
2016-02-09 10:36               ` Installing Guix on foreign distros Ludovic Courtès
2016-02-10  8:53                 ` Tomáš Čech
2016-02-10  9:42                   ` Ricardo Wurmus
2016-02-10 12:44                   ` Jookia
2016-02-11  5:44                     ` Ricardo Wurmus
2016-02-11 10:54                       ` Bootstrapping Ludovic Courtès
2016-02-23 23:00               ` GSoC ideas Diane Trout
2016-02-23 23:52                 ` Guix on Debian (was: GSoC ideas) Christopher Allan Webber
2016-02-24  0:02                   ` Leo Famulari
2016-02-24  9:03                     ` Ricardo Wurmus
2016-02-24  9:16                       ` Efraim Flashner
2016-02-24  9:36                         ` Jookia
2016-02-25 18:15                           ` Bootstrap binaries Ludovic Courtès
2016-02-25 20:26                             ` Christopher Allan Webber
2016-02-26 23:19                               ` Ludovic Courtès
2016-02-28 10:51                                 ` Jookia
2016-02-28 15:08                                   ` Ludovic Courtès
2016-02-28 15:10                                     ` Jookia
2016-02-29  5:22                                       ` Christopher Allan Webber
2016-02-29 10:01                                       ` Ludovic Courtès
2016-02-24  0:32                   ` Guix on Debian (was: GSoC ideas) Diane Trout
2016-02-24  7:04                     ` Pjotr Prins
2016-02-24 17:20                       ` Thompson, David
2016-02-24 19:36                         ` Diane Trout
2016-02-25 10:30                           ` Efraim Flashner
2016-02-26  1:27                             ` Diane Trout
2016-02-24 19:14                 ` GSoC ideas Jan Nieuwenhuizen
2016-02-24 21:24                   ` Jan Nieuwenhuizen
2016-02-24 21:56                     ` Diane Trout
2016-02-25 18:10                 ` Ludovic Courtès
2016-02-26  1:28                   ` Diane Trout
2016-03-25 20:52         ` myglc2
2016-02-09 20:49     ` Ludovic Courtès
2016-02-09 22:17       ` Christopher Allan Webber
2016-02-10  6:12         ` Pjotr Prins
2016-02-11  2:11           ` Christopher Allan Webber
2016-02-11 10:01             ` Ludovic Courtès
2016-02-11 17:59               ` Christopher Allan Webber
2016-02-21 21:07                 ` Ludovic Courtès
2016-03-23 19:07       ` myglc2
2016-02-11 11:46   ` Manolis Ragkousis
2016-02-11 17:32     ` Andreas Enge
2016-02-12 11:48       ` Alex Sassmannshausen
2016-02-11 17:36     ` Christopher Allan Webber
2016-02-28 22:12     ` Samuel Thibault
2016-02-28 23:33       ` Richard Braun
2016-03-02 10:09     ` Ludovic Courtès
2016-03-02 10:12       ` Samuel Thibault
2016-03-02 21:31         ` Ludovic Courtès
2016-03-02 22:06           ` Samuel Thibault
2016-03-21 12:09             ` [GSoC] Porting GuixSD to GNU Hurd draft Manolis Ragkousis
2016-03-22  0:49               ` Samuel Thibault
2016-03-23 13:40               ` Ludovic Courtès
2016-03-23 16:55                 ` Justus Winter
2016-03-24 11:18                   ` Manolis Ragkousis
2016-03-24 11:38                     ` Justus Winter
2016-03-24 12:36                       ` Manolis Ragkousis
2016-03-24 12:49                         ` Justus Winter
2016-03-24 13:22                   ` Ludovic Courtès [this message]
2016-03-24 13:55                     ` Manolis Ragkousis
2016-03-24 14:30                       ` Justus Winter
2016-03-04 15:09           ` GSoC ideas Manolis Ragkousis
2016-03-05 22:02             ` Ludovic Courtès
2016-02-06 23:53 ` Ben Woodcroft
2016-02-07  5:51   ` Pjotr Prins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874mbw2eoi.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=4winter@informatik.uni-hamburg.de \
    --cc=bug-hurd@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=samuel.thibault@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).