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? On Sat, 8 Apr 2023 at 01:04, Kinney, Michael D wrote: > 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 > > Sent: Friday, April 7, 2023 3:36 PM > > To: Pedro Falcato ; devel@edk2.groups.io; Tan, > Lean Sheng > > Cc: Lin, Benny ; Kinney, Michael D < > michael.d.kinney@intel.com>; Gao, Liming ; > > Liu, Zhiguang ; Sean Brogan < > sean.brogan@microsoft.com>; Michael Kubacki > > 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 > > > Sent: Friday, April 7, 2023 8:24 AM > > > To: devel@edk2.groups.io; Tan, Lean Sheng > > > Cc: Warkentin, Andrei ; Lin, Benny > > > ; Kinney, Michael D ; > > > Gao, Liming ; Liu, Zhiguang > > > ; Sean Brogan ; > > > Michael Kubacki > > > Subject: Re: [edk2-devel] [PATCH 0/2] Support FDT library. > > > > > > On Thu, Apr 6, 2023 at 5:34 PM Sheng Lean Tan > > > 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 >