[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 :|
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, (continued)
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Thomas Huth, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Markus Armbruster, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Dr. David Alan Gilbert, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Richard W.M. Jones, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Thomas Huth, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Markus Armbruster, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Dr. David Alan Gilbert, 2018/11/14
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Daniel P . Berrangé, 2018/11/14
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project, Stefan Hajnoczi, 2018/11/14
- Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project,
Daniel P . Berrangé <=