From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [GSoC] Porting GuixSD to GNU Hurd draft Date: Thu, 24 Mar 2016 14:22:53 +0100 Message-ID: <874mbw2eoi.fsf@gnu.org> References: <20160206113802.GA17867@thebird.nl> <87mvre2eyz.fsf@gnu.org> <56BC7496.8020409@gmail.com> <8760x5gpif.fsf@inria.fr> <20160302101227.GF2815@var.bordeaux.inria.fr> <87a8mgefcy.fsf@gnu.org> <20160302220654.GC3037@var.home> <56EFE480.6020007@gmail.com> <878u19wbvt.fsf@gnu.org> <20160323165550.2708.70954@thinkbox.jade-hamburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj5EH-0007e8-HO for guix-devel@gnu.org; Thu, 24 Mar 2016 09:23:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj5EE-0006Fk-8s for guix-devel@gnu.org; Thu, 24 Mar 2016 09:23:13 -0400 In-Reply-To: <20160323165550.2708.70954@thinkbox.jade-hamburg.de> (Justus Winter's message of "Wed, 23 Mar 2016 17:55:50 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Justus Winter <4winter@informatik.uni-hamburg.de> Cc: guix-devel@gnu.org, bug-hurd@gnu.org, Samuel Thibault Hi Justus, Justus Winter <4winter@informatik.uni-hamburg.de> skribis: > Quoting Ludovic Court=C3=A8s (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.=20 >> > 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 mecha= nisms. > > 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 >> =E2=80=98mount=E2=80=99 with support for MS_BIND (which I think it shoul= d), it would >> help a bit, but there=E2=80=99s still the problem of the other Linux nam= e spaces >> that are used (the CLONE_NEW* clone(2) flags.) >>=20 >> 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=E2=80= =99s >> =E2=80=9Cjust=E2=80=9D a matter of giving the child process ports to sep= arate proc, >> auth, etc. translators. >>=20 >> 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. =E2=80=9CMerely=E2=80=9D, hmm=E2=80=A6 :-) So, let=E2=80=99s say PID isolation will be optional, and we can always adj= ust 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=E2=80=99t bother syncing th= is work with nix-daemon; guix-daemon has already diverged, and for instance it does not have OS=C2=A0X sandbox support. You=E2=80=99ll have to arrange to have the Hurd-specific bits in a separate file, so that =E2=80=98#ifdef HURD=E2=80=99 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=E2=80=99s =E2=80=98-kernel=E2=80=99 option to boot the kernel Li= nux. For GNU/Hurd, we >> instead need to boot a complete image with GRUB, like =E2=80=98guix syst= em >> vm-image=E2=80=99 does. You=E2=80=99ll have to investigate how to port = this. > > qemu can boot multiboot operating systems. Great, didn=E2=80=99t know that. >> > Deliver a working GuixSD system image with Hurd as the kernel. > > Hurd is not a kernel. I think we use =E2=80=9Ckernel=E2=80=9D to mean =E2=80=9Cthe thing(s) that = libc talks to.=E2=80=9D >> 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=E2=80=99d 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=E2=80=99d consider it roughly half o= f the programming effort), followed by GuixSD stuff? Thanks, Ludo=E2=80=99.