Re: Lwip 2.0.3 patches
> > - Not intended to be upstream
> > autoconf
> > port
> Why not?
About port, it includes some stack configuration which is only valid for
us. About autoconf, the stack is distributed without any build system and
the user is expected to provide its own solution. They have a repo called
lwip-contrib which has some build systems as an example and for testing
purposes, it includes a library for unix systems.
> > - Won't get to upstream
> > posix
> Similarly, why not?
We were talking about this a year ago[1] and I wasn't able to find a
satisfactory solution. Do you think it's worth to keep trying? Any ideas?
> If they really don't want it, we definitely should make this patch more
> maitainable by avoiding to move code around, and instead put #ifdef
> #endif around, so that changes to that code will not bring patch
> conflicts.
It's OK for me.
> > max_sockets
> I guess they didn't want to cripple their source code? It's arguably
> not very intrusive...
Mmmm, maybe this shouldn't be in that section. I've been reading the
discussion[2] we had past year an they were open to apply the patch but
after solving a problem on fd_set definition. Finally, the discussion went
to a dead end and I forgot it, but the patch could get to upstream if we
solve that problem, any ideas?
------------------------------------------------------
[1] https://savannah.nongnu.org/patch/?9350
[2] https://lists.nongnu.org/archive/html/lwip-devel/2017-08/msg00029.html
Missatge de Samuel Thibault <sthibault@debian.org> del dia dt., 1 de maig
2018 a les 1:52:
> Samuel Thibault, le mar. 01 mai 2018 01:34:42 +0200, a ecrit:
> > > - Won't get to upstream
> > > posix
> >
> > Similarly, why not?
> If they really don't want it, we definitely should make this patch more
> maitainable by avoiding to move code around, and instead put #ifdef
> #endif around, so that changes to that code will not bring patch
> conflicts.
> Samuel
Reply to: