From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 0DibC6Z6EWNF2QAAbAwnHQ (envelope-from ) for ; Fri, 02 Sep 2022 05:38:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id LnybC6Z6EWO1GwAAauVa8A (envelope-from ) for ; Fri, 02 Sep 2022 05:38:14 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3FB822AE44 for ; Fri, 2 Sep 2022 05:38:12 +0200 (CEST) Received: from localhost ([::1]:38818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oTxVS-00083C-SV for larch@yhetil.org; Thu, 01 Sep 2022 23:38:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTxVK-000834-7h for guix-patches@gnu.org; Thu, 01 Sep 2022 23:38:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:54825) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oTxVJ-0006Ks-Ul for guix-patches@gnu.org; Thu, 01 Sep 2022 23:38:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oTxVJ-0002MC-NR for guix-patches@gnu.org; Thu, 01 Sep 2022 23:38:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#57496] [PATCH 1/2] gnu: bootloader: Extend `' for chain-loader. Resent-From: tiantian Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 02 Sep 2022 03:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57496 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Julien Lepiller Cc: 57496@debbugs.gnu.org Received: via spool by 57496-submit@debbugs.gnu.org id=B57496.16620898789050 (code B ref 57496); Fri, 02 Sep 2022 03:38:01 +0000 Received: (at 57496) by debbugs.gnu.org; 2 Sep 2022 03:37:58 +0000 Received: from localhost ([127.0.0.1]:44574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTxVF-0002Lu-HU for submit@debbugs.gnu.org; Thu, 01 Sep 2022 23:37:58 -0400 Received: from out203-205-221-155.mail.qq.com ([203.205.221.155]:54569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTxVA-0002LZ-UT for 57496@debbugs.gnu.org; Thu, 01 Sep 2022 23:37:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1662089864; bh=uEFEP+r3JPHu2K+bJZavlSwb4dnXkmI4a38xnrDLYb8=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=qjQSWIpBCUoeI4tIZgZYB0alYWf1bFDAg6fz1GoM0ZhItZHjzxSrKK2ZzBtN34lJG 5vyycFjMO4sbjZKBL7/IqfVVi2BJYkeWGAc1bTXCkDK8ScLudeLaIGvNyuvB/kUKIR j8JmHOl633XoNKzexFESXlO1CteO26fiFTFp6YLk= Received: from guix-pc ([240e:398:28aa:8901:2e5d:53be:47ef:3da]) by newxmesmtplogicsvrsza8.qq.com (NewEsmtp) with SMTP id 96A8F8E5; Fri, 02 Sep 2022 11:37:42 +0800 X-QQ-mid: xmsmtpt1662089862t9vazfz6k Message-ID: X-QQ-XMAILINFO: ORuEwgb9eurkKnyOHDS9QBwGxKGlyiOdY7S5hCj1ytRsTPuiZN4S47Sru0fFfk YTNkft5y54T33XtYufbRvb+Qm/tcupMS11uhEUWCXuTe2YxgUsXDtGxoA8yKljhchRhFBAhOpfcJ I/juH0IHgSlc91IwzL4EgF5/AV4MWNWnJOxomNQbxZ6O0XH3yzu16XlMHU+1HmqqfvcICwzhTJWo UNzmvbbBrMGngKzM4mDG7QSIEoBMSB8avqziVZ7O9emOI79iRTdAW5zd0MZclWZrf1R+Wi5Go/qu Z5DpQAl/nNsVQRLkiEdZYsCy5toN0nM3PBFInschMw8tLkPywwe1W+YHwP4KmZQTwaDwxRSqSz+8 ZEoDSk3jlm4HmtJq4W/4eTw8UKCvWeT0FGY2nL+TS04TinGCHDne9ejxRg6q5VEoxrKdHoq38Q79 xNP4MxcnQUNGmvBSgIVpZIf2X7WrvXDlT+LVrVVfI2iBrj5fiUoA8qW2QbHthJ1hr+m3xRhmD5vn 2rwY/0tD8RZ6GCJnPWdLk9LOTbOWJkLhSZOH9/nEq95n7X+sV8f1i/n3c0kWYJEQyPDylmDfrEEM VmCUHcEedz0wQNGlXgH788nQwqNvPmVfcxZhJYRcbqzwreBMc4BySS2rV3nuI4E+7PI8Ti7dSWR4 9soDcTYEt+Nnp7Y/TOWBWEFsAi2qR8vTdT7qso1s14jLsrS++vUKFxgm2XvtSBBdM/KxjMJPV+Zf mtTF54OItS2R+h8HkZaelH2XqGxh/1s6Gmm+KaHAHBc2z4Pm9+lGjxFOs7Z3N3vRdc7/2hoNrFz7 2bP/mrFt4HQY63PUQVQP/WhyoSkCe/OnWA7Do/dk//svmIYKS6P7DNW29OWLSDLCosYRqhf2Rsvj 6hEvkl5ut4bdREiKU1DXTDEbAKQLtWcDErOQIitlgVlkGK3Rs7hJcUZtiHOe1qQFvBngh9Y7x8iL fGeLidxiVYa7+omATZjegMBXPUYeZz References: <55016216-84d9-e2e6-8bf5-0efdfa0e6ac1@foxmail.com> <20220831213406.3ec92474@sybil.lepiller.eu> <7xy1v37ny8.fsf@foxmail.com> User-agent: mu4e 1.8.9; emacs 28.1 From: tiantian Date: Fri, 02 Sep 2022 09:04:15 +0800 In-reply-to: <7xy1v37ny8.fsf@foxmail.com> Message-ID: <7xfshacupl.fsf@foxmail.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1662089894; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=uEFEP+r3JPHu2K+bJZavlSwb4dnXkmI4a38xnrDLYb8=; b=SQEDbrGZNaefhzSU/irg77nUyvEgpWhbcIincjs4XfEFRgbDdNM0glimFJzNF7DYDlW5zS qfxAGd2Aybi/V110h4sNOhNiR80mMCmEPKemZTEcWJp51nfXUrjpkMaHE1OnUOPSx3V/M/ J/gP86mkjWQQv8YpPiJEgK8YbcK5MI+SyaS57rbZbmftFGbtow2wcaS3ctZIyTGEQaOPya WA91+zu/lZGLFhnb35992uGHENxaijV4WwNy3RtgXY6O5AjhAT+FVkD8RU2hIfDYNPUGNQ jEigG3ekobHsiKHvbGAeqR62A7zKy9sAJMeiyV9GB6toKwKqmnYKtKPrel7wmg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1662089894; a=rsa-sha256; cv=none; b=HPmPsGL6C2mD0h2RKqJZIN/b64XrjZLyjPi62cOKsz8wNvoqdd9Snglv/zh8IM+1vHV3d4 Ha9qdAXZp95nDnbC9OvWm1iG9dXFXSNp1PrQglIsQFWz08zLWcBK+Ymfk5mYbJAFeThDGM kNG74lQtUaeYN22WpJMAEHov6W6+2UhVqFCemn7BmPeVNZujQfZ54Mz8fg52DDepXfVYY/ lUmOUOsTnRjWLWwqPoWVOhfe02wTTsDjbX3JPnT3DqIF6fD5uIeCF/dAqUMIcOlIIQq4sz 80rCM9WDV7roDCmgj+LC1G1CMgVugmL4ygojEfWQS+8TE+BVx/kNtdy3GuB8ZQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=foxmail.com header.s=s201512 header.b=qjQSWIpB; dmarc=fail reason="SPF not aligned (relaxed)" header.from=foxmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 9.83 X-Spam: Yes Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=foxmail.com header.s=s201512 header.b=qjQSWIpB; dmarc=fail reason="SPF not aligned (relaxed)" header.from=foxmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3FB822AE44 X-Spam-Score: 9.83 X-Migadu-Spam: Yes X-Migadu-Scanner: scn0.migadu.com X-TUID: 3yxo+no+XSBF Hi Lepiller, >> >> Let's try something like this: >> >> @item @code{chain-loader} (default: @code{#f}) >> A string that can be accepted by @code{grub}'s @code{chainloader} >> directive. This has no effect if either @code{linux} or >> @code{linux-multiboot} fields are specified. The following is an >> example of chainloading a different GNU/Linux system. >> > > Thank you for your help. I will change it in next patch. > > But I have a little doubt. 'linux-multiboot' has never appeared in the > documentation. Will it be difficult to understand the document? I don't > know much about multiboot. I haven't seen the "linux-" prefix in > multiboot before. Does multiboot only support linux? > After reviewing some documents of grub. How about changing "linux-multiboot" to "multiboot" or "multiboot-kernel" in the document? The first is because multiboot is used in grub manual. The scecond is because multiboot-kernel is a field that appears in guix manual. like this: @item @code{chain-loader} (default: @code{#f}) A string that can be accepted by @code{grub}'s @code{chainloader} directive. This has no effect if either @code{linux} or @code{multiboot} fields are specified. The following is an example of chainloading a different GNU/Linux system. or @item @code{chain-loader} (default: @code{#f}) A string that can be accepted by @code{grub}'s @code{chainloader} directive. This has no effect if either @code{linux} or @code{multiboot-kernel} fields are specified. The following is an example of chainloading a different GNU/Linux system. >> >> I prefer this variant where the pattern is explicit. >> >> As with what we have today, if the user specifies more than one of >> linux, linux-multiboot and chainloader, they get an unhelpful "no >> matching pattern" error. >> >> This could be done later if you don't have time, but I would suggest to >> fix it by adding a default case that matches all incorrect cases, like >> so: >> >> (_ (raise (condition (&message (message (G_ "Your error message >> here")))))) >> >> Have a look at other "&message" conditions for inspiration. >> >> Also I noticed that if all of linux, linux-multiboot and chainloader >> are #f, then the first pattern matches and will lead to a different >> error message. I haven't tested so I'm not sure what we get, but it >> might be interresting to match on all of them being #f, and print a >> different message. Again, this can be done later. >> > > Thank you for your suggestions. I will use in the pattern to specify all > fields of in next patch. > I didn't know how to throw an error message before. I may need to spend > time reading code and learning. If possible, I will implement it in v3 > patch. > You should be right. There are many situations that I need to check. I can't find a case in menu-entry->sexp to solve it. So, I wrote a function alone. After I have preliminarily completed the function that checks menu-entry, I found that it seems that the explicit pattern is more readable than my individual function. The procedure that check menu-entry will check that there is no boot, different fields of boot are mixed, and there are multiple boot modes. I haven't tested it yet. The expected effect is as follows. --- start examples ---- (menu-entry (label "example") (linux "...") (initrd "...")) Pass check, and no error messages are reported. (menu-entry (label "example") (linux #f) (initrd #f)) (menu-entry (label "example") (linux "...") (initrd #f)) Becase initrd is required, they report the same error message as following. Please select one of following. 1. boot directly (linux + linux-arguments + linux-modules) 2. multiboot (multiboot-kernel + multiboot-arguments + multiboot-modules) 3. chain-loader(chain-loader) (menu-entry (label "example") (linux "...") (linux-arguments '(...)) (initrd "...") (chain-loader "...")) Becase It is complete for boot directly by linux and complete for chainloader, reporting the message as following. Please don't have more than one boot methods 1. boot directly (linux + linux-arguments + linux-modules) 2. multiboot (multiboot-kernel + multiboot-arguments + multiboot-modules) 3. chain-loader(chain-loader) (menu-entry (label "example") (linux "...") (initrd "...") (multiboot-kernel "...")) Becase multiboot-kernel shouldn't appear in the boot mode of linux and the boot mode of multiboot is incomplete, reporting the message as following. Please don't mix them. 1. boot directly (linux + linux-arguments + linux-modules) 2. multiboot (multiboot-kernel + multiboot-arguments + multiboot-modules) 3. chain-loader(chain-loader) --- end examples --- But the procedure lead more difficult to read and understand the code. Maybe it's because my code level is not enough. For the current code, I'm not sure if the error message is worth the performance it consumes and the code that becomes difficult to understand. The check of the procedure is not strong. It only checks whether some fields are set, but not whether the contents of the fields are correct. And I think the most important point is that the procedure just check menu-entry. menu-entry->sexp still need to check linux, multiboot and chain-loader. if not check, An incorrect match will occur in menu-entry->sexp, and an error message that is not helpful may be reported by 'guix system'. I think it might be good to use the menu-entry->sexp in v2 patch. Should I keep menu-entry->sexp of v2 in v3 patch, in addition to adding some necessary comments? The code of the procedure is following. --- >8 --- (define (check-menu-entry entry) (define (all-correct? fields) "Returns a pair according to the number of #t in the FIELDS. If all of the FIELDS are #t, the pair is (#t . #t). If the part of FIELDS is #t, the pair is (#t . #t). If all of the FIELDS aren't #t, the pair is (#f . #f)." (let ((total (length fields)) (right (length (filter identity fields)))) (cond ((= right 0) (cons #f #f)) ((< right total) (cons #t #f)) ((= right total) (cons #t #t))))) (define (get-all-correct-amount boot-methods right-number) (match boot-methods (((_ . #t) rest ...) (get-all-correct-amount rest (1+ right-number))) (((_ . #f) rest ...) (get-all-correct-amount rest right-number)) (() right-number))) (define (get-part-correct-amount boot-methods number) (match boot-methods (((_ . #t) rest ...) (get-part-correct-amount rest number)) (((#t . #f) rest ...) (get-part-correct-amount rest (1+ number))) (((#f . #f) rest ...) (get-part-correct-amount rest number)) (() number))) (match-record entry (label linux initrd multiboot-kernel multiboot-arguments multiboot-modules chain-loader) (let* ((linux-boot? (all-correct? (list linux initrd))) (multiboot? (all-correct? (list multiboot-kernel (not (null? multiboot-arguments)) (not (null? multiboot-modules))))) (chain-loader? (all-correct? (list chain-loader))) (boot-method-all-amount (get-all-correct-amount (list linux-boot? multiboot? chain-loader?) 0)) (boot-method-part-amount (get-part-correct-amount (list linux-boot? multiboot? chain-loader?) 0)) (selects " 1. boot directly (linux + linux-arguments + linux-modules) 2. multiboot (multiboot-kernel + multiboot-arguments + multiboot-modules) 3. chain-loader(chain-loader)\n") ((raise-message (lambda (message) (raise (condition (&message (format #f (G_ "invalid menu-entry: ~a~%~a~%~a~%") entry message selects)))))))) (match (list boot-method-part-amount boot-method-all-amount) ((0 0) (raise-message "Please select one of following.")) ((0 1) #t) ((0 (? (lambda (n) (> n 1)) _)) (raise-message "Plase don't have more than one boot method.")) (((? (lambda (n) (> n 0)) _) _) (raise-message "Plese don't mix them.")))))) --- 8< --- Without any exceptions, v3 patch may be the last version. So how can I modify the submission information to record your help to me? I would like to express my sincere thanks to you.I look forward to your reply. Thanks, tiantian