public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Shah, Tapan" <tapandshah@hpe.com>
To: "Carsey, Jaben" <jaben.carsey@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	Rebecca Cran <rebecca@bluestop.org>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg
Date: Fri, 17 Feb 2017 16:46:59 +0000	[thread overview]
Message-ID: <CS1PR84MB0024CE5BB69E4AA0D48DE9FAD45D0@CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CB6E33457884FA40993F35157061515C54B75FFC@FMSMSX103.amr.corp.intel.com>

Agree on the number of includes in that header file.

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

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<mailto:jiewen.yao@intel.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>>; Carsey, Jaben <jaben.carsey@intel.com<mailto: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


  reply	other threads:[~2017-02-17 16:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 22:47 EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg Rebecca Cran
2017-02-16 22:58 ` Yao, Jiewen
2017-02-16 22:59 ` Shah, Tapan
2017-02-16 23:12   ` Yao, Jiewen
2017-02-17 15:42     ` Shah, Tapan
2017-02-17 16:03       ` Carsey, Jaben
2017-02-17 16:46         ` Shah, Tapan [this message]
2017-02-16 23:16   ` Rebecca Cran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CS1PR84MB0024CE5BB69E4AA0D48DE9FAD45D0@CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox