From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx.groups.io with SMTP id smtpd.web09.18359.1574151338131440084 for ; Tue, 19 Nov 2019 00:15:38 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.24, mailfrom: jiaxin.wu@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2019 00:15:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,322,1569308400"; d="scan'208,217";a="258652741" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 19 Nov 2019 00:15:37 -0800 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 19 Nov 2019 00:15:36 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 19 Nov 2019 00:15:36 -0800 Received: from shsmsx107.ccr.corp.intel.com ([169.254.9.63]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.149]) with mapi id 14.03.0439.000; Tue, 19 Nov 2019 16:15:34 +0800 From: "Wu, Jiaxin" To: "devel@edk2.groups.io" , "abner.chang@hpe.com" , "Rabeda, Maciej" Subject: Re: [edk2-devel] Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Topic: [edk2-devel] Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Index: AdWbBekFnGHFycz5Qx6FKZpWk4uEzQC6XgPAACbJVXAACAdxIA== Date: Tue, 19 Nov 2019 08:15:33 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B727416FA5A4B@SHSMSX107.ccr.corp.intel.com> References: <40FBBD5C52E8B4429773266A45BDCC174C6899E5@IRSMSX104.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODczZTY1M2ItZWI4ZC00MDYyLTkxYWQtYWQ1NWVmZTNkNGU1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNlhPOUNSXC9YaWxkTnV4RHM3aXFYbUxHZG5iYVRcLzBDcHk3WWswbXFtaWNEWnFXcytLRzBKT1RCS05YdytKdjUyIn0= 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: jiaxin.wu@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_895558F6EA4E3B41AC93A00D163B727416FA5A4BSHSMSX107ccrcor_" --_000_895558F6EA4E3B41AC93A00D163B727416FA5A4BSHSMSX107ccrcor_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Abner, I just prefer put it with REST(EX) driver. So, how about keep it under Red= fishPkg since the REST driver will still under RedfishPkg (currently)? I kn= ow it's a generic and centralized driver to do the converting, but the fact= of the matter is no other consumer except for UEFI Redfish feature, or do = you have the real other usage cases? In the future, based on the real usage case in UEFI, we can consider wheth= er need to move that driver with the REST(EX) driver to NetworkPkg or not. = What do you think? Thanks, Jiaxin From: devel@edk2.groups.io On Behalf Of Abner Chang Sent: Tuesday, November 19, 2019 12:02 PM To: Rabeda, Maciej ; devel@edk2.groups.io; Wu, Ji= axin Subject: Re: [edk2-devel] Which is the proper edk2 package the EFI REST St= ructure DXE driver should stay with? Hi Maciej, EFI REST Structure driver is designed as a generic and centralized driver = for REST JSON payload to C structure convertors. Redfish payload in JSON fo= rmat is one of the REST services which consumes EFI REST Structure driver f= or registering the convertor, others services could be AWS or Openstack. Th= is driver is not really designed for Redfish only, although I believe Redfi= sh is the only one to use this protocol. Actually, this driver mainly deals= with the payload, less relationship to the specific REST service or underl= ying transports although HTTP is used for carrying REST payload in the most= of cases. In responding to your questions, >>>Is REST in UEFI going to be HTTP-based or is it planned to be tied to d= rivers outside of NetworkPkg? This driver doesn't depends on transport layer. >>>Is REST currently consumed only by Redfish or is going to be extensivel= y used outside that package? Yes, this driver is current consumed by Redfish JSON to C structure driver= s. But as mentioned above, this driver is not only for Redfish, could be ex= tensively used by other REST services. >>> I believe that, by default, REST driver build will be controlled by a = separate flag and disabled by default... Yes, this driver is not necessary to be built as default. this driver coul= d be pulled into build with the convertors according to the demand of platf= orm. Actually, neither RedfishPkg nor NetworkPkg are ideal packages to own EFI = REST Structure driver IMO. My thought to put this driver in NetworkPkg is j= ust because "REST" related driver is mentioned in Network Protocols in UEFI= spec. Which I feel more comfortable than put this driver in RedfishPkg. However, I don't have preference on this. We can keep this driver in Redfi= shPkg if one or more people think we should let this driver goes to Redfish= Pkg :). Yep, what's your opinion Jiaxin? Thanks Abner From: Rabeda, Maciej [mailto:maciej.rabeda@intel.com] Sent: Monday, November 18, 2019 5:52 PM To: devel@edk2.groups.io; Chang, Abner (HPS S= W/FW Technologist) >; Wu, J= iaxin > Subject: RE: Which is the proper edk2 package the EFI REST Structure DXE d= river should stay with? Hi Abner, REST as a more generic network API and could possibly be placed in Network= Pkg. My concerns are: Is REST in UEFI going to be HTTP-based or is it planned to be tied to driv= ers outside of NetworkPkg? If it is going to be more generic, I do not think that it = is a good idea to tie it with other network drivers within NetworkPkg Is REST currently consumed only by Redfish or is going to be extensively u= sed outside that package? Even if it is HTTP-based, question of maintenance arises. If Redfish is th= e only consumer of REST API, I would leave it within RedfishPkg so that Red= fish+REST could be treated as a whole solution by the package maintainer. In case REST is planned to be used outside of RedfishPkg, it could be adde= d to NetworkPkg with some extra work. I believe that, by default, REST driver build will be controlled by a sepa= rate flag and disabled by default (no need for it in regular network stack = use cases like PXE/iSCSI/HTTP boot). Additionally, if REST DXE build is requested, one would have to ensure tha= t dependant drivers like HttpDxe will be included and built within NetworkP= kg and outside of it (by consumers like OvmfPkg). For example: there is a preprocessor mechanism used in NetworkPkg/NetworkD= efines.dsc.inc to throw a compiler error in case TLS is not included if HTT= PS support is requested. Jiaxin, What do you think? Thanks, Maciej From: devel@edk2.groups.io > On Behalf Of Abner Chang Sent: Thursday, November 14, 2019 17:10 To: devel@edk2.groups.io Subject: [edk2-devel] Which is the proper edk2 package the EFI REST Struct= ure DXE driver should stay with? Hi all, I would like to get your suggestion with regard to the suitable edk2 packa= ge for EFI REST Structure DXE driver. We have POC code for this protocol (r= efer to UEFI spec 2.8, section 29.7.3) and currently this driver is impleme= nted in RedfishPkg. However, this driver is not for Redfish only. Either Ne= towrkPkg or MdeModulePkg is better than RedfishPkg. I prefer to put this dr= iver in NetworkPkg, but it's fine to me if you have other opinions. Thanks Abner --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. S=B3owackiego 173 | 80-298 Gda=F1sk | S=B1d Rejonowy Gda=F1sk P=F3=B3n= oc | VII Wydzia=B3 Gospodarczy Krajowego Rejestru S=B1dowego - KRS 101882 |= NIP 957-07-52-316 | Kapita=B3 zak=B3adowy 200.000 PLN. Ta wiadomo=B6=E6 wraz z za=B3=B1cznikami jest przeznaczona dla okre=B6lone= go adresata i mo=BFe zawiera=E6 informacje poufne. W razie przypadkowego ot= rzymania tej wiadomo=B6ci, prosimy o powiadomienie nadawcy oraz trwa=B3e je= j usuni=EAcie; jakiekolwiek przegl=B1danie lub rozpowszechnianie jest zabro= nione. This e-mail and any attachments may contain confidential material for the = sole use of the intended recipient(s). If you are not the intended recipien= t, please contact the sender and delete all copies; any review or distribut= ion by others is strictly prohibited. --_000_895558F6EA4E3B41AC93A00D163B727416FA5A4BSHSMSX107ccrcor_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Abner,

 

