From mboxrd@z Thu Jan 1 00:00:00 1970 From: Justus Winter <4winter@informatik.uni-hamburg.de> Subject: Re: [GSoC] Porting GuixSD to GNU Hurd draft Date: Wed, 23 Mar 2016 17:55:50 +0100 Message-ID: <20160323165550.2708.70954@thinkbox.jade-hamburg.de> 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> 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]:38344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aim4l-0002C7-Bc for guix-devel@gnu.org; Wed, 23 Mar 2016 12:56:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aim4g-0000Cc-D0 for guix-devel@gnu.org; Wed, 23 Mar 2016 12:56:07 -0400 In-Reply-To: <878u19wbvt.fsf@gnu.org> 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: Ludovic =?utf-8?Q?Court=C3=A8s?= , Manolis Ragkousis Cc: guix-devel@gnu.org, bug-hurd@gnu.org, Samuel Thibault Hi, 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 n= eeded to boot into a system with Hurd at its core. = > > 2. Modify Guix so it can produce a working image, while isolating any c= ases 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 mechan= isms. For me, 4. is the most important bit, so we can build packages in isolation. > > Currently the tools Guix uses to interact with the filesystem exist ins= ide the (guix build syscalls) module. = > > This module provides bindings to libc's syscall wrappers, which are onl= y available on a GNU/Linux system. = > > In order to offer the same functionality on a GNU/Hurd system we must f= irst write Guile bindings for the = > > relevant Hurd functions, like 'file_set_translator' in hurd/fs.defs > > for example. > = > Note that technically the =E2=80=98file_set_translator=E2=80=99 function = is in libc: > = > --8<---------------cut here---------------start------------->8--- > scheme@(guile-user)> (dynamic-func "file_set_translator" (dynamic-link)) > $1 =3D # > --8<---------------cut here---------------end--------------->8--- > = > > This 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. Right. In fact, what settrans (or mount) does isn't that hard to reproduce, though I wouldn't mind moving the c implementation to libhurdutil or the like and binding to that. > I think it=E2=80=99s 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=E2=80=99ll probably explicitly activate > translators at boot time. Currently, there is not really a reason to have an initrd-like solution on the Hurd. Yes, one has to start the default pager explicitly, but that's about it. > > Finally, once GuixSD is successfully ported, we can cater to the last s= tage of taking advantage of Hurd specific = > > mechanisms. = > > This includes but is not limited to: > > 1)Replacing (gnu build linux-container) with (gnu build subhurd) when o= n 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 =E2=80=98= guix > environment --container=E2=80=99, which is an optional feature. Yes, subhurds are more on the experimental side imho. > > 2)Modify the guix-daemon to run without root privileges by utilizing th= e 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 > =E2=80=98mount=E2=80=99 with support for MS_BIND (which I think it should= ), it would > help a bit, but there=E2=80=99s 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=E2=80= =99s > =E2=80=9Cjust=E2=80=9D a matter of giving the child process ports to sepa= rate 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. 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. > > 3)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. ;-) Agreed. > > May 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=C2=A0Mach 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=E2=80=99s no initrd, there=E2=80=99s also no =E2=80=98switch_= root=E2=80=99 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=E2=80=99re abl= e to > mount it), which simplifies things. > = > Justus, Samuel, WDYT? Debian has the initrd for the live cds, but that is a bit hacky. I don't believe we need an initrd at this point. > > May 23 - 12 June > > Modify (gnu system *) modules as needed. > > All the modules (guix build *) and (gnu build *) will be working as exp= ected 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 =E2=80=98guix system vm=E2=80=99: it would allow you to te= st your changes > very quickly, without rebooting and so on. > = > 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 Lin= ux. For GNU/Hurd, we > instead need to boot a complete image with GRUB, like =E2=80=98guix system > vm-image=E2=80=99 does. You=E2=80=99ll have to investigate how to port t= his. qemu can boot multiboot operating systems. > > Deliver a working GuixSD system image with Hurd as the kernel. Hurd is not a kernel. > Victory! :-) > = > I think this is super cool, and also super ambitious! I=E2=80=99d expect= that > we=E2=80=99d be able to reach milestone #2 if everything goes well (and a= ssuming > we don=E2=80=99t 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=E2=80=99d like to hear what the Hurd folks think. I consider isolation more important. > Justus, Samuel: could you add yourselves as official co-mentors on > Google=E2=80=99s web site, if not already done? :-) I clicked on 'want to mentor', do I need to do more? Justus