Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
> 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? No, the only blocker is MTU (which significantly improves the bandwidth from 1.07 Gbps to 9.21 Gbps : https://github.com/rootless-containers/slirp4netns/tree/19ec5cf6b8f562ebaed6d4004c8b172907ea6adb#benchmarks ) In future I think we want to support checksum offloading and multiqueue/multithread, but these can be experimented and discussed after we get support for the standalone libslirp. https://github.com/rootless-containers/slirp4netns/issues/16 https://github.com/rootless-containers/slirp4netns/issues/17 2018年11月16日(金) 0:49 Giuseppe Scrivano : > Daniel P. Berrangé 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 >
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
Daniel P. Berrangé 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
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
* Markus Armbruster (arm...@redhat.com) wrote: > Thomas Huth writes: > > > On 2018-11-14 15:46, Markus Armbruster wrote: > >> Thomas Huth writes: > >> > >>> On 2018-11-14 13:59, Markus Armbruster wrote: > Marc-André Lureau 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"... > >>> > >>> The slirp code is already used in a lot of other projects: > >> > >> The issue I have with SLIRP isn't that it solves a useless problem (au > >> contraire!), it's that it's a useless solution. > > > > Ouch, that was completely arrogant and inappropriate. It's far away from > > being useless, > > ... as I immediately admit ... > > >and Samuel is doing a very good job in picking up all the > > patches and fixes that have been posted in the past months. Have you had > > a look at the changelog at all before you wrote that sentence? > > ... right in the next sentence: > > >> 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. > > If my joke offended Samuel, or anyone, I offer my sincere apologies. > > > Nobody said that the slirp code would suddenly be perfect, but if it's > > getting even more traction and attention as a separate library (since > > other projects might contribute their fixes back "upstream" in that > > case), it could really get a solid building block for a lot of emulators > > and similar software. > [...] > > I'm afraid we're in violent agreement there. I wrote: > > >> No objections to spinning it out, as long as it comes with a fair > >> assessment of its limitations. > >> > >> 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. One thought is that it might actually be the best standalone stack around at the moment; I mean while I'm seeing people objecting to bits of SLIRP, I'm not seeing anyone saying 'Why don't you just use ' Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
Thomas Huth writes: > On 2018-11-14 15:46, Markus Armbruster wrote: >> Thomas Huth writes: >> >>> On 2018-11-14 13:59, Markus Armbruster wrote: Marc-André Lureau 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"... >>> >>> The slirp code is already used in a lot of other projects: >> >> The issue I have with SLIRP isn't that it solves a useless problem (au >> contraire!), it's that it's a useless solution. > > Ouch, that was completely arrogant and inappropriate. It's far away from > being useless, ... as I immediately admit ... >and Samuel is doing a very good job in picking up all the > patches and fixes that have been posted in the past months. Have you had > a look at the changelog at all before you wrote that sentence? ... right in the next sentence: >> 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. If my joke offended Samuel, or anyone, I offer my sincere apologies. > Nobody said that the slirp code would suddenly be perfect, but if it's > getting even more traction and attention as a separate library (since > other projects might contribute their fixes back "upstream" in that > case), it could really get a solid building block for a lot of emulators > and similar software. [...] I'm afraid we're in violent agreement there. I wrote: >> No objections to spinning it out, as long as it comes with a fair >> assessment of its limitations. >> >> 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.
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
On 2018-11-14 15:46, Markus Armbruster wrote: > Thomas Huth writes: > >> On 2018-11-14 13:59, Markus Armbruster wrote: >>> Marc-André Lureau 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"... >> >> The slirp code is already used in a lot of other projects: > > The issue I have with SLIRP isn't that it solves a useless problem (au > contraire!), it's that it's a useless solution. Ouch, that was completely arrogant and inappropriate. It's far away from being useless, and Samuel is doing a very good job in picking up all the patches and fixes that have been posted in the past months. Have you had a look at the changelog at all before you wrote that sentence? > 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. Nobody said that the slirp code would suddenly be perfect, but if it's getting even more traction and attention as a separate library (since other projects might contribute their fixes back "upstream" in that case), it could really get a solid building block for a lot of emulators and similar software. Thomas
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
On 14/11/18 15:30, Daniel P. Berrangé wrote: On Wed, Nov 14, 2018 at 02:26:42PM +, Stefan Hajnoczi wrote: On Wed, Nov 14, 2018 at 04:36:02PM +0400, Marc-André Lureau wrote: [...] 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. It will also become easier to fuzz.
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
On Wed, Nov 14, 2018 at 03:46:39PM +0100, Markus Armbruster wrote: > 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 used by virt-builder, virt-customize, virt-v2v, etc., in some cases in production. Of course those uses are not completely general purpose (it'll be things like running very specific, known ‘yum install’ commands from the guest), and we test it quite a bit. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
* Markus Armbruster (arm...@redhat.com) wrote: > Thomas Huth writes: > > > On 2018-11-14 13:59, Markus Armbruster wrote: > >> Marc-André Lureau 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"... > > > > The slirp code is already used in a lot of other projects: > > 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/network/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. they > > 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 that > > version. > > No objections to spinning it out, as long as it comes with a fair > assessment of its limitations. > > 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. > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
Thomas Huth writes: > On 2018-11-14 13:59, Markus Armbruster wrote: >> Marc-André Lureau 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"... > > The slirp code is already used in a lot of other projects: 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. > - 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/network/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. they > 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 that > version. No objections to spinning it out, as long as it comes with a fair assessment of its limitations. 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.
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
On Wed, Nov 14, 2018 at 02:26:42PM +, 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
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. signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
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. 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 If the libslirp you propose can satisfy their integration needs it would be a positive validation of the need for & benefit of a standalone libslirp. > 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.. A sub-module sounds ok in short term, but from a distro packaging POV, I think there'd be strong pressure to unbundle it as quickly as possible, even immediately. A lack of stable ABI would not be ideal, but it is not a show stopper either - it would just mean relatively frequent rebuilds for soname changes which is something that happens quite a bit already for other deps we have in Fedora: $ grep soname qemu.spec - Rebuild for libiscsi changed soname again - Rebuild for changed Xen sonames - Rebuild to pick up changed libxen* sonames - Rebuild for libiscsi soname bump - Rebuild for changed xen soname > 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) FWIW, when I split the libvirt python binding out of the main libvirt repo, I needed a few more commands to fully clean the git repo, otherwise the git repo size was still enourmous despite having very few files left. At the time I ran this: $ git clone libvirt libvirt-python $ cd libvirt-python $ git filter-branch --subdirectory-filter python --tag-name-filter cat -- --all $ git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d $ git reflog expire --expire=now --all $ git gc --prune=now https://www.redhat.com/archives/libvir-list/2013-September/msg00413.html > What do you think? I think it sounds worthwhile given the number of times this has come up before and the fact that people are forking QEMU already to get access to slirp code. A standalone project could potentially draw in more contributors who are otherwise put off by it being part of the bigger QEMU project, and/or unable to even use it as part of QEMU. This could ultimately improve slirp's quality. 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
On Wed, Nov 14, 2018 at 01:59:25PM +0100, Markus Armbruster wrote: > Marc-André Lureau 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/
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
On 2018-11-14 13:59, Markus Armbruster wrote: > Marc-André Lureau 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"... The slirp code is already used in a lot of other projects: - 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/network/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. they 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 that version. Thomas
Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
Marc-André Lureau 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"...
[Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project
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? Marc-André Lureau (41): slirp: move socket pair creation in helper function glib-compat: add g_spawn_async_with_fds() fallback slirp: simplify fork_exec() slirp: remove unused M_TRAILINGSPACE slirp: use a callback structure to interface with qemu slirp: add a callback for qemu_chr_fe_write_all() slirp: add clock_get_ns() callback slirp: add callbacks for timer slirp: add a set_nonblock() callback slirp: remove PROBE_CONN dead-code slirp: remove FULL_BOLT slirp: remove the disabled readv()/writev() code path slirp: remove HAVE_SYS_SIGNAL_H slirp: remove unused HAVE_SYS_BITYPES_H slirp: remove NO_UNIX_SOCKETS slirp: remove unused HAVE_SYS_STROPTS_H slirp: remove unused HAVE_ARPA_INET_H slirp: remove unused HAVE_SYS_WAIT_H slirp: remove unused HAVE_SYS_SELECT_H slirp: remove HAVE_SYS_IOCTL_H slirp: remove HAVE_SYS_FILIO_H slirp: remove unused DECLARE_IOVEC slirp: remove unused HAVE_INET_ATON slirp: replace HOST_WORDS_BIGENDIAN with glib equivalent slirp: replace SIZEOF_CHAR_P with glib equivalent slirp: replace compile time DO_KEEPALIVE slirp: remove unused global slirp_instance slirp: replace error_report() with g_critical() slirp: improve a bit the debug macros slirp: replace trace functions with DEBUG calls slirp: add a callback to log guest errors slirp: remove unused sbflush() slirp: replace qemu_notify_event() with a callback slirp: remove #if notdef dead code slirp: NULL is defined by glib (at least) slirp: remove dead TCP_ACK_HACK code slirp: replace ARRAY_SIZE with G_N_ELEMENTS net: do not depend on slirp internals slirp: move QEMU state saving to a separate unit slirp: replace remaining QEMU dependency build-sys: add a basic meson build include/glib-compat.h | 56 ++ net/colo.h| 3 +- net/util.h| 55 + slirp/debug.h | 47 - slirp/ip.h| 24 ++- slirp/ip6.h | 8 +- slirp/ip6_icmp.h | 22 +- slirp/libslirp.h | 35 +++- slirp/main.h | 4 - slirp/mbuf.h | 1 - slirp/qtailq.h| 218 slirp/sbuf.h | 3 +- slirp/slirp.h | 58 ++ slirp/slirp_config.h | 86 slirp/socket.h| 1 + slirp/state.h | 9 + slirp/tcp.h | 4 +- slirp/util.h | 145 + net/colo-compare.c| 1 + net/colo.c| 1 + net/filter-rewriter.c | 1 + net/slirp.c | 65 +- slirp/arp_table.c | 13 +- slirp/bootp.c | 4 +- slirp/cksum.c | 5 +- slirp/dhcpv6.c| 19 +- slirp/dnssearch.c | 1 - slirp/if.c| 6 +- slirp/ip6_icmp.c | 34 ++-- slirp/ip6_input.c | 1 - slirp/ip6_output.c| 2 - slirp/ip_icmp.c | 25 ++- slirp/ip_input.c | 201 -- slirp/ip_output.c | 1 - slirp/mbuf.c | 3 +- slirp/misc.c | 188 + slirp/ncsi.c | 5 +- slirp/ndp_table.c | 20 +- slirp/sbuf.c | 8 +- slirp/slirp.c | 458 +++--- slirp/socket.c| 72 +++ slirp/state.c | 394 slirp/tcp_input.c | 86 ++-- slirp/tcp_output.c| 3 +- slirp/tcp_subr.c | 21 +- slirp/tcp_timer.c | 3 +- slirp/tftp.c | 18 +- slirp/udp.c | 13 +- slirp/udp6.c | 8 +- slirp/util.c | 176 stubs/slirp.c | 2 +- Makefile.objs | 1 - slirp/Makefile.objs | 4 +- slirp/meson.build | 48 + slirp/trace-events| 5 - 55 files changed, 1547 insertions(+), 1148 deletions(-)
