From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUHw5-0003VC-F5 for guix-patches@gnu.org; Sun, 09 Jul 2017 15:32:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUHw2-0003zE-A0 for guix-patches@gnu.org; Sun, 09 Jul 2017 15:32:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:56494) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dUHw2-0003z9-6f for guix-patches@gnu.org; Sun, 09 Jul 2017 15:32:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dUHw2-00029k-0b for guix-patches@gnu.org; Sun, 09 Jul 2017 15:32:02 -0400 Subject: [bug#27529] [PATCH] bootloader: Use for the bootloader side. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170629104259.13537-1-dannym@scratchpost.org> <8737ae995g.fsf@gnu.org> <20170702202656.60c2af09@scratchpost.org> Date: Sun, 09 Jul 2017 21:30:59 +0200 In-Reply-To: <20170702202656.60c2af09@scratchpost.org> (Danny Milosavljevic's message of "Sun, 2 Jul 2017 20:26:56 +0200") Message-ID: <87pod9v24s.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Danny Milosavljevic Cc: 27529@debbugs.gnu.org Hi Danny, [+Cc Mathieu.] Danny Milosavljevic skribis: > On Sun, 02 Jul 2017 16:59:55 +0200 > ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > >> Danny Milosavljevic skribis: >>=20 >> > * gnu/bootloader.scm (menu-entry-device-mount-point): New variable. E= xport it. >> > (: New field "device". >> > * gnu/bootloader/grub.scm (grub-confgiuration-file): Handle >> > entries. >> > * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Handle >> > entries. >> > * gnu/system.scm (menu->entry->boot-parameters): Delete variable. >> > (boot-parameters->menu-entry): New variable. Export it. >> > (operating-system-bootcfg): Make OLD-ENTRIES a list of . >> > * guix/script/system.scm (reinstall-bootloader): Fix bootcfg usage. >> > --- >> > gnu/bootloader.scm | 3 +++ >> > gnu/bootloader/extlinux.scm | 19 +++++++++---------- >> > gnu/bootloader/grub.scm | 27 ++++++++++++--------------- >> > gnu/system.scm | 29 ++++++++++++++--------------- >> > guix/scripts/system.scm | 10 +++++----- >> > 5 files changed, 43 insertions(+), 45 deletions(-)=20=20 >>=20 >> Could you explain the rationale? >>=20 >> IIRC there was the idea that implementations of the bootloader API >> should use , and that would be used only >> in the user-facing APIs (it had even disappeared with the initial >> thing.) > > Yeah, it's preparation for chainloading support (non-Linux OSes etc). I = don't feel strongly one way or another but I think those chainloading entri= es would actually be menu entries and not really boot-parameters as in Guix= -can-use-them-for-anything. > > What this does is use boot-parameters for stuff which Guix needs for itse= lf, and menu entries (which could be a poem by Goethe as much as Guix cares= ) for the rest. *Some* boot-parameters will end up as menu entries, but no= t all (for example think of chainloading: There would only be a menu-entry = for chainloading, but both a boot-parameter and a (generated) menu-entry fo= r the Guix Linux kernel). OK, makes sense to me. So users can provide menu entries for, say, GNU/Hurd or GNU/kFreeBSD; Guix would not try to interpret them and instead pass them directly to GRUB & co., right? > There would be no way to get from a to a be= cause it could as well make no sense to do that. > > In short, the bootloader would always and only get menu-entries, but the = remainder of Guix would only use them as support under wobbly chairs or som= ething :) OK. > On the other hand, boot-parameters are things which Guix needs and manage= s. > > If we want that (or want it again - it was that way before), this patch w= ould be a way to do it. If not, I'm fine with it as well. It just bothere= d me a bit even when the (otherwise great) multi bootloader support went in= that it used boot-parameters as some kind of menu-entry substitute. In th= e beginning, was grub-private, so that was the only way to get= the multi bootloader support to work. But now the is public.= Then why not use it for what it is? That makes sense to me. Mathieu, WDYT? Thanks for explaining, Ludo=E2=80=99.