A @c_ptr pointer is stored in memory as a real pointer rather than a
SPICE_ADDRESS. This is a temporary thing that will be removed again
when all SPICE_ADDRESSes have been converted to real pointer.
red_parse_qxl.c starts to follow QXLPHYSICAL references and build up
data structures. Can zap a bunch of get_virt calls in red_worker.c,
followed by cleanups.
(de-) marshaller needs updates to deal with that. Also I suspect with
the get_virt() calls being gone we can offload more work to generated
marshaller code.
client doesn't build.
This makes the protocol more compact. This was mainly done for the commonly
used types. Some seldom used ones are still 32bit for future compatibility.
This means the member is not sent on the network at all.
Instead its initialized to the attribute argument when demarshalled.
This is useful for backwards compatibility support.
This is required because we don't want to free messages that just
refer to the unparsed message (like SpiceMsgData).
Also, in the future we might need it for more complex demarshalling.
Right now we always assume pointers are stored as SPICE_ADDRESS,
i.e. 64bit, independent on the size sent on the network.
This is required for 64bit architectures of course, but slightly overkill
on 32bit architectures, so needs fixing when all SPICE_ADDRESS elements
can be made internal.
We move all message structs from spice-protocol to spice as
we want to be able to change these as needed internally. The
on-network format is no longer defined by these structures anyway,
but rather by the spice protocol description.
When a message has been read from the network we now pass it into
the generated demarshaller for the channel. The demarshaller converts
the network data to in-memory structures that is passed on to the
spice internals.
Additionally it also:
* Converts endianness
* Validates sizes of message and any pointers in it
* Localizes offsets (converts them to pointers)
* Checks for zero offsets in messages where they are not supported
Some of this was previously done using custom code in the client, this
is now removed.
The "spice.proto" file describes in detail the networking prototcol
that spice uses and spice_codegen.py can parse this and generate
demarshallers for such network messages.
1) add an option to determine if a bitmap can be sent lossy to the client
2) when required, replacing lossy cache items with their correspending
lossless bitmaps
