From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mx.groups.io with SMTP id smtpd.web10.2915.1574070712232144765 for ; Mon, 18 Nov 2019 01:51:52 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.65, mailfrom: maciej.rabeda@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 orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2019 01:51:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,319,1569308400"; d="scan'208,217";a="258363563" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by FMSMGA003.fm.intel.com with ESMTP; 18 Nov 2019 01:51:49 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by IRSMSX153.ger.corp.intel.com ([169.254.9.119]) with mapi id 14.03.0439.000; Mon, 18 Nov 2019 09:51:48 +0000 From: "Rabeda, Maciej" To: "devel@edk2.groups.io" , "abner.chang@hpe.com" , "Wu, Jiaxin" Subject: Re: Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Topic: Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Index: AdWbBekFnGHFycz5Qx6FKZpWk4uEzQC6XgPA Date: Mon, 18 Nov 2019 09:51:48 +0000 Message-ID: <40FBBD5C52E8B4429773266A45BDCC174C6899E5@IRSMSX104.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjE4ZjYzZGMtM2ZkMi00OGIzLWFlMjQtYTk4YjgwYzhmZWE0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiY3Ftd3NJWlZ4dUZqaVwvRnhWYUJIT3FkXC96MlUxQ2dqMUVPZ2xudWRucmk5ekR2NHBFZlNjbGJ1anYxeWt4aXpZIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] MIME-Version: 1.0 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_40FBBD5C52E8B4429773266A45BDCC174C6899E5IRSMSX104gercor_" --_000_40FBBD5C52E8B4429773266A45BDCC174C6899E5IRSMSX104gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wyd= zial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-3= 16 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresat= a i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej w= iadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakie= kolwiek przegladanie lub rozpowszechnianie 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_40FBBD5C52E8B4429773266A45BDCC174C6899E5IRSMSX104gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

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.>

 

From: de= vel@edk2.groups.io <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= Structure DXE driver should stay with?

 

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łowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy G= dańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882= | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.

Ta wiadomość wraz z załącznikami jest przeznaczona = dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego = otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej us= unięcie; jakiekolwiek przeglądanie lub rozpowszechnianie 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 recipient, please contact the sender and delete all copies; any review or distribution by ot= hers is strictly prohibited.

--_000_40FBBD5C52E8B4429773266A45BDCC174C6899E5IRSMSX104gercor_--