<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> On 2010-03-23 17:58, Alexander Larsson wrote: <blockquote cite="mid:1269359898.10861.45.camel@fatty" type="cite"> <pre wrap="">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. </pre> </blockquote> 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. <blockquote cite="mid:1269359898.10861.45.camel@fatty" type="cite"> <pre wrap=""> </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ Spice-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> </pre> </blockquote> </body> </html>