From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0F00982137 for ; Fri, 17 Feb 2017 08:03:23 -0800 (PST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 08:03:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,172,1484035200"; d="scan'208,217";a="65953229" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga005.jf.intel.com with ESMTP; 17 Feb 2017 08:03:22 -0800 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.47]) by FMSMSX106.amr.corp.intel.com ([169.254.5.63]) with mapi id 14.03.0248.002; Fri, 17 Feb 2017 08:03:21 -0800 From: "Carsey, Jaben" To: "Shah, Tapan" , "Yao, Jiewen" , Rebecca Cran , "edk2-devel@lists.01.org" , "Gao, Liming" CC: "Carsey, Jaben" Thread-Topic: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg Thread-Index: AQHSiKaxetCFev83bUGOBaYig3ptGaFsxYCAgAADqgCAARR1gP//f3uA Date: Fri, 17 Feb 2017 16:03:20 +0000 Message-ID: References: <27f6c46b-aebe-a250-eb17-b93267c12a82@bluestop.org> <74D8A39837DF1E4DA445A8C0B3885C503A8EFF4F@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjYxN2YyNTQtNWJkMS00MTJlLTlkZDEtZWVlOTgzNWJhOGVmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImZsSUNyS1pweDBtMXRpWkk1c2ZSdFZKc05QdW5ZUjZpZk9SOVR2WEl1alk9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.1.200.108] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 16:03:23 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The reason for the structs is as Tapan said. The Shell must support all du= mps 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 ; Rebecca Cran = ; edk2-devel@lists.01.org; Gao, Liming ; Carsey, Jabe= n Subject: RE: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and Shel= lPkg Importance: High There is no rule that says consumer of the code cannot define their own str= uctures (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 stru= ctural way instead of hard-coded method to parse the data. Liming and Jaben agreed on this idea of having V1, V2 in UefiHandleParsingL= ib 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 >; Rebecca Cr= an >; edk2-devel@lists.01= .org; Gao, Liming > Subject: RE: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and Shel= lPkg 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 Last= AttemptVersion/ LastAttemptStatus/ HardwareInstance in V2. Thank you Yao Jiewen > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Sh= ah, > Tapan > Sent: Thursday, February 16, 2017 3:00 PM > To: Rebecca Cran >; edk= 2-devel@lists.01.org; Gao, Liming > > > 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 def= ined. > > 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 > Subject: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and > ShellPkg > > I'm a bit confused about why Firmware Management Protocol image descripto= r > structures are split between MdePkg and ShellPkg: > > In MdePkg/Include/Protocol/FirmwareInformation.h there's the definition o= f > 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 s= ome > seemingly-unrelated stuff - and that file appears to have a ridiculous nu= mber 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 > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel