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. :-)
next prev parent 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).