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: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
Date: Wed, 14 Nov 2018 14:30:38 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Nov 14, 2018 at 02:26:42PM +0000, Stefan Hajnoczi wrote:
> 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.
> > 
> > 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?
> 
> Great idea!
> 
> Maybe in the future there will be a tests too.  Right now my impression
> is that slirp isn't hardened and suitable for production use cases (i.e.
> security).  But with some love (and testing!) I think that could change.

With Marc-André's desire to move it to a separate process, it is the
kind of thing where seccomp could actually do a fairly good job as it
would be a narrow enough piece of functionality that you can put some
meaningful constraints around it.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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