[GSoC] Guix + Hurd continuation

[GSoC] Guix + Hurd continuation

[Ludovic Courtès]

Hello!

Now that Manolis managed to produce the bootstrap binaries (yay!), we
must plan for what’s next.

I think the first thing will be to try and start building things
natively, as noted in
<https://www.gnu.org/software/guix/manual/html_node/Porting.html>.  That
implies a few things:

  0. Run Guix’s ‘./configure --with-courage && make’ and see what
     happens.

  1. ‘guix-daemon’ must work correctly on GNU/Hurd.  This should be
     mostly the case, but it’s degraded compared to GNU/Linux because it
     will not use name spaces and bind mounts, so no chroot either (see
     <http://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n54>.)
     That’s OK for a start.  Maybe there are other issues I haven’t
     thought of.

  2. When building natively, surely you’ll find out that some packages
     do not build (PATH_MAX!), and that there are assumptions in
     hurd.scm and base.scm, such as the fact that GNU/Hurd is a
     cross-compilation target and not a native system.

  3. In parallel to that, I should review wip-hurd again and apply the
     patches to a new ‘core-updates’ branch.

  4. Instead of sitting idle watching build logs ;-), it Would Be Nice™
     to implement the ‘mount’ and ‘umount’ functions for GNU/Hurd in
     libc, with support for MS_BIND using /hurd/firmlink.  See
     <http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/utils/mount.c#n213>
     (the Hurd’s ‘mount’ command) for a good starting point.

     Of course libc hacking can be quite involved.  So ideally Samuel,
     Thomas, and others would give you detailed guidance and/or hack
     power.  What do people think?

     The reason I’m suggesting this is that it will be useful for the
     build daemon (see #1), and it will also facilitate porting of
     GuixSD afterwards (see
     <http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/syscalls.scm#n144>.)

Anything else?  Comments?

Ludo’.

Re: [GSoC] Guix + Hurd continuation

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

>   2. When building natively, surely you’ll find out that some packages
>      do not build (PATH_MAX!), and that there are assumptions in
>      hurd.scm and base.scm, such as the fact that GNU/Hurd is a
>      cross-compilation target and not a native system.

Another can of worms I forgot to mention is <hurd/paths.h>, which
assumes that translators live in /hurd, whereas we’ll rather have them
in /gnu/store/…/hurd.

The recipe for the ‘hurd’ package could change those file names in
<hurd/paths.h>.  However, translator file names such as “/hurd/symlink”
serve as shortcuts to avoid starting a translator for each symlink:
<http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libdiskfs/file-set-trans.c#n111>.

Thus, with /gnu/store file names for translators, a libc that uses
/gnu/store/XYZ/hurd/symlink as _HURD_SYMLINK (e.g., in
<http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/symlink.c>)
would prevent the shortcut if it talks to a translator that expects
/gnu/store/ABC/hurd/symlink.

I think it would work anyway, but would end up starting one instance of
/hurd/symlink for each symlink, which is suboptimal.

Food for thought!

Ludo’.

Re: [GSoC] Guix + Hurd continuation

[Justus Winter]

Quoting Ludovic Courtès (2015-07-02 11:33:29)
> I think it would work anyway, but would end up starting one instance of
> /hurd/symlink for each symlink, which is suboptimal.

No, /hurd/symlink doesn't quite work as expected.  Currently, the
shortcut semantics are important for us.

Justus

Re: [GSoC] Guix + Hurd continuation

[Ludovic Courtès]

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

> Quoting Ludovic Courtès (2015-07-02 11:33:29)
>> I think it would work anyway, but would end up starting one instance of
>> /hurd/symlink for each symlink, which is suboptimal.
>
> No, /hurd/symlink doesn't quite work as expected.  Currently, the
> shortcut semantics are important for us.

Oh, good to know.  How exactly does it not work as expected?

Ludo’.

Re: [GSoC] Guix + Hurd continuation

[Justus Winter]

Quoting Ludovic Courtès (2015-07-02 14:14:57)
> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
> 
> > Quoting Ludovic Courtès (2015-07-02 11:33:29)
> >> I think it would work anyway, but would end up starting one instance of
> >> /hurd/symlink for each symlink, which is suboptimal.
> >
> > No, /hurd/symlink doesn't quite work as expected.  Currently, the
> > shortcut semantics are important for us.
> 
> Oh, good to know.  How exactly does it not work as expected?

The wiki lists quite a few quirks:

http://darnassus.sceen.net/cgi-bin/hurd-web?P=symlink

Justus

Re: [GSoC] Guix + Hurd continuation

[Manolis Ragkousis]

Hello everyone,

On 2 July 2015 at 12:12, Ludovic Courtès <ludo@gnu.org> wrote:
>   0. Run Guix’s ‘./configure --with-courage && make’ and see what
>      happens.
>   1. ‘guix-daemon’ must work correctly on GNU/Hurd.

Already started working on them. Will report back today on my first results.

>
>   2. When building natively, surely you’ll find out that some packages
>      do not build (PATH_MAX!), and that there are assumptions in
>      hurd.scm and base.scm, such as the fact that GNU/Hurd is a
>      cross-compilation target and not a native system.

I already have a pretty solid idea of what you mean. Will work around
them as I progress.

>   3. In parallel to that, I should review wip-hurd again and apply the
>      patches to a new ‘core-updates’ branch.

Okay.

>   4. Instead of sitting idle watching build logs ;-), it Would Be Nice™
>      to implement the ‘mount’ and ‘umount’ functions for GNU/Hurd in
>      libc, with support for MS_BIND using /hurd/firmlink.
>      Of course libc hacking can be quite involved.  So ideally Samuel,
>      Thomas, and others would give you detailed guidance and/or hack
>      power.  What do people think?

Yes,  I think now it's the right time to start this. Expect questions
as I work on this. :-)
Meanwhile if the hurd guys have something to point out, please do. :-)

> Another can of worms I forgot to mention is <hurd/paths.h>, which
> assumes that translators live in /hurd, whereas we’ll rather have them
> in /gnu/store/…/hurd.

A question. Isn't it possible, that this will break the Hurd expected
behavior? I think I should get
a better understanding of how things work.

Manolis

Re: [GSoC] Guix + Hurd continuation

[Samuel Thibault]

Manolis Ragkousis, le Thu 02 Jul 2015 16:38:54 +0300, a écrit :
> >   4. Instead of sitting idle watching build logs ;-), it Would Be Nice™
> >      to implement the ‘mount’ and ‘umount’ functions for GNU/Hurd in
> >      libc, with support for MS_BIND using /hurd/firmlink.
> >      Of course libc hacking can be quite involved.  So ideally Samuel,
> >      Thomas, and others would give you detailed guidance and/or hack
> >      power.  What do people think?
> 
> Yes,  I think now it's the right time to start this. Expect questions
> as I work on this. :-)
> Meanwhile if the hurd guys have something to point out, please do. :-)

Note that this is listed on the "contributing" page of the wiki, with a
link to the glibc open_issues page describing a bit more details.

> > Another can of worms I forgot to mention is <hurd/paths.h>, which
> > assumes that translators live in /hurd, whereas we’ll rather have them
> > in /gnu/store/…/hurd.
> 
> A question. Isn't it possible, that this will break the Hurd expected
> behavior?

The Hurd is supposed to be flexible, so this is supposed to work. If not
then that needs to be fixed, not the way you're doing things :)

Samuel