Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project

[Thomas Huth]

On 2018-11-14 13:59, Markus Armbruster wrote:
> Marc-André Lureau <address@hidden> 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:

- 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.

 Thomas