unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: 41541@debbugs.gnu.org, Mathieu Othacehe <othacehe@gnu.org>
Subject: bug#41541: merge wip-hurd-vm
Date: Tue, 02 Jun 2020 14:40:24 +0200	[thread overview]
Message-ID: <87mu5lsksn.fsf@gnu.org> (raw)
In-Reply-To: <87mu5ly7tx.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Tue, 02 Jun 2020 14:23:54 +0200")

Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

>> Having an RC argument passed directly by the bootloader seems like a
>> good way to proceed for me. This is somehow remotely similar to what we
>> are doing with the "initrd" on Linux (pointing to some piece of code
>> that needs to be loaded before starting the init process).
>>
>> You would also need to store this RC argument in the <boot-parameters>
>> record, by adding a new field or stuffing it in the "initrd"
>> field. Then, we wouldn't need an extra service I guess.
>
> Hmm...I don't understand...probably I'm missing something.
>
> I was thinking to just extend boot-parameters with
> --rc-file=%hurd-rc-script, and then add %hurd-rc-script to the SYSTEM
> service...How would I get the RC script into SYSTEM without a service?

Normally, if you have the system (as returned by ‘guix system build’),
that’s enough to derive any other kind of thing you might want.

So for example, you could have a “startup” (or “rc”) entry in the
‘system’ directory by extending ‘system-service-type’.  And since the
system is known from the boot command line, bingo.

The guideline IMO should be to remain as close as possible to Guix
System on GNU/Linux.  It’s OK to depart a bit from upstream Hurd though
because those bits are not actually used (Debian does its own thing).

>> If we are going that way, the procedures in (gnu build hurd-boot) could
>> be passed the "hurd" package to install, and we could maybe get rig of
>> the "/hurd" symlink?
>
> Hehe, that would be nice...but IME /hurd isn't easy to get rid of.

Some of the /hurd names are embedded in libc, via the Hurd’s paths.h.
Some names are compared by string (!); for instance, symlink.c in libc
has:

  /* A symlink is a file whose translator is "/hurd/symlink\0target\0".  */

  memcpy (buf, _HURD_SYMLINK, sizeof (_HURD_SYMLINK));
  memcpy (&buf[sizeof (_HURD_SYMLINK)], from, len);

That makes it next to impossible to remove /hurd.

I think it should be treated like /bin/sh and /run/current-system: set
up at activation time.

>>From e11e59cbcd9165e3b885c1019e19aaab471f5498 Mon Sep 17 00:00:00 2001
> From: "Jan (janneke) Nieuwenhuizen" <janneke@gnu.org>
> Date: Thu, 30 Apr 2020 15:40:07 +0200
> Subject: [PATCH] gnu: services: Add %hurd-startup-service.
>
> This decouples startup of the Hurd from the "hurd" package, moving the RC
> script into SYSTEM.
>
> * gnu/packages/hurd.scm (hurd)[inputs]: Remove hurd-rc-script.
> [arguments]: Do not substitute it.  Update "runsystem.sh" to parse
> kernel arguments and exec into --rc-file=RC-FILE.
> (hurd-rc-script): Move to...
> * gnu/services.scm (%hurd-rc-file): ...this new variable.
> (bootable-kernel-arguments): Use it.
> (%hurd-bare-metal-service): New variable.
> * gnu/system.scm (hurd-default-essential-services): Use it.

[…]

