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

 

 

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