Re: [edk2-devel] [PATCH 0/2] Support FDT library.

["Michael D Kinney" <michael.d.kinney@intel.com>]

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
> Sent: Tuesday, April 11, 2023 9:07 AM
> To: Tan, Lean Sheng <sheng.tan@9elements.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Warkentin, Andrei <andrei.warkentin@intel.com>; devel@edk2.groups.io;
> Lin, Benny <benny.lin@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu@intel.com>; Sean
> Brogan <sean.brogan@microsoft.com>; Michael Kubacki <mikuback@linux.microsoft.com>
> Subject: Re: [edk2-devel] [PATCH 0/2] Support FDT library.
> 
> On Tue, Apr 11, 2023 at 2:20 PM Lean Sheng Tan <sheng.tan@9elements.com> wrote:
> >
> > Thanks Mike for the proposal layout!
> > It sounds good to me :)
> >
> > Hi Pedro,
> > I went through the email chain again, basically these are 2 of your main concerns (correct me if I'm wrong):
> > 1. a good idea to at least ditch that specific copy (current FDT in Embedded Pkg) for a git submodule.
> > 2. Rework to remove/reduce libc Implementation as there is a problem with both libc fragments and compiler intrinsic
> fragments all over edk2. Should unify standards between crypto, libfdt, etc, could we try here
> >
> > I guess Mike has provided a plan to answer your first question, and the 2nd question would require a broader discussion
> with a few key owners.
> >
> > So it seems like we could get the current patchset from Benny Lin in for now? Any minor clean up needed for the current
> patch?
> >
> 
> No.
> 
> 3. Lots of questions and comments on the actual patch set regarding
> the quality of the libc implementation. Which should be fixed,
> regardless of centralizing a libc implementation.
>     Also questions on the FdtLib itself (why are we wrapping pure
> libfdt functions with FluffyIdentifierNames and SCARY_TYPEDEFS?).

This is done to accommodate potential future changes to the submodule APIs
and types.  The wrapper lib is a common practice in EDK II use of submodules.
The calling code can use the APIs/types defined in EDK II lib class.  If
there are changes to the submodule APIs/types, we only have to update one
location. Can also provide flexibility to move to a different submodule or
implementation if there is a better option in the future.

Look at CryptoPkg CryptoLibs as an example. We have an implementation that
layers on top of openssl.  We also have experiments looking at mbedtls. 
No changes to calling code that uses CrytoLibs.

>     I also sent out an RFC for a central libc for GCC/clang based
> toolchains, which should cover the libc usage of libfdt. Asked for
> testing, got ignored.

I provided feedback on your work on a central libc and asked if you are
able to test the libc uses currently checked into edk2.  Are you able to
help with that testing?

> 
> So a NAK from me, in its current state.
> 
> --
> Pedro
> 
> 
> 
>