From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com [40.92.20.30]) by mx.groups.io with SMTP id smtpd.web11.2425.1598984015069347748 for ; Tue, 01 Sep 2020 11:13:35 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=e0C1LUYi; spf=pass (domain: outlook.com, ip: 40.92.20.30, mailfrom: michael.kubacki@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V5z1bB9woi5lWRHQnFXIxxftgKPCZlYHusY5o+ZL1Bwzh2BCbjrsDYw5MKz/I0Cf7Mp/xoSz6WgEbTYodnUN8kHdFU5K3W2eAqZar4AMIy77+7Qkre3+6H9Tncrt5gq+Ocgf+csDJDvQBuqpbxcJcmVFuj8yfcTN5t9qPwzb3zWZ7ajNzawppvIT68Ilj81O382PwUw9gfNLKgvehT6jnM9PFM+vo+YbcccOBmfW7MDG5zRfsARKjtboIycrPvezAejtDCogvtTam82YnpQD+FUBUD32xe+8lNoc1UiPW9j4dIb2FV+3jiIN6ZDEUfd8Y+SIYR6lUfeSxtL9ZrgWEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wP3pY3CCXUVQpInV4U6kFCLOVjRQBMd04l27OXL6Kq4=; b=BrIBqRbu3suqjLlbifIoI9rsPyTqDs3D4ZYmeK//fRWcwOUaUu9OprIu2hhD+mySFP7I6uGX3Xd2yeeD6VjkafePkDmtDMDTDVapmxCNk3sTdkxLf04yb3UUqcIvqsw3EZeR1j/Y9JhgoV+qXdS9KQDTe49+RBav6DisKDIS/hqtwv44YfBKQBfKnc69f1S5SUzLriWK5ixBvNpZ7SuJHrSd8eJbDuELjAqQolM7JrIQQnKjJSTkalc5i/nlDFD2vb2LIy5L6GfTSgrZR5ANFunpseyyeVesGk0cT04fXgCERaSMPS30bLwmrlueBTL8LANCbS7Im0JJxKkRAu4S6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wP3pY3CCXUVQpInV4U6kFCLOVjRQBMd04l27OXL6Kq4=; b=e0C1LUYiIhsEk+S1vOM/RJlf0k9xmWRc682IsNjF5aHG32PG+rrDAA3gOUZsQ4+hUmmPpE+AGhwlFbkGUtJdfAgFV7eiujxy+plgYmmfadTWQypgPZZ0GIWAt+Yeu0icAmR0rAr8vj8KwAKipcGQxBQkImletq/I8kL55gQQNbI47O9ufyxzZadLm9kCMwqQr8qIkKY0piLoW1P/813aRJuG2vG8Jin5rasVgEucQoMM43DJRjUa/0JP/ULVsGKHb45zqgbBofb1yXvDYlagLFgUwNhcWNjdlSTEzx3VJFdSj/zW6d3V1SCbK/9NZk2kPSVt/NA7Z0wSu4hB/PHUIA== Received: from CO1NAM11FT053.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::43) by CO1NAM11HT005.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::395) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Tue, 1 Sep 2020 18:13:32 +0000 Received: from MWHPR07MB3440.namprd07.prod.outlook.com (2a01:111:e400:3861::45) by CO1NAM11FT053.mail.protection.outlook.com (2a01:111:e400:3861::319) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Tue, 1 Sep 2020 18:13:32 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:4767496B39FBD2CDA1B4601834D8436DBB26558EEFFB75DDB72E1901610C92F0;UpperCasedChecksum:07330922DC06CEE117D6D3CC383758BDC52A53F9987BF85B84AAECEDD3933A92;SizeAsReceived:9633;Count:49 Received: from MWHPR07MB3440.namprd07.prod.outlook.com ([fe80::eda9:ccc8:2ef:2471]) by MWHPR07MB3440.namprd07.prod.outlook.com ([fe80::eda9:ccc8:2ef:2471%7]) with mapi id 15.20.3326.025; Tue, 1 Sep 2020 18:13:32 +0000 Subject: Re: [edk2-devel] [PATCH v3 0/6] Extend Last Attempt Status Usage To: "Kinney, Michael D" , "devel@edk2.groups.io" , Sean Brogan CC: "Gao, Liming" , "Jiang, Guomin" , "Xu, Wei6" , "Liu, Zhiguang" References: From: "Michael Kubacki" Message-ID: Date: Tue, 1 Sep 2020 11:13:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 In-Reply-To: X-ClientProxiedBy: MWHPR03CA0024.namprd03.prod.outlook.com (2603:10b6:300:117::34) To MWHPR07MB3440.namprd07.prod.outlook.com (2603:10b6:301:69::28) Return-Path: michael.kubacki@outlook.com X-Microsoft-Original-Message-ID: <59f2d538-d545-9a7e-f68e-6b9525b1105e@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 255.255.255.255 (255.255.255.255) by MWHPR03CA0024.namprd03.prod.outlook.com (2603:10b6:300:117::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Tue, 1 Sep 2020 18:13:31 +0000 X-Microsoft-Original-Message-ID: <59f2d538-d545-9a7e-f68e-6b9525b1105e@outlook.com> X-TMN: [n4kc2OIo4vo4Drg/T8pAelOjor/ZwmlCKDq6LZHCtZjMhqvetdvjIAffompzL/2r] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: c9dd1fca-7690-4186-4afb-08d84ea2bba3 X-MS-Exchange-SLBlob-MailProps: jGdi06XMWgCK/P/1f5y701wlg/9WQoJC56zOcCUBfMs+cTDJwGIL3qK7/RLPcrsbuk77tiUyQ9e0REKgOBvrFDqmnyJfIs4aN8aPpYrQat9K9deOgYkxOZ92MC8qo8xomiswnFgUszLR3xuNCG8VXo2c7pT325vvkFvwxY1BoDhrKG5GoQSxSJwXKGHQi4U5/TLt3prpOdCHHbo7ikmBpNEAeL4ViPgT6DZxl1FEEo9VTyhEwK+NMfkV1mX3gbpBZ4ulLZZs+bx5jU8cgtJxpEOHE19wMmo8gC+TTcR326rYv2DY4imjwaYbmkl4858sRdBFNCEWZZsAE6SLqGBfBesKhhLiKxPitV2KLP5Mu/nGpJCkHAzAsppQ0GJsAd/AZ7Hu2Vd5iGMowPhohPi8QyVFsgfHRmFDprSSoO99fF4oXBGwp2unTp/jsQGVw73KCvjAAk8xLlkUkv5bF5zwoxXwbfePUxwmcrwvgOujM1TclhDijr55d3vO1uGUsKoTlIJit+B9O51dyWJlayai/LrKYr/6Bczz3CraN5PuiyUCGa0nS6jlsTzsxVZQeq9lzR+z/1h+zUiZy6RLZL8k4k84lAKWFohNNwW7QlpD9IxRFGb90PpZ5ZniPmYGaDgGqQfSXpaZ+LG7wKt+gs+eylUhYU1oIJECDokA2VaUEq1E15t/hgCou5K/FPpnhC1N0+fEpKyiIjrmCogkeKCSSuM4vjmLTO04dlcV5Q9LrpmHheO69P/jvjwjxHQpR9vHOv0OSQr0UgHtadkwgoaUg3uMx7KpiNfIawEkbBQijgrx37G2NGIC015iPamahe0nEr8/uLMvTGabTe06gNmhrfV3BudskPSphc0HOqZh54vtzHQAk0VYVY40e15Ii/SaX190ImKGZeimDOr0VIf9ucIiHC06nfI/SJuBHwVsH8LyaIOPiPCqivqb9L4vhLR2lBKVWm+uavV6ZfGDgEYneFxHYbce2TXo X-MS-TrafficTypeDiagnostic: CO1NAM11HT005: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NXu4MjVzSnreNN/maU+52Yvrubt+NZIJw7BKWtbZuekdCcs0pt952JTluFj/CvYO+MKtKbL4LyLEunS/aQhDULIgfQLRw3L6xPa8cP0jaUip7m0a28FIAQ5pKR88k5IZNJoFpuGnQPZJrI0K0se5oOL/x/uOfrPf8st2EiywbiJyls1fTHkK0uvhBjz6JNMpj4VbV0yqRVz79EV4OY2ab52VY76Ewh0raBKngMk7lxnNb+NrSyEDhAvxs4xyJxT1 X-MS-Exchange-AntiSpam-MessageData: pWoMtYIALz9YOoaQrWOMnISxYxI0tjsIfvwlOfJM916fEHFyNttNjffJpIhKN0oruHCu9WrD9BnV+tnML/VbZ4LNpby26HC0PUFbIFpNMgqnfxbCbUKN4Fffmj7L1Fh12RRtaqXugJpGmCMEhRxu4SZjCxGaqAeBbEwM5vZHxcAhxHl8Cvihh4FF1gAASYAYlwwht9Rq/DHjfzkulAfsgg== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9dd1fca-7690-4186-4afb-08d84ea2bba3 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2020 18:13:32.0989 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT053.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Mike, I agree that's a good way to meet the requirement. Maintaining the two=20 APIs would just be a transient state (i.e. on order of days) to update=20 edk2-platforms users and then we could remove the old API, right? Our main concern was maintaining the two APIs side-by-side long term. Thanks, Michael On 8/28/2020 12:25 PM, Kinney, Michael D wrote: > Hi Michael, >=20 > There are implementations of FMpDeviceLib in edk2-platforms. So the cha= llenge is how > to prepare a set of patch series to edk2 and edk2-platforms where there = are no > intermediate states that break builds. Adding new APIs and later removi= ng the > old APIs is one way to meet this requirement. Do you have other ideas? >=20 > Mike >=20 >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Michael = Kubacki >> Sent: Friday, August 28, 2020 12:21 PM >> To: Sean Brogan ; devel@edk2.groups.io; Kinney, M= ichael D >> Cc: Gao, Liming ; Jiang, Guomin ; Xu, Wei6 ; Liu, Zhiguang >> >> Subject: Re: [edk2-devel] [PATCH v3 0/6] Extend Last Attempt Status Usa= ge >> >> Hi Mike, >> >> We've stated a few reasons we prefer to change the library API now. Do >> you find that acceptable for v4? >> >> Thanks, >> Michael >> >> On 8/21/2020 2:25 PM, Michael Kubacki wrote: >>> Hi Sean, >>> >>> Thanks for the feedback. >>> >>> #1 - I will include both suggestions in v4. >>> >>> Thanks, >>> Michael >>> >>> On 8/20/2020 7:37 PM, Sean Brogan wrote: >>>> Michael, >>>> >>>> #1 >>>> I would suggest calling out the sub-range >>>> >>>> 0x10A0 | 0x17FF=C2=A0 -- Free for Library Implementations of FmpDevic= ePkg >>>> >>>> I also might suggest splitting FmpDependencyLib and >>>> FmpDependencyCheckLib ranges just to show a consistent pattern of how >>>> each library instance within FmpDevicePkg gets a defined range. >>>> >>>> >>>> #2 >>>> Given that edk2 does not have any real FmpDeviceLibs (only instance i= s >>>> FmpDevicePkg\Library\FmpDeviceLibNull\FmpDeviceLibNull.inf).=C2=A0 No= w is >>>> the best time to make a breaking change. It is very common for >>>> downstream code repositories to integrate edk2 and be forced to make >>>> changes associated with the new integration.=C2=A0 To me this is >>>> preferred.=C2=A0 A build break is easy to resolve. When functionality >>>> changes or new features are added but don't cause a break this is mor= e >>>> difficult to integrate correctly.=C2=A0 Not only that, it leads to ne= arly >>>> everyone ignoring the change.=C2=A0 There is no need for this change = to be >>>> a multi-year integration or cause extra development of shims and >>>> translation functions.=C2=A0 The API change is pretty easy.=C2=A0 The >>>> implementation can choose to to avoid the new ranges and just set the >>>> value to 1 (FMP unknown error).=C2=A0 This would match the behavior o= f >>>> today.=C2=A0 Obviously i believe it would better to take the extra ti= me to >>>> create unique ranges for each of your libs.=C2=A0 Also note that if a= nyone >>>> is doing third party binary integration this is not a breaking >>>> change.=C2=A0 This only breaks for those doing a src build. >>>> >>>> Thanks >>>> Sean >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 8/20/2020 6:25 PM, Michael Kubacki wrote: >>>>> Hi Mike, >>>>> >>>>> 1) Yes, we can certainly leave more of the unsuccessful vendor range >>>>> available for future expansion. I believe we can also reduce the FMP >>>>> reserved range. How about a length of 0x800 for both? >>>>> >>>>> The ranges would then be defined as follows: >>>>> >>>>> START=C2=A0=C2=A0=C2=A0=C2=A0 | END=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= = =A0 | Usage >>>>> ------------------------------------------------------------------| >>>>> 0x1000=C2=A0=C2=A0=C2=A0 | 0x17FF=C2=A0=C2=A0=C2=A0 | FmpDevicePkg= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | >>>>> =C2=A0=C2=A0=C2=A0 0x1000 |=C2=A0=C2=A0=C2=A0 0x107F | FmpDxe drive= r=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | >>>>> =C2=A0=C2=A0=C2=A0 0x1080 |=C2=A0=C2=A0=C2=A0 0x109F | FMP dependen= cies (e.g. FmpDependencyLib)=C2=A0 | >>>>> 0x1800=C2=A0=C2=A0=C2=A0 | 0x1FFF=C2=A0=C2=A0=C2=A0 | FmpDeviceLib i= nstances implementation=C2=A0=C2=A0=C2=A0=C2=A0 | >>>>> 0x2000=C2=A0=C2=A0=C2=A0 | 0x3FFF=C2=A0=C2=A0=C2=A0 | Unused. Availa= ble for future expansion.=C2=A0=C2=A0 | >>>>> >>>>> Also, I don't see a problem with removing the length defines and >>>>> directly specifying min/max defines for each range. >>>>> >>>>> 2.) I understand the compatibility concern but as you noted it is >>>>> cleaner to maintain a single interface. I believe making the >>>>> transition to the new API will only become more difficult in the >>>>> future as it may go unnoticed resulting in implementations that don'= t >>>>> implement support for this capability leading to an increasing amoun= t >>>>> of future effort to do work that could be done now. Perhaps we could >>>>> get thoughts from others as well? >>>>> >>>>> 3.) I will update these to return back an expected value. >>>>> >>>>> Thanks, >>>>> Michael >>>>> >>>>> On 8/19/2020 7:57 PM, Kinney, Michael D wrote: >>>>>> Hi Michael, >>>>>> >>>>>> A couple a couple general questions: >>>>>> >>>>>> 1) I see the entire range from 0x2000-0x3FFF is reserved for >>>>>> FmpDeviceLib.=C2=A0 If we >>>>>> =C2=A0=C2=A0=C2=A0 every add more device/platform specific libs fo= r FMP, there are >>>>>> no ranges available. >>>>>> =C2=A0=C2=A0=C2=A0 Should we limit the FmpDeviceLib to a smaller r= ange to support >>>>>> future expansion? >>>>>> >>>>>> =C2=A0=C2=A0=C2=A0 Also, the style of LastAttemptStatus.h with ext= ra defines for >>>>>> the length of >>>>>> =C2=A0=C2=A0=C2=A0 each range is hard to read, and I do not think = there are any >>>>>> consumers of the >>>>>> =C2=A0=C2=A0=C2=A0 length defines from this public include file.= =C2=A0 Since there are >>>>>> really only 3 >>>>>> =C2=A0=C2=A0=C2=A0 defined ranges, couldn't this be simplified to = min/max defines >>>>>> for each range >>>>>> =C2=A0=C2=A0=C2=A0 for a total of 6 #defines.=C2=A0 I do not expec= t ranges (once >>>>>> defined) to change in >>>>>> =C2=A0=C2=A0=C2=A0 length, and the most that might happen in the f= uture is adding >>>>>> new ranges for >>>>>> =C2=A0=C2=A0=C2=A0 new lib classes in the unused ranges. >>>>>> >>>>>> 2) This series makes non-backwards compatible changes to some of th= e >>>>>> lib classes. >>>>>> =C2=A0=C2=A0=C2=A0 I agree this is the cleanest way to add support= for the vendor >>>>>> specific >>>>>> =C2=A0=C2=A0=C2=A0 last attempt status.=C2=A0 It does mean that ex= isting implementations >>>>>> will have >>>>>> =C2=A0=C2=A0=C2=A0 to update their lib implementations to be compa= tible with this >>>>>> new version. >>>>>> =C2=A0=C2=A0=C2=A0 I would be slightly cleaner to introduce new AP= Is with support >>>>>> for the >>>>>> =C2=A0=C2=A0=C2=A0 vendor specific last attempt status codes.=C2= =A0 Then update all libs >>>>>> to produce >>>>>> =C2=A0=C2=A0=C2=A0 both the existing APIs and the new APIs (The ol= d APIs can call >>>>>> the new APIs). >>>>>> =C2=A0=C2=A0=C2=A0 Then update FmpDxe to use the new APIs.=C2=A0 T= his would be 3 patch >>>>>> series. >>>>>> =C2=A0=C2=A0=C2=A0 If FmpDxe never calls the old APIs, then we cou= ld (at a future >>>>>> date) >>>>>> =C2=A0=C2=A0=C2=A0 delete the old APIs from the lib class and the = lib >>>>>> implementations could >>>>>> =C2=A0=C2=A0=C2=A0 remove the old API that calls the new API. >>>>>> >>>>>> 3) The following APIs in the Null implementations have OUT params. >>>>>> =C2=A0=C2=A0=C2=A0 Should these OUT params be set to an expected v= alue? >>>>>> >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CheckFmpDependency() >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDeviceGetImage() >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDeviceSetImage() >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Mike >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: michael.kubacki@outlook.com >>>>>>> Sent: Tuesday, August 18, 2020 2:16 PM >>>>>>> To: devel@edk2.groups.io >>>>>>> Cc: Gao, Liming ; Kinney, Michael D >>>>>>> ; Jiang, Guomin >>>>>>> ; Xu, >>>>>>> Wei6 ; Liu, Zhiguang >>>>>>> Subject: [PATCH v3 0/6] Extend Last Attempt Status Usage >>>>>>> >>>>>>> From: Michael Kubacki >>>>>>> >>>>>>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D2802 >>>>>>> >>>>>>> This patch series adds more granularity to Last Attempt Status >>>>>>> codes reported during FMP check image and set image operations >>>>>>> that greatly improve precision of the status codes. >>>>>>> >>>>>>> The unsuccessful vendor range (0x1000 - 0x4000) was introduced >>>>>>> in UEFI Specification 2.8. At a high-level, two subranges are >>>>>>> defined within that range in this patch series: >>>>>>> =C2=A0=C2=A0 1. The FMP Reserved range - reserved for components = implemented >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in FmpDevicePkg. >>>>>>> =C2=A0=C2=A0 2. The FMP Device Library Reserved range - reserved = for >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDeviceLib instance-specific usa= ge. >>>>>>> >>>>>>> The ranges are described in a public header file LastAttemptStatus= .h >>>>>>> while the specific codes used within FmpDevicePkg implementation >>>>>>> are defined in a private header file FmpLastAttemptStatus.h. >>>>>>> >>>>>>> FmpDeviceLib instances should use the range definition from the >>>>>>> public header file to define Last Attempt Status codes local to >>>>>>> their library instance. >>>>>>> >>>>>>> Of note, there's multiple approaches to assigning private status >>>>>>> codes in the FMP Reserved range. For example, individual component= s >>>>>>> could define their last attempt status codes locally with the >>>>>>> range allocated to the component defined in a package-wide private >>>>>>> header file. However, one goal of the granularity being introduced >>>>>>> is to provide straightforward traceability to an error source. >>>>>>> >>>>>>> For that reason, it was chosen to define a constant set of codes a= t >>>>>>> the package level in FmpLastAttemptStatus.h. For example, if a new >>>>>>> FmpDependencyLib instance is added, it would not be able to reassi= gn >>>>>>> status code values in the pre-existing FMP Dependency range; it >>>>>>> would reuse codes for the same error source and be able to add new >>>>>>> codes onto the range for its usage. I wanted to highlight this for >>>>>>> any feedback. >>>>>>> >>>>>>> V3 changes: >>>>>>> =C2=A0=C2=A0 1. Enhanced range definitions in LastAttemptStatus.h= with more >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 completeness providing length, min= , and max values. >>>>>>> =C2=A0=C2=A0 2. Moved the actual Last Attempt Status code assignm= ents to a >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 private header file PrivateInclude= /FmpLastAttemptStatus.h. >>>>>>> =C2=A0=C2=A0 3. Changed the value of >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_ERROR_UNSUCCES= SFUL_VENDOR_RANGE_MAX >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to 0x3FFF instead of 0x4000 even t= hough 0x4000 is defined in >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the UEFI specification. The length= is 0x4000 but the max >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 allowed value should be 0x3FFF. Th= is change was made now to >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prevent implementation compatibili= ty issues in the future. >>>>>>> =C2=A0=C2=A0 4. Included "DEVICE" in the following macro name to = clearly >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associate it with the FmpDeviceLib= library class: >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LAST_ATTEMPT_STATUS_DEVICE_LIBRARY= _ERROR_xxx >>>>>>> =C2=A0=C2=A0 5. Included a map to help the reader better visualiz= e the range >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 definitions in LastAttemptStatus.h= . >>>>>>> =C2=A0=C2=A0 6. Included additional documentation describing the = enum in >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpLastAttemptStatus.h. An explici= t statement stating that new >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 codes should be added onto the end= of ranges to preserve the >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 values was added. >>>>>>> =C2=A0=C2=A0 7. Simplified error handling logic in FmpDxe for Fmp= DeviceLib >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 calls that return Last Attempt Sta= tus. >>>>>>> =C2=A0=C2=A0 8. V2 had a single memory allocation failure code us= ed for >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different memory allocations in Ch= eckFmpDependency () in >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FmpDependencyLib. Each potential a= llocation failure was >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 assigned a unique code. >>>>>>> >>>>>>> V2 changes: >>>>>>> =C2=A0=C2=A0 1. Consolidate all previous incremental updates to >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LastAttemptStatus.h into one patch= (patch 2) >>>>>>> =C2=A0=C2=A0 2. Move LastAttemptStatus.h from Include to PrivateI= nclude >>>>>>> =C2=A0=C2=A0 3. Correct patch 1 subject from "FmpDevicePkg" to "M= dePkg" >>>>>>> >>>>>>> Cc: Liming Gao >>>>>>> Cc: Michael D Kinney >>>>>>> Cc: Guomin Jiang >>>>>>> Cc: Wei6 Xu >>>>>>> Cc: Zhiguang Liu >>>>>>> Signed-off-by: Michael Kubacki >>>>>>> >>>>>>> Michael Kubacki (6): >>>>>>> =C2=A0=C2=A0 MdePkg/SystemResourceTable.h: Add vendor range value= s >>>>>>> =C2=A0=C2=A0 FmpDevicePkg: Add Last Attempt Status header files >>>>>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDxe: Add check image path Last Attem= pt Status >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 capability >>>>>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDxe: Improve set image path Last Att= empt Status >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 granularity >>>>>>> =C2=A0=C2=A0 FmpDevicePkg: Add Last Attempt Status support to dep= endency libs >>>>>>> =C2=A0=C2=A0 FmpDevicePkg/FmpDeviceLib: Add Last Attempt Status t= o Check/Set API >>>>>>> >>>>>>> FmpDevicePkg/FmpDxe/FmpDxe.c | 176 +++++++++++++++++--- >>>>>>> FmpDevicePkg/Library/FmpDependencyCheckLib/FmpDependencyCheckLib.c >>>>>>> |=C2=A0 39 +++-- >>>>>>> FmpDevicePkg/Library/FmpDependencyCheckLibNull/FmpDependencyCheckL= ibNull.c >>>>>>> |=C2=A0=C2=A0 9 +- >>>>>>> FmpDevicePkg/Library/FmpDependencyLib/FmpDependencyLib.c |=C2=A0 9= 6 >>>>>>> +++++++++-- >>>>>>> FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c |=C2=A0 48 ++= ++-- >>>>>>> FmpDevicePkg/Test/UnitTest/Library/FmpDependencyLib/EvaluateDepend= encyUnitTest.c >>>>>>> |=C2=A0=C2=A0 7 +- >>>>>>> FmpDevicePkg/FmpDxe/FmpDxe.h |=C2=A0=C2=A0 4 +- >>>>>>> FmpDevicePkg/Include/LastAttemptStatus.h |=C2=A0 96 +++++++++++ >>>>>>> FmpDevicePkg/Include/Library/FmpDependencyCheckLib.h |=C2=A0=C2=A0= 8 +- >>>>>>> FmpDevicePkg/Include/Library/FmpDependencyLib.h |=C2=A0 44 +++-- >>>>>>> FmpDevicePkg/Include/Library/FmpDeviceLib.h |=C2=A0 48 ++++-- >>>>>>> FmpDevicePkg/PrivateInclude/FmpLastAttemptStatus.h |=C2=A0 80 ++++= +++++ >>>>>>> MdePkg/Include/Guid/SystemResourceTable.h |=C2=A0 13 ++ >>>>>>> =C2=A0 13 files changed, 575 insertions(+), 93 deletions(-) >>>>>>> =C2=A0 create mode 100644 FmpDevicePkg/Include/LastAttemptStatus.= h >>>>>>> =C2=A0 create mode 100644 >>>>>>> FmpDevicePkg/PrivateInclude/FmpLastAttemptStatus.h >>>>>>> >>>>>>> -- >>>>>>> 2.28.0.windows.1 >>>>>> >>>>> >>>>> >>>>> >> >>=20 >=20