[Spice-devel] Adding a proper marshaller/demarshaller to spice

[Yaniv Kaul]

On 2010-03-23 17:58, Alexander Larsson wrote:
> I've been doing some research on adding a proper validating demarshaller
> to spice. What i mean by this is a piece of code that parses the bytes
> recieved from the network, validates that it is a proper spice message
> and then generates an internal structure describing the request.
>
> Right now we more or less read packed structures from the network and
> push validation out into any place that uses it. This has multiple
> issues. For instance the structs are not aligneds properly for
> performance, the validation is hard to review, its hard to extend
> messages (add to the structs) while being backwards compatible.
>
> I have constructed a simple language to describe the current spice
> protocol. Its attached to this mail, please report any strangeness you
> find. I have also written a parser in python for this language, and I
> plan to write a code generator based on this that can generate
> validating (de)marshaller code which we will use in spice.
>
> The plan to get this into spice is then this:
> 1. Make the code use the generated (de)marshallers to marshal the
>     network data from/into the current spice structures.
> 2. Split all current structures used in both the Qxl pci commands
>     and for network marshalling into two copies, one QxlFoo used
>     for qxl and one SpiceFoo used internally.
> 3. Now no external entity depends on the spice structs, so we
>     can change them as we please into regular non-packed structs
>     with pointers instead of offsets, etc.
> 4. Make a copy of the spice protocol and use it for a new
>     (de)marshaller with major number == 2, picking implementation
>     in the client based on the server major number.
> 5. Start modifying the protocol description for the new major.
>
>
> I have a bunch of protocol changes I want to do in the new major. For
> instance, on the network all "offsets" in the current protocol can be
> removed and instead we can put the relevant data inline. We can also
> make parts of messages totally optional if not used (like clip region)
> such that we send no data if they are not used. I also want to simplify
> some the stroke operation and remove the clip-by-path mode.
>
> Additionally there are some changes i want to do to the internal
> structures. For instance, SpicePoint members should be reordered to be
> compatible with pixman points, and Clip regions should always be stored
> as pointers to pixman regions.
>    

There's also redundant data *between* different structures of a message.
For example, in DRAW_COPY:
1. In RedDrawBase, we have a RECT that defines the size.
It's mentioned again, in the ImageDescriptor that follows.
And again, in the QUIC image header that follows.
2. In the QUIC image header, the magic 'QUIC' is not needed - we already 
know it's QUIC from the ImageDescriptor's image type field (4 bytes)
In the QUIC image header, we don't really need the major nor the minor 
version - we could have used a new ImageDescriptor type ('QUIC2.0') for 
it (4 bytes)

Y.

>    
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20100323/43ae4a7f/attachment.html>