I just prefer put it with REST(EX) driver. So, how = about keep it under RedfishPkg since the REST driver will still under Redfi= shPkg (currently)? I know it’s a generic and centralized driver to do= the converting, but the fact of the matter is no other consumer except for UEFI Redfish feature, or do you have the = real other usage cases?

 

In the future, based on the real usage case in UEFI= , we can consider whether need to move that driver with the REST(EX) driver= to NetworkPkg or not. What do you think?

 

Thanks,

Jiaxin

 

 

 

 

From: de= vel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Abner Chang
Sent: Tuesday, November 19, 2019 12:02 PM
To: Rabeda, Maciej <maciej.rabeda@intel.com>; devel@edk2.grou= ps.io; Wu, Jiaxin <jiaxin.wu@intel.com>
Subject: Re: [edk2-devel] Which is the proper edk2 package the EFI = REST Structure DXE driver should stay with?

 

Hi Maciej,=

EFI REST Structure dr= iver is designed as a generic and centralized driver for REST JSON payload = to C structure convertors. Redfish payload in JSON format is one of the RES= T services which consumes EFI REST Structure driver for registering the convertor, others services could be AWS or Ope= nstack. This driver is not really designed for Redfish only, although I bel= ieve Redfish is the only one to use this protocol. Actually, this driver ma= inly deals with the payload, less relationship to the specific REST service or underlying transports althou= gh HTTP is used for carrying REST payload in the most of cases.<= /span>

 

In responding to your= questions,

