* [Qemu-devel] libslirp and QEMU slirp @ 2017-02-06 11:55 Stefan Hajnoczi 2017-02-08 22:10 ` Samuel Thibault 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2017-02-06 11:55 UTC (permalink / raw) To: Samuel Thibault, renzo; +Cc: virtualsquare, Jan Kiszka, qemu-devel Hi, There was a talk about new developments in VDEplug at FOSDEM 2017. The QEMU slirp code has been extracted into a library: https://fosdem.org/2017/schedule/event/iaas_modvde/ QEMU's slirp code does not have many contributors. Other projects using slirp are probably in this situation too. Spinning the QEMU slirp code out into an external library seems like a good idea because it could help focus on new developments like IPv6 support and ease the maintenance burden. I'm proposing this topic for discussion because there might be common ground for Samuel from QEMU and the VDE folks to collaborate. Samuel: Should QEMU join forces with libslirp? If you would like to speak rather than email, QEMU has a developer conference call on Tuesday 14th of February at 13:00-14:00 UTC. The agenda is open for topics and it would be a good forum to share ideas on slirp code maintenance and future direction. All that's required is an email to Juan Quintela <quintela@redhat.com> and he can schedule the call and provide dial-in details. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] libslirp and QEMU slirp 2017-02-06 11:55 [Qemu-devel] libslirp and QEMU slirp Stefan Hajnoczi @ 2017-02-08 22:10 ` Samuel Thibault 2017-02-12 7:30 ` Renzo Davoli 0 siblings, 1 reply; 6+ messages in thread From: Samuel Thibault @ 2017-02-08 22:10 UTC (permalink / raw) To: Stefan Hajnoczi Cc: renzo, virtualsquare, thuth, jasowang, Jan Kiszka, peter.maydell, qemu-devel Hello, Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +0000, wrote: > I'm proposing this topic for discussion because there might be common > ground for Samuel from QEMU and the VDE folks to collaborate. > > Samuel: Should QEMU join forces with libslirp? Well, there are not that many forces from the QEMU side :) Personally, I'm fine with seeing slirp move to a separate playground that qemu would depend on and others could contribute to. It just needs to be integrated to distros so that qemu can get it. That being said, the integration of slirp and qemu is not so loose, notably on the top of my head: - we are using timers for icmp announcements - qemu needs to be able to save/restore state, with compatibility with previous versions We'd need to see how that can be expressed as a library. Samuel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] libslirp and QEMU slirp 2017-02-08 22:10 ` Samuel Thibault @ 2017-02-12 7:30 ` Renzo Davoli 2017-02-13 10:56 ` Thomas Huth 2017-02-15 14:33 ` Stefan Hajnoczi 0 siblings, 2 replies; 6+ messages in thread From: Renzo Davoli @ 2017-02-12 7:30 UTC (permalink / raw) To: Samuel Thibault Cc: Stefan Hajnoczi, virtualsquare, thuth, jasowang, Jan Kiszka, peter.maydell, qemu-devel Hi, On Wed, Feb 08, 2017 at 11:10:50PM +0100, Samuel Thibault wrote: > Hello, > > Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +0000, wrote: > > I'm proposing this topic for discussion because there might be common > > ground for Samuel from QEMU and the VDE folks to collaborate. > > > > Samuel: Should QEMU join forces with libslirp? > > Well, there are not that many forces from the QEMU side :) Neither on VDE side ;-) but many ants can move mountains... > > - we are using timers for icmp announcements > - qemu needs to be able to save/restore state, with compatibility with > previous versions libslirp is using qemu's slirp code. If you try a diff between your "slirp" directory and libslirp's "src" directory you'll find that there are only 3 lines added: (at the date of the code extraction, e.g. qemu git's tag 1f8b56e7cebc71d80aec27a4760024b56acc957a) In slirp.h: #include <qemu2libslirp.h> Which includes stubs and specific implementations to give slirp all the stuff provided by qemu's core or other libraries used by qemu. In tcp_subr.c: 400a401,403 > if ((ret = unixtcp_fconnect(so, af)) >= 0) > return ret; which adds a nice feature that IMHO would be useful in qemu, too. unixtcp_fconnect creates a TCP to AF_UNIX socket redirection. The VM running on qemu (or in VDE a VM connected to the virtual net) can redirect a default route port (say 10.0.2.2:6000) to a UNIX socket (say /tmp/.X11-unix/0). In this example X clients using the X display 10.0.2.2:0 can appear on the X server of the host. Timers have been reimplemented using the qemu's API. save/restore are dummy stubs in libslirp. Qemu's code is still there but it is not used by libslirp. In this way we can inherit all bugfixes and new feature from Qemu at almost no cost. It would be a nice project to create a common codebase for libslirp. The project sould be interesting for other VM projects (virtualbox-OSE?) and maybe many others. We could collect several ants... Libslirp/QEMU integration is not so difficult. As a first step: * Qemu could add the UNIX socket redirect feature, or at least a unixtcp_fconnect dummy function returning -1 (#ifndef LIBSLIRP) * #include <qemu2libslirp.h> could be added in slirp.h (inside an #ifdef LIBSLIRP). In this way we could share exactly the same codebase. One further step: * discuss how to reduce/eliminate qemu-specific dependence * create an API for save/restore These are only my two (euro)cents. ciao renzo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] libslirp and QEMU slirp 2017-02-12 7:30 ` Renzo Davoli @ 2017-02-13 10:56 ` Thomas Huth 2017-02-13 11:21 ` Renzo Davoli 2017-02-15 14:33 ` Stefan Hajnoczi 1 sibling, 1 reply; 6+ messages in thread From: Thomas Huth @ 2017-02-13 10:56 UTC (permalink / raw) To: Renzo Davoli, Samuel Thibault Cc: Stefan Hajnoczi, virtualsquare, jasowang, Jan Kiszka, peter.maydell, qemu-devel On 12.02.2017 08:30, Renzo Davoli wrote: > Hi, > > On Wed, Feb 08, 2017 at 11:10:50PM +0100, Samuel Thibault wrote: >> Hello, >> >> Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +0000, wrote: >>> I'm proposing this topic for discussion because there might be common >>> ground for Samuel from QEMU and the VDE folks to collaborate. >>> >>> Samuel: Should QEMU join forces with libslirp? >> >> Well, there are not that many forces from the QEMU side :) > Neither on VDE side ;-) but many ants can move mountains... >> >> - we are using timers for icmp announcements >> - qemu needs to be able to save/restore state, with compatibility with >> previous versions > > libslirp is using qemu's slirp code. [...] > Timers have been reimplemented using the qemu's API. > save/restore are dummy stubs in libslirp. Qemu's code is still there but it is not used > by libslirp. Well, sure, but if this libslirp is going to evolve into a QEMU-independent library, such timer and save/restore hacks likely should go away from the library and implemented on the side of the consuming application instead. > It would be a nice project to create a common codebase for libslirp. > The project sould be interesting for other VM projects (virtualbox-OSE?) and > maybe many others. We could collect several ants... FWIW, I know that WinUAE is using QEMU's slirp code, too. I've got a question: Is there already a project page and public repository for libslirp available somewhere? I did not find anything useful with Google yet... Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] libslirp and QEMU slirp 2017-02-13 10:56 ` Thomas Huth @ 2017-02-13 11:21 ` Renzo Davoli 0 siblings, 0 replies; 6+ messages in thread From: Renzo Davoli @ 2017-02-13 11:21 UTC (permalink / raw) To: Thomas Huth Cc: Samuel Thibault, Stefan Hajnoczi, virtualsquare, jasowang, Jan Kiszka, peter.maydell, qemu-devel Hi Thomas, > FWIW, I know that WinUAE is using QEMU's slirp code, too. thank you! I'll have a look of it. > > I've got a question: Is there already a project page and public > repository for libslirp available somewhere? I did not find anything > useful with Google yet... Sure: https://github.com/rd235/libslirp ciao renzo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] libslirp and QEMU slirp 2017-02-12 7:30 ` Renzo Davoli 2017-02-13 10:56 ` Thomas Huth @ 2017-02-15 14:33 ` Stefan Hajnoczi 1 sibling, 0 replies; 6+ messages in thread From: Stefan Hajnoczi @ 2017-02-15 14:33 UTC (permalink / raw) To: Renzo Davoli Cc: Samuel Thibault, virtualsquare, thuth, jasowang, Jan Kiszka, peter.maydell, qemu-devel [-- Attachment #1: Type: text/plain, Size: 1161 bytes --] On Sun, Feb 12, 2017 at 08:30:19AM +0100, Renzo Davoli wrote: > It would be a nice project to create a common codebase for libslirp. > The project sould be interesting for other VM projects (virtualbox-OSE?) and > maybe many others. We could collect several ants... > > Libslirp/QEMU integration is not so difficult. > As a first step: > * Qemu could add the UNIX socket redirect feature, or at least a unixtcp_fconnect dummy function > returning -1 (#ifndef LIBSLIRP) > * #include <qemu2libslirp.h> > could be added in slirp.h (inside an #ifdef LIBSLIRP). > In this way we could share exactly the same codebase. > > One further step: > * discuss how to reduce/eliminate qemu-specific dependence > * create an API for save/restore Eliminating QEMU dependencies is feasible, I think. libslirp could have no "qemu" strings in the code :). Applications like QEMU need to query libslirp for timers and fds so they can be integrated into event loops (select(2)). Once there is a working libslirp that arbitrary programs can link against it can be packaged (rpm, deb, etc) and announced. That might attract new contributors. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-15 14:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-06 11:55 [Qemu-devel] libslirp and QEMU slirp Stefan Hajnoczi 2017-02-08 22:10 ` Samuel Thibault 2017-02-12 7:30 ` Renzo Davoli 2017-02-13 10:56 ` Thomas Huth 2017-02-13 11:21 ` Renzo Davoli 2017-02-15 14:33 ` Stefan Hajnoczi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).