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

["Richard W.M. Jones" <rjones@redhat.com>]

On Wed, Nov 14, 2018 at 01:59:25PM +0100, Markus Armbruster wrote:
> Marc-André Lureau <marcandre.lureau@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"...

SLIRP may or may not be bad internally -- I don't know -- but it
provides an unbeatable feature that nothing else replaces: no setup,
no root network access.  We use it all over the place.

The idea of these patches is to move SLIRP into a separate project and
have it run as a separate process.  This solves IMHO two problems:
qemu maintainers don't seem to like it, as demonstrated above, and if
there are any security problems them we can nail down the SLIRP
external process so it has literally no access to the host except for
the handful of network socket system calls it needs.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/