From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com [148.163.156.75]) (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 9B76721A13487 for ; Thu, 4 May 2017 07:59:41 -0700 (PDT) Received: from pps.filterd (m0098781.ppops.net [127.0.0.1]) by mx0a-00010702.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v44EtjrC018480; Thu, 4 May 2017 09:59:40 -0500 Received: from ni.com (skprod2.natinst.com [130.164.80.23]) by mx0a-00010702.pphosted.com with ESMTP id 2a72m56r7u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 May 2017 09:59:40 -0500 Received: from us-aus-exhub1.ni.corp.natinst.com (us-aus-exhub1.ni.corp.natinst.com [130.164.68.41]) by us-aus-skprod2.natinst.com (8.16.0.17/8.16.0.17) with ESMTPS id v44ExdWQ015990 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 4 May 2017 09:59:39 -0500 Received: from us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) by us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 4 May 2017 09:59:39 -0500 Received: from jmw-lm181.ni.corp.natinst.com (130.164.49.7) by us-aus-exhub1.ni.corp.natinst.com (130.164.68.41) with Microsoft SMTP Server id 15.0.1156.6 via Frontend Transport; Thu, 4 May 2017 09:59:39 -0500 Date: Thu, 4 May 2017 09:59:39 -0500 From: Jeff Westfahl X-X-Sender: jwestfah@jmw-lm181 To: "Carsey, Jaben" CC: Jeff Westfahl , "edk2-devel@lists.01.org" , "Ni, Ruiyu" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705040237 Subject: Re: ShellPkg: Difference in behavior of 'dh' between old shell and new X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:59:41 -0000 Content-Type: text/plain; charset="US-ASCII"; format=flowed Hi Jaben, No PI protocols can be required means that I can try to use them? And gracefully handle the case where they aren't found? Regards, Jeff On Wed, 19 Apr 2017, Carsey, Jaben wrote: > That would be welcome; I don't know how it was missed. A caveat is that the shell should use UEFI protocols only. No PI protocols can be required (optional is ok). > > Only the specific output controlled by "-sfo" is severely constrained by the spec. > >> -----Original Message----- >> From: Jeff Westfahl [mailto:jeff.westfahl@ni.com] >> Sent: Wednesday, April 19, 2017 10:36 AM >> To: edk2-devel@lists.01.org >> Cc: Carsey, Jaben ; Ni, Ruiyu >> Subject: [edk2] ShellPkg: Difference in behavior of 'dh' between old shell and >> new >> Importance: High >> >> I noticed a difference in behavior of 'dh' between the old shell and the new shell. >> With the old shell, 'dh -v' for a LoadedImage handle shows the >> following: >> >> Handle D3 (3A537F98) >> Image (3A532818) File:MicrocodeUpdate >> ParentHandle..: 3A64F118 >> SystemTable...: 3D2A8F18 >> DeviceHandle..: 3B1B2098 >> FilePath......: FvFile(F3331DE6-4A55-44E4-B767-7453F7A1A021) >> ImageBase.....: 3D650000 - 3D655540 >> ImageSize.....: 5540 >> CodeType......: RT_code >> DataType......: RT_data >> >> With the new shell, I get this for the same LoadedImage handle: >> >> D3: 3A537F98 >> LoadedImage >> Revision......: 0x00001000 >> ParentHandle..: 3A64F118 >> SystemTable...: 3D2A8F18 >> DeviceHandle..: 3B1B2098 >> FilePath......: 3A539018 >> OptionsSize...: 0 >> LoadOptions...: 0 >> ImageBase.....: 3D650000 >> ImageSize.....: 5540 >> CodeType......: EfiRuntimeServicesCode >> DataType......: EfiRuntimeServicesData >> Unload........: 0 >> >> The old shell shows the name of the file associated with the LoadedImage, >> which seems like useful information. Is this omission intentional or an oversight? >> Would a patch adding the file name to ShellPkg be welcomed? >> >> Regards, >> Jeff >