>>>Is REST in UEFI going to be HTTP-based = or is it planned to be tied to drivers outside of NetworkPkg?

This driver doesnR= 17;t depends on transport layer.

 

>>>Is REST currently consumed only by Redf= ish or is going to be extensively used outside that package?

Yes, this driver is c= urrent consumed by Redfish JSON to C structure drivers. But as mentioned ab= ove, this driver is not only for Redfish, could be extensively used by othe= r REST services.

 

>>> I believe that, by default, REST drive= r build will be controlled by a separate flag and disabled by default…= ;

Yes, this driver is n= ot necessary to be built as default. this driver could be pulled into build= with the convertors according to the demand of platform.=

 

Actually, neither Red= fishPkg nor NetworkPkg are ideal packages to own EFI REST Structure driver = IMO. My thought to put this driver in NetworkPkg is just because “RES= T” related driver is mentioned in Network Protocols in UEFI spec. Which I feel more comfortable than put this driver in Redfi= shPkg.

However, I don’= t have preference on this. We can keep this driver in RedfishPkg if one or = more people think we should let this driver goes to RedfishPkg J.

 

Yep, what’s you= r opinion Jiaxin?

 

Thanks

Abner

 

 

From: Rabeda, Maciej [mailto:maciej.rabeda@intel.com]
Sent: Monday, November 18, 2019 5:52 PM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Wu, Jiaxin <jiaxin.wu@intel.com>
Subject: RE: Which is the proper edk2 package the EFI REST Structur= e DXE driver should stay with?

 

Hi Abner,

 

REST as a more generic network API and could possib= ly be placed in NetworkPkg.

My concerns are:

Is REST in UEFI going to be HTTP-based or is it pla= nned to be tied to drivers outside of NetworkPkg?

        &nb= sp;       If it is going to be more generic, = I do not think that it is a good idea to tie it with other network drivers = within NetworkPkg

 

Is REST currently consumed only by Redfish or is go= ing to be extensively used outside that package?

Even if it is HTTP-based= , question of maintenance arises. If Redfish is the only consumer of REST A= PI, I would leave it within RedfishPkg so that Redfish+REST could be tr= eated as a whole solution by the package maintainer.

 

In case REST is planned = to be used outside of RedfishPkg, it could be added to NetworkPkg with some= extra work.

I believe that, by defau= lt, REST driver build will be controlled by a separate flag and disabled by= default (no need for it in regular network stack use cases like PXE/iSCSI/= HTTP boot).

Additionally, if REST DX= E build is requested, one would have to ensure that dependant drivers like = HttpDxe will be included and built within NetworkPkg and outside of it (by = consumers like OvmfPkg).

For example: there is a = preprocessor mechanism used in NetworkPkg/NetworkDefines.dsc.inc to throw a= compiler error in case TLS is not included if HTTPS support is requested.<= o:p>

 

Jiaxin,

 

What do you think?

 

Thanks,

Maciej

 

<Please disregard the legal disclaimer below. I&= #8217;m working on it.>

 

 

Hi all,

I would like to get your suggestion with regard to = the suitable edk2 package for EFI REST Structure DXE driver. We have POC co= de for this protocol (refer to UEFI spec 2.8, section 29.7.3) and currently= this driver is implemented in RedfishPkg. However, this driver is not for Redfish only. Either NetowrkPkg or MdeMod= ulePkg is better than RedfishPkg. I prefer to put this driver in NetworkPkg= , but it’s fine to me if you have other opinions.

 

Thanks

Abner

--------------------------------------------------------------------- Intel Technology Poland sp. z o.o.
ul. S=B3owackiego 173 | 80-298 Gda=F1sk | S= =B1d Rejonowy Gda=F1sk P=F3=B3noc | VII Wydzia=B3 Gospodarczy Krajowego Re= jestru S=B1dowego - KRS 101882 | NIP 957-07-52-316 | Kapita=B3 zak=B3adowy 200.000 PLN.

Ta wiadomo= =B6=E6 wraz z za=B3=B1cznikami jest przeznaczona dla okre=B6lonego adresat= a i mo=BFe zawiera=E6 informacje poufne. W razie przypadkowego otrzymania t= ej wiadomo=B6ci, prosimy o powiadomienie nadawcy oraz trwa=B3e jej usuni=EAcie; jakiekolwiek przegl=B1danie lub rozpowszechnian= ie jest zabronione.
This e-mail and any attachments may contain confidential material for the = sole use of the intended recipient(s). If you are not the intended recipien= t, please contact the sender and delete all copies; any review or distribut= ion by others is strictly prohibited.

 

--_000_895558F6EA4E3B41AC93A00D163B727416FA5A4BSHSMSX107ccrcor_--