Re: EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

["Carsey, Jaben" <jaben.carsey@intel.com>]

The reason for the structs is as Tapan said.  The Shell must support all dumps that customers require.

The reason for the includes is that it needs to include each protocol that it may dump.

I agree that the number of includes looks insane.

-Jaben

From: Shah, Tapan [mailto:tapandshah@hpe.com]
Sent: Friday, February 17, 2017 7:42 AM
To: Yao, Jiewen <jiewen.yao@intel.com>; Rebecca Cran <rebecca@bluestop.org>; edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>; Carsey, Jaben <jaben.carsey@intel.com>
Subject: RE: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg
Importance: High

There is no rule that says consumer of the code cannot define their own structures (in this case UefiHandleParsingLib in ShellPkg needs to consume V1 and V2). Having V1, V2 structures make it easy to decode the data in a structural way instead of hard-coded method to parse the data.

Liming and Jaben agreed on this idea of having V1, V2 in UefiHandleParsingLib when we decided to add FMP V1,V2,V3 decode support in 'dh' command. See attached old discussion on this agreement.

From: Yao, Jiewen [mailto:jiewen.yao@intel.com]
Sent: Thursday, February 16, 2017 5:13 PM
To: Shah, Tapan <tapandshah@hpe.com<mailto:tapandshah@hpe.com>>; Rebecca Cran <rebecca@bluestop.org<mailto:rebecca@bluestop.org>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
Subject: RE: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

Yes, I agree that SHELL pkg should dump V1 only and V2 only data structure.

I just think there is no need to add new data structure there.
The shell pkg can just skip LowestSupportedImageVersion in V1 and skip LastAttemptVersion/ LastAttemptStatus/ HardwareInstance in V2.


Thank you
Yao Jiewen

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Shah,
> Tapan
> Sent: Thursday, February 16, 2017 3:00 PM
> To: Rebecca Cran <rebecca@bluestop.org<mailto:rebecca@bluestop.org>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Gao, Liming
> <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> Subject: Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and
> ShellPkg
>
> UEFI Spec does not have old FMP image descriptor structures V1 and V2 defined.
>
> MdePkg only follows the spec, so it contains the latest version # 3. But there are
> still drivers using old V1, V2 revisions and Shell 'dh' command needs to support
> decoding all revisions and needs to remain in ShellPkg.
>
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Rebecca Cran
> Sent: Thursday, February 16, 2017 4:48 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Subject: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and
> ShellPkg
>
> I'm a bit confused about why Firmware Management Protocol image descriptor
> structures are split between MdePkg and ShellPkg:
>
> In MdePkg/Include/Protocol/FirmwareInformation.h there's the definition of
> EFI_FIRMWARE_IMAGE_DESCRIPTOR (version 3).  But then the
> EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1 and
> EFI_FIRMWARE_IMAGE_DESCRIPTOR_V2 struct definitions are in
> ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.h along with some
> seemingly-unrelated stuff - and that file appears to have a ridiculous number of
> #include's!
>
>
> Is there a reasoning behind putting the older structures in ShellPkg, or should
> they be moved to FirmwareInformation.h?
>
>
> --
>
> Rebecca
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel