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

[Simon Goldschmidt]

On 21.09.2023 18:29, Simon Glass wrote:
> 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.

As an lwIP maintainer, I cannot step up as a maintainer of lwIP in
U-Boot, however, I can assure you I will do my best to work with you on
integrating fixes into upstream lwIP if required.

Without wanting to promote using submodules: all other examples of lwIP
being copied into another repository have practically never resulted in
bugfixes being sent back to us (ok, that's not 100% true, but we do get
them only once in a while) and being like that, those projects are
facing problems upgrading our stack in turn. I wouldn't want to be a
maintainer of such code, either.

Regards,
Simon