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

[Tom Rini]

On Fri, Sep 22, 2023 at 12:56:58PM +0200, Simon Goldschmidt wrote:
> 
> 
> 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.

So, ideally once we've integrated lwip, I'd be having us track the
stable tags, rather than top of tree. Is this what you'd recommend,
first of all?  And second, assuming we can take STABLE_2_2_0 once it's
released how often do you envision updates?  I ask since maybe things do
move slow enough that if I make some of my local every-time test scripts
stop and confirm it's OK to have some changes to net/ (or where ever...)
I can make sure we don't diverge and then like the calendar entries I do
have to remind me to check with a resync to X I could do that for lwip.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230922/01fad80f/attachment.sig>