Re: [Qemu-devel] qemu-system split

[Michael Tokarev]

21.01.2013 23:43, Daniel P. Berrange wrote:
> On Mon, Jan 21, 2013 at 10:58:48PM +0400, Michael Tokarev wrote:
> > We in debian talked about splitting qemu-system into
> > individual target packages for a long time, and there's
> > a patch (almost current) to support it, in qemu-system-split-mjt
> > branch of qemu debian git tree (I'll refresh it hopefully
> > today).
> >
> > I think it's time to decide whenever we want to do that
> > or not.
> >
> > The idea is to provide qemu-system-x86, qemu-system-arm,
> > etc, together with qemu-system-common (with common files
> > if any), and qemu-system-misc for "miscellaneous" arches
> > for which there was no separate package introduced.
> >
> > It was a long way there, and I'm still not certain if
> > we really want to do that or not, but the current
> > qemu-system is huge and has many non-trivial dependencies
> > (various firmwares).
>
> FWIW, we had the same thoughts in Fedora a few years back. In
> the end, we stopped short of creating one package per system
> target. Instead we went for one package per "architecture family"
> where a family includes both the 32-bit & 64-bit variants. eg
> qemu-system-x86 contains i686 & x86_64 emulators. This level of
> granularity helped keep the number of packages reasonably sane.
> We left all the userspace emulators in one package on the grounds
> that their userbase is tiny and probably don't care.

This is exactly what we did in debian (in the separate branch).  Current
list of packages:

sysarch_arm   = $(filter arm,${system_targets})
sysarch_mips  = $(filter mips mipsel mips64 mips64el,${system_targets})
sysarch_ppc   = $(filter ppc ppc64 ppcemb,${system_targets})
sysarch_sparc = $(filter sparc sparc64,${system_targets})
sysarch_x86   = $(filter i386 x86_64,${system_targets})
sysarch_misc  = $(filter-out $(foreach 
s,${sys_systems},${sysarch_$s}),${system_targets})

> We had a qemu-common for some shared pieces, and qemu-img so
> that tools can get hold of the qemu-img binary without pulling
> in any of the virtualization pieces.

That's also the case, except of s/qemu-common/qemu-system-common/,
and we have qemu-img in qemu-utils (qemu-img, qemu-nbd, qemu-virtfs-helper, --
this latter one should probably move to qemu-system-common).

> You can see what we ended up with here:
>
>    http://kojipkgs.fedoraproject.org/packages/qemu/1.3.0/4.fc19/x86_64/
>    http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec

Yeah, something very similar ;)

> > Second, it isn't clear how -dbg packages should be handled.
> > It is sometimes useful to have them, -- should we have one
> > huge pkg with all debug info which breaks all qemu-system-*
> > of "wrong" version, or should we have one dbg per target?
> > And again, the size (or count of packages) is large.
>
> IMHO one debug package is sufficient - it is reasonable to
> assume that if multiple qemu-system-* packages are installed,
> they would all be the same version.

That's exactly the issue, I think: when debugging something,
it is sometimes necessary to go back or forth one or another
version, but at the same time keeping other stuff working.
For example, debugging qemu-system-arm while keeping
qemu-system-x86_64 working.

> > At least, when refreshing the branch (note it is volatile,
> > ie, I rebase it on top of debian-experimental currently),
> > I'll add Provides: qemu-system-$arch for all qemu-system-target,
> > so that it will be possible for other packages to depend on
> > particular arch they're interested, not whole qemu-system.
> > And add this to current 1.3 branch as well.
>
> We also added a virtual 'qemu-kvm' package which depends on the
> particular qemu-system-* package which has KVM support enabled
> for that host arch. This lets apps depend on 'qemu-kvm' without
> having to do different deps depending on the architectures they
> are built on.

Again, the same thing :)

We've qemu-kvm only for x86 (32 or 64bits), not for ppc and a few
other targets where it exists, but this actually is a good thing
you reminded me about - "kvm" binary may be used with more targets
and hosts.  Hmm.

> I think it'd be a good move to split up the large qemu-system package
> into something smaller. It is very rare to have someone who genuinely
> wants to have all the emulators installed at once. In the server / desktop
> virt world, probably the vast majority of people only care about having
> the particular qemu-system-* emulators which contain KVM support.

Yeah.

Note that, as far as I understand, upstream is moving towards a single
binary which can emulate any target (sort of like busybox).  But even
if this is the case, we're FAR from there, and it will be trivial to
merge them back together.  It is more difficult to split them up but
keep stuff installed properly (transition from single qemu-system to
or qemu-system-misc to a several qemu-system-$foo).

Thank you for sharing!

/mjt