Re: [Qemu-devel] [PATCH v7 1.2] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC

[Alon Levy <alevy@redhat.com>]

----- Original Message -----
> Hi,
> 
> >> Maybe revisit upstream spice packaging?  spice internal usage of
> >> spice-protocol is handled via submodules now.  Are there external
> >> users, other than qemu?  Does it make sense to keep the
> >> spice-server / spice-protocol split in the first place?  Or should
> >> spice-server just provide the protocol headers too?
> > 
> > spice-server is a much larger project then spice-protocol. The
> > agents
> > and the drivers don't need any bits in spice-server.
> 
> I didn't meant to kill the spice-protocol git repo, just the way it
> is
> distributed.
> 
> Remove any makefiles & stuff from spice-protocol, so it is really
> just
> the headers.  Any spice-internal users get it as submodule like they
> do
> today.  spice-server gets updated to also install the spice-protocol
> header files from the submodule.
> 
> Kills the whole protocol header version dance for the external users
> (the submodule usage already does it for the internal ones).  When
> you've installed spice-server-devel you automatically also have
> recent
> enougth spice protocol headers installed.
> 

Yes, we could do it, I'm not sure it's worth the trouble. The only benefit is that it removes one more pkg-config check. But it means that anyone who wants to develop a new client has to install spice-server to get the client headers.

Right now the protocol has other problems - it doesn't contain the complete protocol specification, spice.proto, that is actually in spice-common. And it's wrongly named - it contains the agent protocol and the device "protocol" as well.

> > Sure, we can
> > unify them - it would make it easier for qemu and Xspice (the only
> > other external user).
> 
> So both external users need the spice server too.  So I think it
> makes
> sense to have spice-server ship the protocol headers.
> 
> cheers,
>   Gerd
> 
> 
>