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

[Markus Armbruster]

Thomas Huth <address@hidden> writes:

> On 2018-11-14 15:46, Markus Armbruster wrote:
>> Thomas Huth <address@hidden> writes:
>> 
>>> 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:
>> 
>> 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,

... as I immediately admit ...

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

... right in the next 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.

If my joke offended Samuel, or anyone, I offer my sincere apologies.

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

I'm afraid we're in violent agreement there.  I wrote:

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