On 2018-11-14 15:46, Markus Armbruster wrote: > 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.
Ouch, that was completely arrogant and inappropriate. It's far away from being useless, and Samuel is doing a very good job in picking up all the patches and fixes that have been posted in the past months. Have you had a look at the changelog at all before you wrote that sentence? > 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. Nobody said that the slirp code would suddenly be perfect, but if it's getting even more traction and attention as a separate library (since other projects might contribute their fixes back "upstream" in that case), it could really get a solid building block for a lot of emulators and similar software. Thomas
