From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 3B19D941C26 for ; Thu, 12 Oct 2023 15:14:47 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=RLQPqcjzlAsUEWVKKIhOsmsyn4b9x/fNf8YRq1doQ/8=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1697123685; v=1; b=DP5qkky42B1b4TJEjdYqXJ1n0/kxwuuVcV/5uzWWLMXDIdGQArBPxq8v1646YsbR13zQMl18 FXMQRUl4S7yk4/5jkvtqtNRCb8R3KompAMauD+ZItCbaQ5kVrSqewJKK9U/ivEovAoHiz3LCtfC iBwqMpQmz0zUUyIurH6xaqZw= X-Received: by 127.0.0.2 with SMTP id 6AKAYY7687511xicLMaYYxbo; Thu, 12 Oct 2023 08:14:45 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.14641.1697123685181567240 for ; Thu, 12 Oct 2023 08:14:45 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-166-djY4lU65P5GkLOnB8blapA-1; Thu, 12 Oct 2023 11:14:30 -0400 X-MC-Unique: djY4lU65P5GkLOnB8blapA-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B1E78185AD35; Thu, 12 Oct 2023 15:14:29 +0000 (UTC) X-Received: from [10.39.192.186] (unknown [10.39.192.186]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B4341C060DF; Thu, 12 Oct 2023 15:14:29 +0000 (UTC) Message-ID: Date: Thu, 12 Oct 2023 17:14:27 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Optimize BmExpandPartitionDevicePath To: Aaron Young , devel@edk2.groups.io References: <9348b3d2-eafb-ef88-9b2f-d70843afb428@redhat.com> <16085.1697045816285916965@groups.io> From: "Laszlo Ersek" In-Reply-To: <16085.1697045816285916965@groups.io> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: xzPGDIPnEJW4RCwTnDpTwybJx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=DP5qkky4; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 10/11/23 19:36, Aaron Young wrote: > >  Thanks for the comments, Laszlo. > >  I could look into optimizing SetBootOrderFromQemu()->Match() by using >  EfiBootManagerGetNextLoadOptionDevicePath() instead of > EfiBootManagerGetLoadOptionBuffer(). >  Makes sense to me and at first glance seems like it would work. My main > concern is some >  unforeseen change in behavior that manifests in a regression somehow. > Would require lots >  of testing beyond what I am capable of doing. Yes, this is exactly my concern as well. EfiBootManagerGetLoadOptionBuffer() contains an internal loop around EfiBootManagerGetNextLoadOptionDevicePath(), and some short form --> long form expansions that succeed right now may depend on that loop. If we just replace the current call to EfiBootManagerGetLoadOptionBuffer() without repeating the same loop, we could regress things. >  However, I'd prefer to do this as a separate task from this PR as it's > not really >  related, right? i.e. EfiBootManagerGetNextLoadOptionDevicePath() still > ends up >  calling ConnectAll. just making sure I understand. Sure, this is totally unrelated. And, it's not a functional issue, just an opportunity for some slight optimization (at the risk of a functional regression, of course). So definitely don't get into it without proper time allocation. That's why I'm not doing it myself either! I just thought that you might be able to consider it, given that you're looking at BmExpandPartitionDevicePath() already. But, certainly feel free to ignore it. Basically I wish UefiBootManagerLib offered an interface that did *all* of what EfiBootManagerGetLoadOptionBuffer() does, except loading the file contents. But extending UefiBootManagerLib with new interfaces is difficult. > >  Also, I can look into amending the PR commit to add the call chain for > ConnectDevicesFromQemu >  that you menioned above. That would be welcome. Thanks! Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109575): https://edk2.groups.io/g/devel/message/109575 Mute This Topic: https://groups.io/mt/101876973/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-