Re: Lwip 2.0.3 patches

[Samuel Thibault]

Hello,

Joan Lledó, le mar. 07 août 2018 18:09:54 +0200, a ecrit:
> > So your autoconf effort and that effort could probably be merged?
> 
> They recently removed their unix library from their lwip-contrib repo, and 
> are wroking on replacing GNU Autotools for CMake[1], so I don't think they 
> are interested in our work.

Well, sure, if they migrated to cmake they won't be interested in
autoconf efforts.  But then we could migrate to cmake too and have it
integrated.  And don't assume anything about interest unless explicitly
asked.  If they are not told what people would like, they can't be able
make good decisions.

The removal of the unix library is worrying, however.  Are they aware
that some people are using it?  If nobody complains, they won't know
that it poses problem.

> > Is it not possible to make them valid over all unix variants, and to have 
> > just a small unix-system-depend section?
> 
> They already are, in fact, our sys_arch.{c,h} are taken directly from their 
> lwip-contrib repo. I could try to send them back our little changes on those 
> two files (pthread_hurd_cond_wait_np and SYS_ARCH_INTR definitions), as they 
> could be useful as an example for others. But for the other two files, cc.h 
> and lwipopts.h, I don't see the point on sharing them, as the last one is 
> just our tunning, and our cc.h only makes sense with our lwipots.h.

I agree about lwipopts.h. For cc.h I don't see how it is really related
with lwipopts.h, it all looks like making lwip use unix libc things
(*16_* and *32_* could use inttypes.h's PRI* macros btw)

About sys_arch.[ch], ok if it's from lwip-contrib, but then it would be
useful to push the changes to the repo indeed, so that downstream only
has to pickup existing files and assemble the compilation.

It's also a question of maintenance: if they change things in their API,
they will update lwip-contrib. If we don't push our changes there, we'll
have to make the changes, most probably after the fact, and having to
dig out what needs to be done.

Really, upstreaming is always the better solution :)

Samuel