From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web11.1593.1572981830070137883 for ; Tue, 05 Nov 2019 11:23:50 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BuAXfEkW; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572981829; 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=Ur9xv4CN6a9zowc/y8RsYh2F3TQcsVWasSlGJf8zcb4=; b=BuAXfEkWw2iHLJ6R9qmTnsCoLtsPurZbVoIY5jnCVGQ3paofFsmiQuXB4uK6u6tmllXgEw J16qTjEJvKnQQJAavMfUaBWIuDpRln7D1XijmuAtAkeAGJ5LRD/SPM8bPaCkDnAmV/XEIN EBe3eC2UJkdOuWmeyEl+RVcFmhud4ZI= 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-151-MJoTahG4MSuvClPvyPod7A-1; Tue, 05 Nov 2019 14:23:47 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F2F8A800C73; Tue, 5 Nov 2019 19:23:45 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-96.ams2.redhat.com [10.36.117.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA76860BF4; Tue, 5 Nov 2019 19:23:36 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration To: Ashish Singhal , Andrew Fish Cc: "devel@edk2.groups.io" , "Ni, Ray" , "Wang, Jian J" , "Wu, Hao A" , "Gao, Zhichao" , Mike Kinney References: <1b91c052-f64c-1dca-98ff-a2777afd7f77@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C34F98A@SHSMSX104.ccr.corp.intel.com> <6766B443-E14A-4F57-984E-5A865FB22CC9@apple.com> <37D801DD-41E8-452E-9F24-ADF52BFDB676@apple.com> From: "Laszlo Ersek" Message-ID: <72ce1d71-2a65-a6c0-1dd8-7628429c5a3c@redhat.com> Date: Tue, 5 Nov 2019 20:23:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: MJoTahG4MSuvClPvyPod7A-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 11/05/19 19:00, Ashish Singhal wrote: > I agree that I can use the platform boot manager protocol to modify > the boot variable and give the custom optional data I need, but that > would not stop UefiBootManagerLib from creating another boot option > with mBmAutoCreateBootOptionGuid as the optional data on the next > bootup which I would have to delete every time in the platform boot > manager driver. >>From a purely pragmatic perspective, I would act exactly like you describe above. I'm not saying that this is the cleanest design, or that it has the best performance. However, it also does not introduce technical debt -- it's not a "wrong" thing to do --, and (from past experience) keeping it 100% in platform code produces the least amount of friction, and allows for the smoothest development. Extending UefiBootManagerLib has always been an uphill battle. Thanks Laszlo