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 :|