GNU bug report logs - #41350
[PATCH 0/3] Use native qemu to build vm-image.

Previous Next

Full log

Message #140 received at 41350 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mathieu Othacehe <othacehe <at> gnu.org>, 41350 <at> debbugs.gnu.org
Subject: Re: [bug#41350] [PATCH v2 3/3] system: vm: Build vm-image using
 native qemu, for the Hurd.
Date: Fri, 29 May 2020 11:06:01 +0200

Ludovic Courtès writes:

> Hi,
>
> Mathieu Othacehe <othacehe <at> gnu.org> skribis:
>
>>> But maybe we can just rebase ‘system-qemu-image’ & co. on top of (gnu
>>> image)?  What prevents us from doing that, Mathieu?
>>>
>>> If we can do that, then indeed, there’s no point in insisting on fixing
>>> cross-compilation support in (gnu system vm).
>>
>> I think we could proceed that way:
>>
>> * Merge Ludo's serie on master.
>
> I think that can wait because on IRC Janneke explained that it doesn’t
> fix anything for GNU/Hurd (to my surprise).

Well, that's too black/white.  Of course this:

-                     (linux   (string-append #$linux "/"
-                                             #$(system-linux-image-file-name)))
-                     (initrd  #$initrd)
-                     (loader  #$loader)
+                     (linux   (string-append
+                               #+linux "/"
+                               #+(system-linux-image-file-name system)))
+                     (initrd  #+initrd)
+                     (loader  #+loader)

is an essential fix.  Only, that used to be on wip-hurd-vm -- so from
that perspective this fix only got reviewed and moved.

Pretty similarly for this

+  (define preserve-target
+    (if target
+        (lambda (obj)
+          (with-parameters ((%current-target-system target))
+            obj))
+        identity))

also an essential bit.  So, seen from master it fixes quite some bits!
What I meant to say is that I haven't seen /additional/ fixes to what
we had on wip-hurd-vm...

Because your fixes look clean and don't break anything, I think we
should maybe apply them to master -- and that's why I kept them at
the bottom of "wip-hurd-vm" for now.

> So I’ll maybe check again once the relevant Hurd bits are on master,
> instead of checking ARM cross-compilation.
>
> Anyway it’s much less important now that (gnu image) can be used for the
> task!

Yes, so from the Hurd perspective this patch set has shifted from
top-priority to probably not going to be used for the Hurd ;)

>> * Then we could review & merge Jan's wip-hurd-disk.
>
> Do I get it right that we first need
> <https://issues.guix.gnu.org/41560>?
>
> The ‘wip-hurd-vm’ branch contains many things:
>
>   1. (gnu system hurd) with the Hurd services etc.
>
>   2. The ‘hurd’ field of <operating-system>.
>
>   3. <menu-entry> with multiboot support.

Yes.

>   4. Hacks to work around vm.scm defects: uses of ‘with-parameters’,

Together with dropping qemu-image support for the Hurd, I have removed
most of this; what remains is in

--8<---------------cut here---------------start------------->8---
system: Add 'multiboot-modules' field to <boot-parameters>.
+             (mach (if (%current-target-system)
+                       ;; A cross-built GNUmach does not work
+                       (with-parameters ((%current-system "i686-linux")
+                                         (%current-target-system #f))
+                         mach)
+                       mach)))
[..]
+         (libc (if target
+                   (with-parameters ((%current-target-system #f))
+                     (cross-libc target))
+                   glibc))
--8<---------------cut here---------------end--------------->8---

>      ‘hurd-target?’, disabling sqlite3, and #~#$ tricks.

I think this is mostly gone, two instances of hurd-target? remain.  I'll
look more sharply at that too!

> I think part of the reason this cycle has been so long is that it’s been
> kind of a big bang; big bangs are great because they lead to something
> new and exciting, but they’re also intimidating.  :-) For me personally,
> looking at all these aspects at once was just too much.

Yes...

> For merging, I think it’d be great to see #1 and #2 as a first step, and
> then #3.

Yes, that would be an amazing feat.

> I do not want any of #4 :-), because I really think it could lead to
> maintenance headaches down the road, which would make the kind of
> changes we’re making today practically impossible in the future.

> Thoughts?

I fully agree, thanks!

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.