Thomas Huth <th...@redhat.com> writes: > On 2018-11-14 13:59, Markus Armbruster wrote: >> Marc-André Lureau <marcandre.lur...@redhat.com> writes: >> >>> Hi, >>> >>> Based-on: https://people.debian.org/~sthibault/qemu.git/ slirp branch >>> >>> This series goal is to allow building libslirp as an independent library. >>> >>> While looking at making SLIRP a seperate running process, I thought >>> that having an independent library from QEMU would be a first step. >>> >>> There has been some attempts to make slirp a seperate project in the past. >>> (https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01092.html) >>> Unfortunately, they forked from QEMU and didn't provide enough >>> compatibility for QEMU to make use of it (in particular, vmstate >>> handling was removed, they lost git history etc). Furthermore, they >>> are not maintained as far as I can see. >>> >>> I would propose to make slirp a seperate project, that can initially >>> be used by QEMU as a submodule, keeping Makefile.objs until a proper >>> shared library with stability guarantees etc is ready.. >>> >>> The subproject could created by preserving git tags, and cleaning up the >>> code style, this way: >>> >>> git filter-branch --tree-filter "if ls * 1> /dev/null 2>&1; then >>> clang-format -i * /dev/null; fi " -f --subdirectory-filter "slirp" >>> --prune-empty --tag-name-filter cat -- --all >>> (my clang-format >>> https://gist.github.com/elmarco/cb20c8d92007df0e2fb8a2404678ac73) >>> >>> What do you think? >> >> Has the slirp code been improved to be generally useful? I still got it >> filed under "friends don't let friends use that, except for testing"... > > The slirp code is already used in a lot of other projects:
The issue I have with SLIRP isn't that it solves a useless problem (au contraire!), it's that it's a useless solution. Okay, that's an unfair exaggeration, it's not useless, I just wouldn't trust it in production, unless it has improved significantly since I last looked at it. > - WinUAE > (https://github.com/tonioni/WinUAE/tree/master/slirp) > > - Previous > (https://sourceforge.net/p/previous/code/HEAD/tree/trunk/src/slirp/) > > - BasiliskII > (https://github.com/cebix/macemu/tree/master/BasiliskII/src/slirp) > > - Bochs > > (https://sourceforge.net/p/bochs/code/HEAD/tree/trunk/bochs/iodev/network/slirp/) > > ... and likely many more. AFAIK they all (or at least most) have been > forked from the QEMU code at one point in time and diverged, i.e. they > likely missed the bug fixes and new features that have been added in > QEMU (like IPv6). So yes, IMHO it makes a lot of sense to try to make a > separate library out of the slirp code again, especially if we could > convince the other projects to use it, too, and to collaborate on that > version. No objections to spinning it out, as long as it comes with a fair assessment of its limitations. Turning it into a proper project might even improve its chances to get improved towards production quality, compared to its current existence as a corner of QEMU next to nobody wants to touch.
