On Wed, 12/03 19:37, Bryan D. Payne wrote:
> >
> > Out of curiosity, what are existing solutions?
> >
>
> Basically just attaching gdb and pulling memory out manually (or writing a
> program to do the same).
>
>
> > +struct request {
> > > + uint8_t type; /* 0 quit, 1 read, 2 write, ... rest reserved */
> > > + uint64_t address; /* address to read from OR write to */
> > > + uint64_t length; /* number of bytes to read OR write */
> > > +};
> >
> > Please add QEMU_PACKED to this structure, and probably name it
> > QEMUMARequest,
> > for name collision avoidance and CamelCase convension.
> >
>
> How critical is QEMU_PACKED? This changes the layout of the struct which
> means that existing clients (LibVMI) would need to change their code as
> well.
It is critical as a transport data structure. You have to define a byte-by-byte
layout (concerning endianness and padding) and use padding fields together with
QEMU_PACKED, so the representation is not dependent on alignment:
http://en.wikipedia.org/wiki/Data_structure_alignment
For example:
typedef struct {
union {
uint8_t type;
uint64_t padding;
};
uint64_t address;
uint64_t length;
} QEMU_PACKED QEMUMARequest;
It also means that client need to use the same endianness with us, but there is
no way to query it.
An alternative might be carry endianness information in the protocol
negotiation or in request.
Fam
