[PATCHv8 00/15] net/lwip: add lwip library for the network stack

[Maxim Uvarov]

On Wed, 13 Sept 2023 at 19:14, Tom Rini <trini at konsulko.com> wrote:

> On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote:
> > > >> Then if for development you need  to pull he history of lwip, you
> can do it with:
> > > >> git pull -s subtree lwip  master --allow-unrelated-histories
> > > >> (but I think nobody will need this.)
> > > >>
> > > >> New update of the lwip net/lwip/lwip-external dir will be done with:
> > > >> git pull -s subtree lwip  master --allow-unrelated-histories
> --squash
> > > >> Squash commit also has to be git format-patch friendly.
> > > >>
> > > >> If you are ok with that proposal I will send v9 with the first
> patch created with steps above.
> > > >
> > > > We've gone through this before.  The whole purpose of this is not
> > > > having to maintain patches.
> > > > Simon, instead of "I had problems in the past", can you elaborate a
> bit more?
> > > >
> > > > Tom said he is fine with subtrees instead of submodules and I know
> for
> > > > a fact EDK2 doesn't have too many issues with submodules.
> > > > Their documentation is pretty clear on building and requires
> > > >
> > > > git clone https://github.com/tianocore/edk2.git
> > > > cd edk2
> > > > git submodule update --init
> > > >
> > > > Perhaps the situation has improved since you had issues?
> > >
> > > While I don't really care how you solve this technically, I'd
> *strongly*
> > > be interested for U-Boot to use *unmodified* lwIP sources where an
> > > explicit reference to an lwIP commit is used. I'd rather integrate
> > > bugfixes for U-Boot into lwIP than having the sources drift apart.
> >
> > Strongly agree here, we want to use upstream and all the combined
> > development and reviews etc rather than forking off and ending up with
> > yet another slightly different IP stack. The whole advantage of
> > adopting LWIP is the advantage of combined security, features and bugs
> > from a wide range of projects :-)
>
> Yes, this is what I want as well, and why I'm perhaps more agreeable
> with the approaches where it's a lot harder for us to start forking
> things unintentionally.  I gather submodule rather than subtree would be
> better for that case?
>
> --
> Tom
>

Yes, submodule will be a much better solution for us. And I also don't
think that today
there are any issues with submodules. It works well of OE, RPM and DEB
builds,
distributions should not have problems with it.

BR,
Maxim.