qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
Date: Wed, 14 Nov 2018 17:52:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]