Re: [GSoC] Guix + Hurd continuation

[Justus Winter]

Quoting Ludovic Courtès (2015-07-02 14:14:57)
> Justus Winter <4win...@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

[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 , 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

Re: [GSoC] Guix + Hurd continuation

[Manolis Ragkousis]

Hello everyone,

On 2 July 2015 at 12:12, Ludovic Courtès  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 , 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

[Ludovic Courtès]

Justus Winter <4win...@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 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]

l...@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 , 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
.  However, translator file names such as “/hurd/symlink”
serve as shortcuts to avoid starting a translator for each symlink:
.

Thus, with /gnu/store file names for translators, a libc that uses
/gnu/store/XYZ/hurd/symlink as _HURD_SYMLINK (e.g., in
)
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’.

[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
.  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
 
.)
 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
 
 (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
 
.)

Anything else?  Comments?

Ludo’.