GNU bug report logs - #41785
[PATCH] DRAFT services: Add 'hurd-in-vm service-type'.

Previous Next

Full log

Message #50 received at 41785 <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>, 41785 <at> debbugs.gnu.org
Subject: Re: [bug#41785] [PATCH] DRAFT services: Add 'hurd-in-vm service-type'.
Date: Fri, 12 Jun 2020 23:33:51 +0200

Ludovic Courtès writes:

Hello,

> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>>> It’s a volatile VM, due to the use of ‘-snapshot’, right?
>>
>> By default: Yes.  That seemed more ready-to-use.  A stateful VM image
>> would need to an out-of-store, writable copy.  You can actually do that
>> and modify the hurd-vm-configuration.
>
> It’s maybe worth mentioning in the manual.

Ah right, I wanted to do that after your remark...but forgot.  Could be
an unpleasant surprise to lose everything.  I've now added

--8<---------------cut here---------------start------------->8---
Note that by default the VM image is volatile, i.e., once stopped the
contents are lost.  If you want a stateful image instead, override the
configuration's @code{image} and @code{options} without
the @code{--snapshot} flag using something along these lines:

@lisp
(service hurd-vm-service-type
         (hurd-vm-configuration
          (image    (const "/out/of/store/writable/hurd.img"))
          (options '("--device" "rtl8139,netdev=net0"
                     "--netdev"
                     "user,id=net0,hostfwd=tcp:127.0.0.1:20022-:2222"))))
@end lisp
--8<---------------cut here---------------end--------------->8---

to the patch.

>>> (The Hurd actually has “sub-Hurds”¹ and “neighborhurds”².  I wonder if
>>> it’s our duty to coin another term… a guesthurd? a visithurd?)
>>>
>>> ¹ https://www.gnu.org/software/hurd/hurd/subhurd.html
>>> ² https://www.gnu.org/software/hurd/hurd/neighborhurd.html
>>
>> Oh, that's cool!  Associating along from the neighborhurd pun, what
>> about a "childhurd" (as a pun on childhood -- only needed while the Hurd
>> is growing up)?
>
> “Childhurd”, LOVE IT!

Heh; ...

>> "herd start childhurd" -- hmm?  In the updated patch, I still have
>> hurd-vm.  If we do our duty and coin "childhurd", should I just
>> s/hurd-vm/childhurd/g ?
>
> Shepherd services can have more than one name, so I propose to have both!

... great, now lemme see where to mention this.  I just put in in the
code

--8<---------------cut here---------------start------------->8---
    (list
     (shepherd-service
      (documentation "Run the Hurd in a Virtual Machine: a Childhurd.")
      (provision '(hurd-vm childhurd))
--8<---------------cut here---------------end--------------->8---

and docs here

--8<---------------cut here---------------start------------->8---
@example
herd start hurd-vm
herd stop childhurd
@end example
--8<---------------cut here---------------end--------------->8---

> Ooh, sadness.  We can’t do that because the image machinery really
> expects an <operating-system>.
>
> What if you move ‘with-parameters’ around (system-image …) instead?

=> \o/ that works!  You're genius ;-)

>>>> +(define %hurd-in-vm-operating-system
>> [..]
>>>> +  (operating-system
>>>> +               (service openssh-service-type
>>>> +                        (openssh-configuration
>>>> +                         (openssh openssh-sans-x)
>> [..]
>>>> +               %base-services/hurd))))
>>>
>>> I understand the need to factorize useful configs, but IMO it doesn’t
>>> belong here.  So I’d just leave it out.  There’s already
>>> ‘%hurd-default-operating-system’ that does the heavy lifting anyway.
>>
>> Sure, removed!  Users will most probably want to add an openssh server
>> using openssh-sans-x; but I guess that's something for a blog post or
>> cookbook then.
>
> Yeah.
>
> Hmm, come to think about it, we need a default value here anyway, so
> after all, we have a good reason to have it here.  (Says the guy who
> changes his mind.)

Heh, it's such a pleasure working with you.  I've put it back again,
without the -in- bit.  (says the guy who was easily convinced we didn't
need it.)

>> From b01b8d2a46a6a04cb8f09d74c06cbbc82878f070 Mon Sep 17 00:00:00 2001
>> From: "Jan (janneke) Nieuwenhuizen" <janneke <at> gnu.org>
>> Date: Thu, 11 Jun 2020 22:52:12 +0200
>> Subject: [PATCH v2 1/2] image: Make 'find-image' non-monadic.
>>
>> * gnu/system/image.scm (find-image): Make non-monadic.
>> * gnu/tests/install.scm (run-install): Update caller.
>> * guix/scripts/system.scm (perform-action): Likewise.
>
> [...]
>
>>    "Find and return an image that could match the given FILE-SYSTEM-TYPE.  This
>>  is useful to adapt to interfaces written before the addition of the <image>
>>  record."
>> -  (mlet %store-monad ((target (current-target-system)))
>> -    (mbegin %store-monad
>> -      (return
>> -       (match file-system-type
>> -         ("iso9660" iso9660-image)
>> -         (_ (cond
>> -             ((and target
>> -                   (hurd-triplet? target))
>> -              hurd-disk-image)
>> -             (else
>> -              efi-disk-image))))))))
>> +  (let ((target (%current-target-system)))
>> +    (match file-system-type
>> +      ("iso9660" iso9660-image)
>> +      (_ (cond
>> +          ((and target
>> +                (hurd-triplet? target))
>> +           hurd-disk-image)
>> +          (else
>> +           efi-disk-image))))))
>
> I’d prefer:
>
>   (define* (find-image #:optional (system (%current-system)))
>     …)
>
> In your case, you’d need to make this call:
>
>   (find-image "i586-gnu")
>
> (Beware of the triplet/system type distinction!)
>
> Perhaps the other call sites need to be adjusted.

Then Mathieu writes

> > I would prefer 'target' to be part of the image itself, as I proposed
> > here: https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00417.html.
> >
> > There's no way for now, that the image is built without cross-compiling
> > for "i586-pc-gnu", so I think it could be part of the "image" record
> > itself.
> >
> > WDYT?

and Ludo writes

> Yes, why not, a ‘target’ field in <image> sounds fine.

So...I'm sticking with a the 'target' parameter for now; as that was
Mathieu's suggestion and a closer match to the final solution of
moving TARGET into image.

>> From e5bdf050f628cc7ea1b6bc4ccdcfeb757429820f Mon Sep 17 00:00:00 2001
>> From: "Jan (janneke) Nieuwenhuizen" <janneke <at> gnu.org>
>> Date: Wed, 10 Jun 2020 00:10:28 +0200
>> Subject: [PATCH v2 2/2] services: Add 'hurd-vm service-type'.
>>
>> * gnu/services/virtualization.scm (disk-image, hurd-in-vm-shepherd-service,
>> hurd-vm-disk-image): New procedures.
>> (hurd-in-vm-service-type): New variable.
>> (<hurd-in-vm-configuration>): New record type.
>> * doc/guix.texi (Virtualization Services): Document it.
>
> s/hurd-in-vm/hurd-vm/ in the commit log.
>
> Otherwise LGTM, thank you!

Thanks!  I'll be sending a v3 series that should be OK (apart from the
image work that's not finished yet), and we can decide what to do.

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.