From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web08.10270.1613749955655136403 for ; Fri, 19 Feb 2021 07:52:35 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fS8l1Qcd; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613749954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UgzFa1kOAH412J2pQlFN4IO1Soa8iuG7vpqMl/0NtIA=; b=fS8l1QcdTLZPjh0imZ4qZRyfdG3ZxPTE0Uih8WYEz9qiIBQvmrOVvUQLqgmkCnf3sxy9jJ DEa9YJn7yAQRbWAVBR6I71FCfcJCCGU1Fu2RF6/VBPHmr8OWAYx434DeIRFTnl18IwyRB5 u4cznlr67GZp4fYt69nPdsMfu0UsBcY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-503-vgLviNm7PnmBVNtGDQJHdA-1; Fri, 19 Feb 2021 10:52:30 -0500 X-MC-Unique: vgLviNm7PnmBVNtGDQJHdA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9212A192FDA4; Fri, 19 Feb 2021 15:52:28 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-87.ams2.redhat.com [10.36.113.87]) by smtp.corp.redhat.com (Postfix) with ESMTP id ECAC01970D; Fri, 19 Feb 2021 15:52:26 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Put BootMenu at the end of BootOrder To: "Li, Walon" , gaoliming , "devel@edk2.groups.io" Cc: "Wang, Sunny (HPS SW)" , "ray.ni@intel.com" , "hao.a.wu@intel.com" References: <20210218032611.1594-1-walon.li@hpe.com> <002801d7065a$5d81f420$1885dc60$@byosoft.com.cn> From: "Laszlo Ersek" Message-ID: <4d25bf28-e147-365a-64d4-6ecf0a1184d2@redhat.com> Date: Fri, 19 Feb 2021 16:52:25 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/19/21 02:33, Li, Walon wrote: > Hi Liming, > > As edk2 design, any new boot options should be put at the end of BootOrder because these are NEW . That means system should "append" BootOrder instead of override original order. > For example, if system has three boot options currently - Boot0001, Boot0002, Boot0003 and then one new option - Boot0000 will be added. The order should become Boot0001,Boot0002,Boot0003,Boot0000. However, in this case, BootmanagerMenu doesn't follow this rule. We set "zero" priority so system would put BootManagerMenu boot option at start. > This case is a corner case because the symptom only be gotten when user delete BootManagerMenu on OS or EFI shell. But it's a possible case. For keeping behavior consistent, we should keep BootManagerMenu option behavior as same as others boot option. > > Thanks > Walon > > -----Original Message----- > From: gaoliming > Sent: Friday, February 19, 2021 8:59 AM > To: devel@edk2.groups.io; Li, Walon > Cc: Wang, Sunny (HPS SW) ; lersek@redhat.com; ray.ni@intel.com; hao.a.wu@intel.com > Subject: 回复: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Put BootMenu at the end of BootOrder > > Walon: > Can you specify the detail reason why BootManagerMenu should be placed at end of BootOrder? In addition to Walon's answer, I'd like to point out that the current code doesn't seem to explain why BootManagerMenu was ever placed at the front. Of course when we change code, the burden of justification is on the patch that's being proposed; so I agree with the question. However, answering that question is easier if the pre-patch code has an explicit explanation, and that explanation can be shown to be wrong (or at least to have missed a corner case or similar). If the pre-patch code is undocumented, then arguing for the new code is more difficult. Laszlo