Re: [edk2-devel] Which is the proper edk2 package the EFI REST Structure DXE driver should stay with?

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6325 bytes --]

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 RedfishPkg (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: devel@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.groups.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 driver 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 REST services which consumes EFI REST Structure driver for registering the convertor, others services could be AWS or Openstack. This driver is not really designed for Redfish only, although I believe Redfish is the only one to use this protocol. Actually, this driver mainly deals with the payload, less relationship to the specific REST service or underlying 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 drivers outside of NetworkPkg?
This driver doesn't depends on transport layer.

>>>Is REST currently consumed only by Redfish or is going to be extensively used outside that package?
Yes, this driver is current consumed by Redfish JSON to C structure drivers. But as mentioned above, this driver is not only for Redfish, could be extensively 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 could be pulled into build with the convertors according to the demand of platform.

Actually, neither RedfishPkg nor NetworkPkg are ideal packages to own EFI REST Structure driver IMO. My thought to put this driver in NetworkPkg is just 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 RedfishPkg if one or more people think we should let this driver goes to RedfishPkg :).

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<mailto:devel@edk2.groups.io>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>; Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>
Subject: RE: Which is the proper edk2 package the EFI REST Structure DXE driver should stay with?

Hi Abner,

REST as a more generic network API and could possibly be placed in NetworkPkg.
My concerns are:
Is REST in UEFI going to be HTTP-based or is it planned to be tied to drivers 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 used outside that package?
Even if it is HTTP-based, question of maintenance arises. If Redfish is the only consumer of REST API, I would leave it within RedfishPkg so that Redfish+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 added to NetworkPkg with some extra work.
I believe that, by default, 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 DXE 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.

Jiaxin,

What do you think?

Thanks,
Maciej

<Please disregard the legal disclaimer below. I'm working on it.>

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Abner Chang
Sent: Thursday, November 14, 2019 17:10
To: devel@edk2.groups.io<mailto: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 code 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 MdeModulePkg 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 Gdań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 usunię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 others is strictly prohibited.



[-- Attachment #2: Type: text/html, Size: 14214 bytes --]