investigate how we can start using libslirp about slirp4netns HOT 9 CLOSED

Do you want to get this in v0.3.0 or can we defer it until QEMU upstream migrates to libslirp? (unlikely to happen until QEMU 4.1 https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07003.html )

from slirp4netns.

this can happen after v0.3.0

from slirp4netns.

I was just about to post an issue about this. If we can use stock libslirp, from a packaging and "what is this software doing" perspective things will look much nicer. However we will need to push our patches upstream first.

I also want to look into getting LXC to be able to use slirp4netns as an alternative to their current set-uid approach (but I don't want to add a dependency to LXC which uses a forked libslirp that is statically built).

But yes, for packaging it would be easier if we wait until libslirp is actually used by qemu -- because then we can piggy-back off the official libslirp packages existing in distributions (rather than having to package it ourselves before they need it).

from slirp4netns.

I prefer to link libslirp statically for the time being so that we can experiment more optimizations (#16 #17) without dependency hell

from slirp4netns.

@AkihiroSuda couldn't #16 & #17 be opened in upstream libslirp instead?

Do you think we should hold back a libslirp release or is it good enough for slirp4netns in its current form?

from slirp4netns.

Yes, though I don't have bandwidth to look into #16 #17 deeper currently.

+1 on having releases ( https://gitlab.freedesktop.org/slirp/libslirp/issues/6 ) but not blocker for us.

from slirp4netns.

@giuseppe do you want to open PR for libslirp migration?

from slirp4netns.

opened #94 for vendoring freedesktop libslirp

from slirp4netns.

Merge request for moving slirp4netns patches to libslirp: https://gitlab.freedesktop.org/slirp/libslirp/merge_requests/8

@elmarco @giuseppe

from slirp4netns.