On Tue, Jun 09, 2026 at 08:51:15PM +0100, Peter Maydell wrote:
> On Tue, 9 Jun 2026 at 20:45, Stefan Hajnoczi <[email protected]> wrote:
> >
> > On Tue, Jun 9, 2026 at 2:51 PM Peter Maydell <[email protected]>
> > wrote:
> > >
> > > On Tue, 9 Jun 2026 at 19:00, Stefan Hajnoczi <[email protected]> wrote:
> > > > I'm not sure if anyone brought up this topic on qemu-devel and with
> > > > Michael before. As I mentioned in my reply, there are ways to avoid
> > > > blocking vhost-user spec changes when qemu.git is frozen:
> > > >
> > > > The simplest approach is to keep merging vhost-user.rst changes during
> > > > freeze since it does not jeopardize the release or introduce
> > > > instability.
snip
> I tend to view the specs subsection of the docs as being
> for things where either QEMU really is the authoritative
> source (eg fw_cfg), or where the spec is for something that's
> basically moribund and has no better home. If vhost-user is
> a cross-project specification that it so active that it
> cannot live within QEMU's release process, then I think
> it deserves to have its own independent home.
Yes, the main impression I get having read through this whole thread
is that vhost-user spec should have its own home outside QEMU.
We can come up with all sorts of rationalizations for how to make
things work in the context of QEMU, but they all just come across
as excuses to avoid changing the fairly arbitrary historical use
of qemu.git. Even if as QEMU maintainers we consider that we're a
"neutral" home, I can understand why it might not be perceived that
way from the outside.
If people want agility such that we need to make exceptions for
our rules during freeze that is one flag that it doesn't belong
with the main qemu.git, but there are broader points that are
pushing my view in that direction too.
Not mentioned is that engaging with the QEMU mailing list as a
non-regular QEMU contributor is not a very attractive task.
While QEMU may be satisfied with email, QEMU are in a tiny
minority these days. The rest of the OSS community has
decided that git forges are the better way to collaborate.
Our dev list is very high volume, with changes very easily (and
often) lost in the noise, even from regular contributors, such
that we have to teach people to (repeatedly) "ping" to attract
attention.
If we want agility though, IMHO it is best to stay away from the
bureucracy of the OASIS virtio spec / committee, which is a big
turn off IME.
If we're considering a move of the spec, we should probably consider
the best home for some of the related code parts too:
subprojects/libvhost-user/
contrib/vhost-user-blk/
contrib/vhost-user-bridge/
contrib/vhost-user-gpu/
contrib/vhost-user-input/
contrib/vhost-user-scsi/
IIUC, the subprojects is fully standalone code with no dependency
on QEMU. It remained within QEMU for "convenience" allowing us to
consume them from the impls under contrib/. While the contrib code
has some depedencies on QEMU, overall they appear pretty light and
so likely easily detached
$ git grep '#include "' vhost-user-* | awk '{print $2}' | sort | uniq
"hw/virtio/virtio-gpu-bswap.h"
"hw/virtio/virtio-gpu-pixman.h"
"libvhost-user-glib.h"
"libvhost-user.h"
"qapi/error.h"
"qemu/atomic.h"
"qemu/bswap.h"
"qemu/ctype.h"
"qemu/drm.h"
"qemu/iov.h"
"qemu/osdep.h"
"qemu/queue.h"
"qemu/sockets.h"
"standard-headers/linux/input.h"
"standard-headers/linux/virtio_blk.h"
"standard-headers/linux/virtio_gpu.h"
"standard-headers/linux/virtio_input.h"
"standard-headers/linux/virtio_net.h"
"standard-headers/linux/virtio_scsi.h"
"virgl.h"
"vugbm.h"
"vugpu.h"
We have a often repeated desire to eliminate the "contrib" tree
as a concept, since it is currently effectively a "dumping ground"
for things which are either unmaintained or didn't have a better
home yet. This might be a chance to provide a better home for a
big part of it.
IMHO this suggests it is worth creating a new top level gitlab project
for it all to live in and form a dedicated team around it, rather than
trying to pick any existing location.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
