Re: [lwip-devel] Desiderata for 2.2.0: better support for Debian packaging and VirtualSquare

[Joan Lledó]

OMG, I missed this!


El 5/1/23 a les 13:51, Renzo Davoli ha escrit:
> 1- The code generated by contrib/ports/unix/lib has unresolved symbols:
> $ nm liblwip.so | grep ' U ' | grep -v @
>                  U sio_read
>                  U sio_tryread
> slirpif requires sio_read and sio_tryread.
> The patch named 1-libnoslip.patch excludes slip.c from the library

The patch is OK, but I don't kinda like the idea of adding the slipif.c 
to a cmake target (lwipnetif_SRCS) and then remove it explicitely for 
the Unix library. Would it be possible to use another approach?

> Does that mean everyone linking to that library has to provide
> sio_read/sio_tryread even if not using slipif right now? Or do we have
> lazy binding and this is only a "cleanup" thing?

I wrote that patch in 2018 and I honestly don't remember why I needed to 
remove slipif.c. Yesterday I tried to build the package, install it, 
link it to a test program during compilation and run it, all without 
removing slipif.c from the cmake target. I only saw some warnings about 
the missing methods during the package building, everything else worked 
fine for me. So maybe we don't need the patch at all. Renzo, have you 
tried to build/install/link/use the debian package without removing 
slipif.c?

> 2- CMakeLists.txt in contrib/ports/unix/lib lacks support for install and
> uninstall and the compatibility with linux sockaddr.
> The patch named 2-linuxlib.patch adds a new dir 
contrib/ports/unix/linuxlib
> to generate a more linux-consistent library.

I'm not sure about this. Would it be possible to add the new features to 
the already existing unix library? I would prefer to not have two 
libraries under the same port. If we wanted to create a new library 
specifically for Linux, it might be better to create a new port for 
linux instead of include a new library for the unix port. Besides, the 
current unix library is not only used for Linux, also for the Hurd. And 
the Debian package should work properly at least in Linux, Hurd and BSD 
systems, so calling it linuxlib doesn't fit its purpose. IMO the best 
thing we can do is to try to add as many features as possible to the 
current unix library.

> 3- Add VDE support (see 
https://wiki.virtualsquare.org/#!tutorials/vdebasics.md)
> The patch named 3-vdeif.patch adds an interface driver for vde.
> (It requires libvdeplug).

I know nothing about this, so I can't help.

> Joan, can I take you in here? What do you think would be required to
> make packaging lwIP into debian easier? This is kind of the last thing
> before releasing 2.2.0 I'm waiting for...

Of course, I'm interested in simplifying the Debian packaging for lwip, 
the more code from my patches that could be upstream, the better. In 
particular there are a few patches which are upstream but aren't 
included in 2.1.3 release:

https://savannah.nongnu.org/patch/?9350
https://savannah.nongnu.org/patch/?9807
https://security-tracker.debian.org/tracker/CVE-2020-8597

Apart from that, the most time consuming patch is usually max_sockes, 
which implements the unlimited number of sockets for lwip. If there are 
changes src/api/sockets.c in upstream, I need to adapt this patch to the 
new code and then test it works properly.

Thanks.