From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx.groups.io with SMTP id smtpd.web09.1113.1573111010378948349 for ; Wed, 06 Nov 2019 23:16:50 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.93, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 23:16:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,277,1569308400"; d="scan'208";a="227742285" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga004.fm.intel.com with ESMTP; 06 Nov 2019 23:16:50 -0800 Received: from fmsmsx606.amr.corp.intel.com (10.18.126.86) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 6 Nov 2019 23:16:49 -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:16:49 -0800 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) 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:16:49 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.127]) by SHSMSX154.ccr.corp.intel.com ([169.254.7.200]) with mapi id 14.03.0439.000; Thu, 7 Nov 2019 15:16:47 +0800 From: "Ni, Ray" 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 Thread-Topic: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add DeviceSecurity.h Thread-Index: AQHVj+cEIaKpMCv2u0qN7YFGo9tarKd9zqVA//+CzwCAAaG0oIAANBLQ//+od4CAAIajQA== Date: Thu, 7 Nov 2019 07:16:47 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C352F44@SHSMSX104.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> <74D8A39837DF1E4DA445A8C0B3885C503F841FBA@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F841FBA@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I didn't think about that naming space issue. I agree with your current nam= e. > -----Original Message----- > From: Yao, Jiewen > Sent: Thursday, November 7, 2019 3:13 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 >=20 > I have thought that before. >=20 > The rule I take is always to add the original data structure name as pre= fix, to > avoid name space collision. >=20 > The meaning of " EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID" is actually > "EDKII_DEVICE_IDENTIFIER.TYPE_PCI_GUID" >=20 > I have a little concern if I name it to "EDKII_DEVICE_TYPE_PCI", it may = conflict > with other generic name. >=20 > As such, I prefer to keep the current definition. >=20 > Thank you > Yao Jiewen >=20 >=20 > > -----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 > > > > 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 I= D? > > > > Thanks, > > Ray > > > > > -----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 (PciIo 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. > > > > In 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 > > > > to 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 G= UID. > > > > > > + /// The device access protocol is installed on the DeviceHa= ndle. > > > > > > + /// 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