The main advantage of the new lib is that it depends on a submodule for the FDT
content so we can easily move to new releases for bug fixes or features.

The FDT content in the EmbeddedPkg is a snap-shot of the code from a long time
ago.  We have been discouraging that approach and trying to move to released
content from a well support submodule if one is available.

Once this new better supported version is accepted, we can then incrementally
remove the duplicate content with the existing consumers moving from use of
EmbeddedPkg version to the MdePkg version and finally the removal of the
duplicate content in the EmbeddedPkg.

Mike

> -----Original Message-----
> From: Warkentin, Andrei <andrei.warkentin@intel.com>
> Sent: Friday, April 7, 2023 3:36 PM
> To: Pedro Falcato <pedro.falcato@gmail.com>; devel@edk2.groups.io; Tan, Lean Sheng <sheng.tan@9elements.com>
> Cc: Lin, Benny <benny.lin@intel.com>; Kinney, Michael D <michael.d.kinney@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.
>
> I think in general it would be nice to understand the long term picture of a change, esp. since there is already FDT support in
> EDK2 in various forms (with libraries and drivers depending on the existing FdtLib). So it would really of confusing to see
> another FDT library in MdePkg, without a clear reasoning for the work (this isn't reflected in the BZ) and a clear action plan
> to end up with just one FDT library in MdePkg in some identified time frame.
>
> I do think FDT lib *does* belong in MdePkg, but it seems the shortest path to get there is to simply move the existing
> EmbeddedPkg one (and update all users). Subsequent cleanup can be incremental. And regardless, every existing FdtLib user ought
> to be updated to use the new one, so there need to be more patches (we're not just throwing the code over the wall, right?)
>
> A
>
> > -----Original Message-----
> > From: Pedro Falcato <pedro.falcato@gmail.com>
> > Sent: Friday, April 7, 2023 8:24 AM
> > To: devel@edk2.groups.io; Tan, Lean Sheng <sheng.tan@9elements.com>
> > Cc: Warkentin, Andrei <andrei.warkentin@intel.com>; Lin, Benny
> > <benny.lin@intel.com>; Kinney, Michael D <michael.d.kinney@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 Thu, Apr 6, 2023 at 5:34 PM Sheng Lean Tan
> > <sheng.tan@9elements.com> wrote:
> > >
> > > Thanks for the nice feedback Pedro, Gerd and Andrei! Yeah it seems like a
> > valid concern here as Mik mentioned on edk2-libc, and it seems to fits edk2
> > long term interest on this.
> > > Can we file this as an issue in Bugzilla for tracking or something? Since this
> > will take some time to work on this as it involves a bigger discussion,
> > personally I think we could get this FDT patch in first meanwhile, and also
> > remove the FDT from Embedded Pkg as next step, per discussion with Leif?
> > > What do you think?
> >
> > I'm all for not merging this without a proper solution in that regard (I even
> > presented a quick RFC solution which wasn't tested by anyone involved in
> > this patch, yet).
> >
> > But if there really is an urgent need for this lib, I'm O-K with merging this
> > given that all my concerns are addressed (minus libc duplication).
> >
> > --
> > Pedro