> +;; XXX this won't go into SYSTEM (as system-service); the result is fine
> +;; though and it gets picked-up well by --rc-file=%hurd-rc-script
> +(define %hurd-rc-script
> +  ;; The RC script to be started upon boot.
> +  (program-file "rc"
> +                (with-imported-modules '((guix build utils)
> +                                         (gnu build hurd-boot)
> +                                         (guix build syscalls))

Probably use ‘source-module-closure’ to be on the safe side.

> +(define (hurd-rc-entry mrc)
> +  "Return, as a monadic value, an entry for the RC script in the system
> +directory."
> +  (mlet %store-monad ((rc mrc))
> +    (return `(("rc" ,rc)))))
> +
> +(define hurd-startup-service-type
> +  ;; The service that creates the initial RC startup file.
> +  (service-type (name 'startup)
> +                (extensions
> +                 (list (service-extension system-service-type hurd-rc-entry)))
> +                (compose identity)
> +                (extend (const (lower-object %hurd-rc-script)))
> +                (description
> +                 "Produce the operating system's RC script, which is executed
> +by RUNSYSTEM.")))

Is this service really meant to be extensible?  If not, we could just do:

  (service-type (name 'startup)
                (extensions
                 (list (service-extension system-service-type hurd-rc-entry)))
                (default-value %hurd-rc-script))

where:

  (define (hurd-rc-entry rc)
    (mlet %store-monad ((rc (lower-object rc)))
      (return `(("rc" ,rc)))))

> +  (append
> +   (if (hurd-target?)
> +       (list #~(string-append "--rc-file=" #$%hurd-rc-script))
> +       '())
> +   (list (string-append "--root="
> +                        ;; Note: Always use the DCE format because that's what
> +                        ;; (gnu build linux-boot) expects for the '--root'
> +                        ;; kernel command-line option.
> +                        (file-system-device->string root-device
> +                                                    #:uuid-type 'dce))
> +         #~(string-append "--system=" #$system)
> +         #~(string-append "--load=" #$system "/boot"))))

So my suggestion is to avoid --rc-file since you know that SYSTEM/rc
exists.

Ludo’, who jumps in the middle of the discussion.  :-)




  reply	other threads:[~2020-06-02 12:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 14:21 bug#41541: merge wip-hurd-vm Jan Nieuwenhuizen
2020-05-27 10:01 ` Mathieu Othacehe
2020-05-27 11:11   ` Jan Nieuwenhuizen
2020-05-30 14:40   ` Jan Nieuwenhuizen
2020-06-02  8:48     ` Mathieu Othacehe
2020-06-02  9:24       ` Jan Nieuwenhuizen
2020-06-02 10:16         ` Mathieu Othacehe
2020-06-02 12:23           ` Jan Nieuwenhuizen
2020-06-02 12:40             ` Ludovic Courtès [this message]
2020-06-02 13:39               ` Jan Nieuwenhuizen
2020-06-03  9:18                 ` Ludovic Courtès
2020-06-03 15:22                   ` Jan Nieuwenhuizen
2020-06-03 15:38                     ` Mathieu Othacehe
2020-06-03 20:27                       ` Jan Nieuwenhuizen
2020-06-04  9:32                         ` Ludovic Courtès
2020-06-04 11:33                           ` Jan Nieuwenhuizen
2020-06-05 16:08                             ` Ludovic Courtès
2020-06-05 16:24                               ` Jan Nieuwenhuizen
2020-06-04 13:59 ` bug#41541: [PATCH 0/9] Merge wip-hurd-vm "last review round" Jan (janneke) Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 1/8] system: Add 'hurd' field to <operating-system> Jan (janneke) Nieuwenhuizen
2020-06-06  7:21     ` Mathieu Othacehe
2020-06-06  8:26       ` Jan Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 2/8] bootloader: Extend `<menu-entry>' for multiboot Jan (janneke) Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 3/8] system: Add 'multiboot-modules' field to <boot-parameters> Jan (janneke) Nieuwenhuizen
2020-06-06  7:32     ` Mathieu Othacehe
2020-06-06 10:13       ` Jan Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 4/8] bootloader: grub: Add support for multiboot Jan (janneke) Nieuwenhuizen
2020-06-06  7:47     ` Mathieu Othacehe
2020-06-06  8:46       ` Jan Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 5/8] system: Use 'hurd' package in label Jan (janneke) Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 6/8] system: examples: Add bare-hurd.tmpl Jan (janneke) Nieuwenhuizen
2020-06-06  7:56     ` Mathieu Othacehe
2020-06-04 13:59   ` bug#41541: [PATCH 7/8] services: hurd: Add `hurd-etc-service' Jan (janneke) Nieuwenhuizen
2020-06-04 13:59   ` bug#41541: [PATCH 8/8] system: Add `hurd-activation' Jan (janneke) Nieuwenhuizen
2020-06-06  8:03     ` Mathieu Othacehe
2020-06-06  8:54       ` Jan Nieuwenhuizen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mu5lsksn.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=41541@debbugs.gnu.org \
    --cc=janneke@gnu.org \
    --cc=othacehe@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).