From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gMwoe-0004vf-Qq for qemu-devel@nongnu.org; Wed, 14 Nov 2018 10:10:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gMwob-0004Zf-HC for qemu-devel@nongnu.org; Wed, 14 Nov 2018 10:10:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34548) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gMwob-0004XN-9B for qemu-devel@nongnu.org; Wed, 14 Nov 2018 10:10:49 -0500 Date: Wed, 14 Nov 2018 15:10:43 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20181114151042.GA2391@work-vm> References: <20181114123643.24091-1-marcandre.lureau@redhat.com> <871s7nstle.fsf@dusky.pond.sub.org> <874lcjra28.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <874lcjra28.fsf@dusky.pond.sub.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Thomas Huth , renzo@cs.unibo.it, Jan Kiszka , qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, samuel.thibault@ens-lyon.org, =?iso-8859-1?Q?Marc-Andr=E9?= Lureau * Markus Armbruster (armbru@redhat.com) wrote: > Thomas Huth writes: >=20 > > On 2018-11-14 13:59, Markus Armbruster wrote: > >> Marc-Andr=E9 Lureau writes: > >>=20 > >>> Hi, > >>> > >>> Based-on: https://people.debian.org/~sthibault/qemu.git/ slirp bran= ch > >>> > >>> This series goal is to allow building libslirp as an independent li= brary. > >>> > >>> 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 th= e past. > >>> (https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01092.htm= l) > >>> 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 initiall= y > >>> be used by QEMU as a submodule, keeping Makefile.objs until a prope= r > >>> shared library with stability guarantees etc is ready.. > >>> > >>> The subproject could created by preserving git tags, and cleaning u= p the code style, this way: > >>> > >>> git filter-branch --tree-filter "if ls * 1> /dev/null 2>&1; then cl= ang-format -i * /dev/null; fi " -f --subdirectory-filter "slirp" --prune-= empty --tag-name-filter cat -- --all > >>> (my clang-format https://gist.github.com/elmarco/cb20c8d92007df0e2f= b8a2404678ac73) > >>> > >>> What do you think? > >>=20 > >> Has the slirp code been improved to be generally useful? I still go= t 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: >=20 > The issue I have with SLIRP isn't that it solves a useless problem (au > contraire!), it's that it's a useless solution. 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. It's now used as a critical part of 'rootless-containers' - i.e. running containers with no priviledges; see: https://github.com/rootless-containers/slirp4netns/ Dave > > - WinUAE > > (https://github.com/tonioni/WinUAE/tree/master/slirp) > > > > - Previous > > (https://sourceforge.net/p/previous/code/HEAD/tree/trunk/src/slirp/= ) > > > > - BasiliskII > > (https://github.com/cebix/macemu/tree/master/BasiliskII/src/slirp) > > > > - Bochs > > > > (https://sourceforge.net/p/bochs/code/HEAD/tree/trunk/bochs/iodev/net= work/slirp/) > > > > ... and likely many more. AFAIK they all (or at least most) have been > > forked from the QEMU code at one point in time and diverged, i.e. the= y > > likely missed the bug fixes and new features that have been added in > > QEMU (like IPv6). So yes, IMHO it makes a lot of sense to try to make= a > > separate library out of the slirp code again, especially if we could > > convince the other projects to use it, too, and to collaborate on tha= t > > version. >=20 > No objections to spinning it out, as long as it comes with a fair > assessment of its limitations. >=20 > Turning it into a proper project might even improve its chances to > get improved towards production quality, compared to its current > existence as a corner of QEMU next to nobody wants to touch. >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK