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

[Giuseppe Scrivano]

Daniel P. Berrangé <address@hidden> writes:

> On Wed, Nov 14, 2018 at 04:36:02PM +0400, Marc-André Lureau wrote:
>> Hi,
>> 
>> Based-on: https://people.debian.org/~sthibault/qemu.git/ slirp branch
>> 
>> This series goal is to allow building libslirp as an independent library.

Marc-André, thanks for working on this!


> At least half of the patches in this series are deleting unused or
> unreachable code. I'd suggest you send all of those as a non-RFC
> series, as they are things we could merge straight away regardless
> of whether/when slirp becomes a separate 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.
>
> More recently there is this fun project which just pulled in the
> QEMU code and chopped out everything todo with slirp:
>
>   https://github.com/rootless-containers/slirp4netns

to give a little bit of background on slirp4netns:

slirp4netns is used for setting up the network in a network namespace
without requiring root privileges.

It is already used by Podman and Buildah to set up the network for
rootless containers, so they won't be limited to run in the host network
namespace or require a suid helper.

Coincidentally just today I was working on a slirp4netns change for
spawning a QEMU process instead of using the forked version.
I'd prefer to not rely on the slirp forked version, but this costs the
access to the underlying knobs.  With a separate libslirp project, this
is not needed anymore.

One change I am aware of in the forked version is the possibility to
tweak the MTU and AFAIK this is the only blocker from adopting libslirp
immediately.
Akihiro, is there anything more that could block slirp4netns from just
using libslirp once it is available?

Regards,
Giuseppe