Re: Lwip 2.0.3 patches
Hello,
Joan Lledó, le sam. 05 mai 2018 08:01:29 +0000, a ecrit:
> > > - Not intended to be upstream
> > > autoconf
> > > port
>
> > Why not?
>
> About port, it includes some stack configuration which is only valid for
> us.
Is it not possible to make them valid over all unix variants, and to
have just a small unix-system-depend section?
Apart from get_monotonic_time() (which could be made to revert to
gettimeofday() if nothing else is found), a quick look didn't show me
anything that is really OS-dependend, provided the availability of a
Unix interface. Yes, there is for instance #define pthread_cond_wait
pthread_hurd_cond_wait_np, but that's very simple tuning.
> 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.
So your autoconf effort and that effort could probably be merged?
> > > - 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?
Yes I think it's worth to keep trying. Being able to buid lwip as a
unix userland library is actually something useful beyond just GNU/Hurd.
We happen to have a couple of packages doing this in Debian for
instance.
I haven't dived in the details so probably no precise idea that you
wouldn't have tried.
But generally speaking, I'd say don't hesitate to revamp the way lwip
organizes its headers. For instance glibc took a very intrusive step by
moving, if needed, the definition of very type, structure, etc. to its
own header, so that it's easy to redirect it the way it is needed.
> > > 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?
Again, I bevelieve it could be useful beyond just GNU/Hurd, so it'd be
worth trying to pursue integration.
Samuel
Reply to: