Re: [Qemu-devel] [PATCH for-3.2 00/41] RFC: slirp: make it again a standalone project

[Daniel P . Berrangé]

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