Re: 13/36: services: Add hurd-console-service-type.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> address@hidden skribis:
>
>> commit d7a217e67dcd3b14402d746f4428db8545ce83f2
>> Author: Jan (janneke) Nieuwenhuizen <address@hidden>
>> AuthorDate: Mon Apr 13 10:13:05 2020 +0200
>>
>>     services: Add hurd-console-service-type.
>>     
>>     * gnu/services/hurd.scm (<hurd-console-configuration>): New variable.
>>     (hurd-console-shepherd-service, hurd-console-service-type): New function.
>>     (hurd-service->shepherd-service): Add entry.
>
> Now for the exciting stuff, neat!

\o/

>> -  #:export (hurd-service->shepherd-service))
>> +  #:export (hurd-console-service-type
>> +            hurd-service->shepherd-service))
>>  
>>  ;;; Commentary:
>>  ;;;
>> @@ -38,9 +39,51 @@
>>  (define (hurd-service->shepherd-service service)
>>    (let ((config (service-value service)))
>>      (match config
>> +      (($ <hurd-console-configuration>) (hurd-console-shepherd-service 
>> config))
>>        (_ '()))))
>
> Hmm do we really need this ‘hurd-service->shepherd-service’ procedure?
> I haven’t read the rest, but it seems surprising at first sight.

We certainly don't need it.  The patch/hunk above is being cut very
unfortunately; it loses the one interesting comment just one line
earlier, which was introduced by the privous (mosttly empty) commit:

    +;; XXX Gradually bootstrap (gnu services) framework.
    +(define (hurd-service->shepherd-service service)

The "XXX" comment is my attempt at implicitly communicating a question
that I had trouble formulating, two weeks ago.  The code that I could
not imagine how to write now looks something like this:

  (define shepherd.conf
    (with-parameters ((%current-target-system "i586-pc-gnu"))
      (shepherd-configuration-file
       (append-map list
                   (service-value
               (fold-services (operating-system-services os)
                              #:target-type
                              shepherd-root-service-type))))))

...but this does not work.  The problem here is that I currestly faked
"file-systems", "syslogd", "user-processes".  Those are needed to "get
past" the missing dependency checks for "openssh" and "guix-daemon".  I
have no idea how to write those yet, so would like to postpone them for
a bit.

However

  (define shepherd.conf
    (with-parameters ((%current-target-system "i586-pc-gnu"))
      (shepherd-configuration-file
       (filter
        (lambda (value)
          ;; XXX Remove file-systems, loopback, syslogd, user-processes
          ;; those are fake/don't work yet on the Hurd
          (pk "prov" (memq (car (shepherd-service-provision value))
                           '(console guix-daemon ssh-daemon ttys
                                     user-processes))))
        (service-value
         (fold-services (operating-system-services os)
                        #:target-type
                        shepherd-root-service-type))))))

this also does not work, because again, I get

    guix build: error: service 'user-processes' requires 'user-homes', which is 
not provided by any service

So...I just can't manage to bootstrap shepherd services into
"system/hurd.scm cross-hurd-image" without this intermediate
hurd-service->shepherd-service procedure.  Once we have working
implementations for all these services, hurd-service->shepherd-service
has become obsolete.

Now this

    guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl

has some cross-build problems, though.  Yesterday I finally managed to
pin-point the problem.  It lives between
expression->derivation-in-linux-vm

(define* (expression->derivation-in-linux-vm name exp
                                             #:key
                                             (system (%current-system)) target
                                             (linux linux-libre)
...

that is called by qemu-image.  So I have been playing with this hack

(define* (qemu-image #:key
                     (name "qemu-image")
                     (system (%current-system))
-                    (target (%current-target-system))
+                    (target (if (hurd-target?) #f (%current-target-system)))

Because when qemu-image has "target" set, then 
expression->derivation-in-linux-vm
will attempt to create a QEMU vm for that target and start in in
QEMU...but it needs a LINUX for that target and starts to cross-build
linux for i586-pc-gnu.  That build fails.

In our "guix build -f gnu/system/hurd.scm" setup ("hack"?) we call
qemu-image with target #f, build and run a VM-image using x86_64-linux
and manually cross-compile all packages that go inside.

I'll be trying to rewrite these services harder and use more of the
regular "guix system" way of handling services to plug that into
gnu/system/hurd.scm.

Meanwhile there is the vm-image question: can we somehow use
expression->derivation-in-linux-vm when running "guix system
... --target=i586-pc-gnu"?  Or do we want to create a
expression->derivation-in-hurd-vm?  Or do we leap onto the "explosive
mixture of wip-disk-image and wip-hurd-vm?  Once any of these solutions
work we can drop the gnu/system/hurd.scm cross-hurd-image workaround.

>> +  (list (shepherd-service
>> +         (documentation "Hurd console.")
>
> “Run the Hurd’s VGA console client.”

Ah, ok...that's what it is.

>> +         (provision '(console))
>> +         (requirement '())
>
> Should be '(user-processes) I think.

Ah yes, good catch.

>> +         (start #~(lambda _ (fork+exec-command #$console-command) #t))
>
> Rather #~(make-forkexec-constructor #$console-command).

Great, thanks!

>> +(define hurd-console-service-type
>> +  (service-type
>> +   (name 'console)
>> +   (description
>> +    "Run a hurd console, @command{console}.")
>
> Maybe “Run the Hurd console client.”

Thanks.

>> +   (compose concatenate)
>> +   (extend first-of-two)
>
> I don’t think we need these two fields since this service is not meant
> to be extensible.
>
>> +   (default-value (hurd-console-configuration))))
>
> Please add a ‘description’ too!

For the default value?  Isn't that added above...maybe i'm using a weird
layout for the fields?

I will be testing these changes and updating the other services
similarly.

> Also, normally we document every new service type in the manual, but
> maybe we can delay it here so that you can unleash your hack powers in
> the meantime.  :-)

I'm marking this as DRAFT and add a TODO in the message so that we don't
forget.  Let's not waste my hacking powers on documenting stuff too long
before it's merged...but also not forget the documentation.

Phew...

Greetings,
janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com