Re: [Qemu-devel] [PATCH v3 2/2] docs: update ivshmem device spec

[David Marchand <david.marchand@6wind.com>]

Hello Stefan,

On 08/08/2014 05:02 PM, Stefan Hajnoczi wrote:
> On Fri, Aug 08, 2014 at 10:55:18AM +0200, David Marchand wrote:
>> +For each client (QEMU processes) that connects to the server:
>> +- the server assigns an ID for this client and sends this ID to him as the first
>> +  message,
>> +- the server sends a fd to the shared memory object to this client,
>> +- the server creates a new set of host eventfds associated to the new client and
>> +  sends this set to all already connected clients,
>> +- finally, the server sends all the eventfds sets for all clients to the new
>> +  client.
>
> The protocol is not extensible and no version number is exchanged.  For
> the most part this should be okay because clients must run on the same
> machine as the server.  It is assumed clients and server are compatible
> with each other.
>
> I wonder if we'll get into trouble later if the protocol needs to be
> extended or some operation needs to happen, like upgrading QEMU or the
> ivshmem-server.  At the very least someone building from source but
> using system QEMU or ivshmem-server could get confusing failures if the
> protocol doesn't match.
>
> How about sending a version message as the first thing during a
> connection?

I am not too sure about this.

This would break current base version.

Using a version message supposes we want to keep ivshmem-server and QEMU 
separated (for example, in two distribution packages) while we can avoid 
this, so why would we do so ?

If we want the ivshmem-server to come with QEMU, then both are supposed 
to be aligned on your system.
If you want to test local modifications, then it means you know what you 
are doing and you will call the right ivshmem-server binary with the 
right QEMU binary.


Thanks.


-- 
David Marchand