From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by mx.groups.io with SMTP id smtpd.web11.13367.1681219203968654018 for ; Tue, 11 Apr 2023 06:20:04 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@9elements.com header.s=google header.b=USn/f+uW; spf=pass (domain: 9elements.com, ip: 209.85.218.54, mailfrom: sheng.tan@9elements.com) Received: by mail-ej1-f54.google.com with SMTP id dm2so20391838ejc.8 for ; Tue, 11 Apr 2023 06:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9elements.com; s=google; t=1681219202; x=1683811202; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zSIoxSRomp6tKFGhBbzGHhTUtUNGl7jyPCkLfffyyhc=; b=USn/f+uWvOxI5SR4SXJp/GB8gK3SWlrdV9faE2B4C8A2JO/2sLZ92GbvwqbEMgELxY WgF2WKkXjkMTMiz0BbRH3MpjGRIE5Fw6v9xfvdHMYVhoPh+d8gWJ1rVWh78olGqjOiwM GhX5mPTWI7M1eRukf4TnpOlQ8CizVNbEVxgWy4UaVuHmo/eImjsylHznyNRdJFiH7lT8 /f+s0K28B3MFZ2ssY2gWyJsexWuNu5g4KvJONYMEjb4QbfnhVNEOB2klaa0Ap11sWpr4 FYG2AKvAqR15BVrS5XzmATyh8PFEgDBPH5BmU19a2rIMQ1IQiSSFp8H6qCxIoc0eiVAI X8aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681219202; x=1683811202; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zSIoxSRomp6tKFGhBbzGHhTUtUNGl7jyPCkLfffyyhc=; b=jO3rb/79NR7ss0RMdlqpAw+jiDrAeprtNkLk7+nCZDxPCQdAv+UPbLowOCYpSSoNuO L8VX61819xV1A6cAX36+/KViH759Q5Bz2P61GI89m5cTLlHF4CujHp02WqPytxpLxMfk +kawlqioLBUjMfNUrQl8bGuZGl+F5cUrm/TrxnqPyWUcz//CXKipdRqvzHZRstzC7Maw INvGDaNNHrLu8gxMiIi5ssMNIufsulYhss3gZAJOekXHdU2gnE3Bc8ZvXyPOeRgtIUid pXmZYgv37p65GsZ1dP8CsMOa/qv+iysQvVHpuoTirtfn79g9Z0rGZfFmZ8H+Kre7qu8N jIRw== X-Gm-Message-State: AAQBX9c44sSl0rFoZ+pspn92qzt5JjMq/VPgmA58deX+e/n2QXJLNV6D CGJ6Tjjw6+6kgBzwW1gjWof6G2IbV0H8IsNXvYPTHA== X-Google-Smtp-Source: AKy350bZvofH+knPoNjpgR7kmjYEHWnB99jJ3F0340DPxDDOpczVcqXC2D8wexrph6Smvs/zhuiyl27xQukvpyoLp9E= X-Received: by 2002:a17:906:dac9:b0:933:1967:a984 with SMTP id xi9-20020a170906dac900b009331967a984mr4397358ejb.15.1681219202295; Tue, 11 Apr 2023 06:20:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Sheng Lean Tan" Date: Tue, 11 Apr 2023 15:19:26 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH 0/2] Support FDT library. To: "Kinney, Michael D" Cc: "Warkentin, Andrei" , Pedro Falcato , "devel@edk2.groups.io" , "Lin, Benny" , "Gao, Liming" , "Liu, Zhiguang" , Sean Brogan , Michael Kubacki Content-Type: multipart/alternative; boundary="00000000000057beaa05f90f59fa" --00000000000057beaa05f90f59fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM 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 fit= s > 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 discussio= n, > > > personally I think we could get this FDT patch in first meanwhile, an= d > 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 > --00000000000057beaa05f90f59fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mike for the proposal layout!
It sounds good to= me :)

Hi Pedro,
I went through t= he 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 speci= fic copy (current FDT in Embedded=C2=A0Pkg) for a git submodule.
= 2. Rework to remove/reduce libc Implementation as there is a problem with b= oth libc fragments and compiler intrinsic fragments all over edk2. Should u= nify standards between crypto, libfdt, etc, could we try here
I guess Mike has provided a plan to answer your first=C2=A0ques= tion, and the 2nd question would require a broader discussion with a few ke= y=C2=A0owners.

So it seems like we could get the c= urrent patchset from Benny Lin in for now? Any minor clean up needed for th= e current patch?



On Sat, 8 Apr 2023 at 01:04, Kinn= ey, Michael D <michael.d.k= inney@intel.com> wrote:
The main advantage of the new lib is that it depends on a su= bmodule 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 t= ime
ago.=C2=A0 We have been discouraging that approach and trying to move to re= leased
content from a well support submodule if one is available.

Once this new better supported version is accepted, we can then incremental= ly
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@9ele= ments.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&g= t;; 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 pictur= e of a change, esp. since there is already FDT support in
> EDK2 in various forms (with libraries and drivers depending on the exi= sting 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 incr= emental. 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: dev= el@edk2.groups.io; Tan, Lean Sheng <sheng.tan@9elements.com>
> > Cc: Warkentin, Andrei <andrei.warkentin@intel.com>; Lin, Benny
> > <benn= y.lin@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> > Gao, Liming <gaoliming@byosoft.com.cn>; Liu, Zhiguang
> > <z= higuang.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=E2=80=AFPM 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 som= ething? Since this
> > will take some time to work on this as it involves a bigger discu= ssion,
> > 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 wit= h Leif?
> > > What do you think?
> >
> > I'm all for not merging this without a proper solution in tha= t 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 w= ith merging this
> > given that all my concerns are addressed (minus libc duplication)= .
> >
> > --
> > Pedro
--00000000000057beaa05f90f59fa--