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

[Simon Glass]

Hi,

On Wed, 13 Sept 2023 at 07:35, Maxim Uvarov <maxim.uvarov at linaro.org> wrote:
>
>
>
> 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?

Nope.

>> > >
>> > > 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.

My particular experience is with coreboot. Some problems I have:

1. Updating the modules doesn't work and I need to reset, try the
--init thing, fetch things manually, etc. etc.
2. In ChromiumOS coreboot we can't use submodules internally since
each package has its own build script. E.g. we need to build coreboot
separately from its blobs, fsp, external libraries, etc. At least
there we can do this, but if U-Boot adopts a submodule for a core
feature, this is going to create no end of problems.
3. It makes it impossible to patch lwip for any fix we need for a release
4. We still have to 'fast forward' to a new commit every now and then,
which really is no easier than doing a merge commit for the changes
since the last sync, is it?

Really, we need a maintainer for the lwip piece, if we are to adopt
it. Using submodules is not a substitute for that.

Regards,
Simon