From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx.groups.io with SMTP id smtpd.web10.1071.1573110791440858893 for ; Wed, 06 Nov 2019 23:13:11 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: jiewen.yao@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 23:13:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,277,1569308400"; d="scan'208";a="377334934" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 06 Nov 2019 23:13:10 -0800 Received: from fmsmsx606.amr.corp.intel.com (10.18.126.86) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 6 Nov 2019 23:13:10 -0800 Received: from fmsmsx606.amr.corp.intel.com (10.18.126.86) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 6 Nov 2019 23:13:09 -0800 Received: from shsmsx106.ccr.corp.intel.com (10.239.4.159) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 6 Nov 2019 23:13:09 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.108]) by SHSMSX106.ccr.corp.intel.com ([169.254.10.248]) with mapi id 14.03.0439.000; Thu, 7 Nov 2019 15:13:08 +0800 From: "Yao, Jiewen" To: "Ni, Ray" , "devel@edk2.groups.io" CC: "Wang, Jian J" , "Wu, Hao A" , "Lou, Yun" Subject: Re: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add DeviceSecurity.h Thread-Topic: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add DeviceSecurity.h Thread-Index: AQHVj+cEIgzkXKmuDkyX050d2kV/CKd9zqVA//+CzwCAAaG0oIAANBLQgAAtxlA= Date: Thu, 7 Nov 2019 07:13:07 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F841FBA@shsmsx102.ccr.corp.intel.com> References: <20191031123012.16020-1-jiewen.yao@intel.com> <20191031123012.16020-3-jiewen.yao@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C35174D@SHSMSX104.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F83EBF9@shsmsx102.ccr.corp.intel.com> <15D4BEC95EBB70CB.18056@groups.io> <734D49CCEBEEF84792F5B80ED585239D5C352CE8@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C352CE8@SHSMSX104.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODE3MTMyY2MtODMyOC00OWZiLWE4ZWUtMmVkNmJiNmY5ZGU5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZlp0OGd0ZDhpdzZrVUhrb1N2Ym5QV0dLRW41a0k5VUtnanNIcGNsZHE3NXZnSTlHZ2xkN1pOUE5VbXp4WGxTRyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jiewen.yao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have thought that before. The rule I take is always to add the original data structure name as prefi= x, to avoid name space collision. The meaning of " EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID" is actually "EDKII= _DEVICE_IDENTIFIER.TYPE_PCI_GUID" I have a little concern if I name it to "EDKII_DEVICE_TYPE_PCI", it may co= nflict with other generic name. As such, I prefer to keep the current definition. Thank you Yao Jiewen > -----Original Message----- > From: Ni, Ray > Sent: Thursday, November 7, 2019 12:32 PM > To: devel@edk2.groups.io; Ni, Ray ; Yao, Jiewen > > Cc: Wang, Jian J ; Wu, Hao A = ; > Lou, Yun > Subject: RE: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add > DeviceSecurity.h >=20 > Jiewen, > "xxx_DEVICE_IDENTIFIER_TYPE_xxx" sounds a bit strange to me because > I feel "IDENTIFIER" and "TYPE" are different properties to describe a de= vice. > Or you think some other GUIDs may be defined in future as the device ID? >=20 > Thanks, > Ray >=20 > > -----Original Message----- > > From: devel@edk2.groups.io On Behalf Of Ni, Ray > > Sent: Thursday, November 7, 2019 9:59 AM > > To: Yao, Jiewen ; devel@edk2.groups.io > > Cc: Wang, Jian J ; Wu, Hao A ; > > Lou, Yun > > Subject: Re: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add > > DeviceSecurity.h > > > > I see. PciIo or UsbIo instance is installed with a different GUID and = consumer > > needs to parse the device path to understand what kind of instance (Pc= iIo or > > UsbIo) should be used. > > > > > -----Original Message----- > > > From: Yao, Jiewen > > > Sent: Wednesday, November 6, 2019 4:25 PM > > > To: Ni, Ray ; devel@edk2.groups.io > > > Cc: Wang, Jian J ; Wu, Hao A > > > ; Lou, Yun > > > Subject: RE: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add > > > DeviceSecurity.h > > > > > > HI > > > Good comment. Let me answer it in 2 parts. > > > > > > 1) The consumer may locate the deice path to know the device type. I= n > > > this part, you can treat this as redundant information. > > > > > > 2) But we still need a new GUID, because I will install the device > > > access protocol on this new GUID for the temporary access for the > > authentication driver only. > > > > > > I don't want to install the device access protocol to the original > > > UEFI spec defined GUID to notify everyone that the device is ready t= o > > > use, because I have seen some device drivers have callback function = (such > > as ATA passthru, or NVME passthru) to start access the device once the > > device access protocol is installed. > > > > > > > > > Thank you > > > Yao Jiewen > > > > > > > -----Original Message----- > > > > From: Ni, Ray > > > > Sent: Wednesday, November 6, 2019 3:56 PM > > > > To: devel@edk2.groups.io; Yao, Jiewen > > > > Cc: Wang, Jian J ; Wu, Hao A > > > > ; Lou, Yun > > > > Subject: RE: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add > > > > DeviceSecurity.h > > > > > > > > > + /// > > > > > + /// Type of the device. > > > > > + /// This field is also served as a device Access protocol GUI= D. > > > > > + /// The device access protocol is installed on the DeviceHand= le. > > > > > + /// The device access protocol is device specific. > > > > > + /// EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID means the device > > access > > > > protocol is PciIo. > > > > > + /// EDKII_DEVICE_IDENTIFIER_TYPE_USB_GUID means the device > > access > > > > protocol is UsbIo. > > > > > + /// > > > > > + EFI_GUID DeviceType; > > > > > > > > Do we still need DeviceType? Consumer can query the Handle to > > > > understand the device type. > > > >=20