On Thu, Jun 09, 2016 at 05:21:26PM +0200, Gerard Garcia wrote:
> > > diff --git a/include/uapi/linux/vsockmon.h b/include/uapi/linux/vsockmon.h
> > > new file mode 100644
> > > index 0000000..c73166f
> > > --- /dev/null
> > > +++ b/include/uapi/linux/vsockmon.h
> > > @@ -0,0 +1,37 @@
> > > +#ifndef _UAPI_VSOCKMON_H
> > > +#define _UAPI_VSOCKMON_H
> > > +
> > > +#include <linux/virtio_vsock.h>
> > > +
> > > +/* Packet structure of packets received from the vsockmon device. */
> > > +
> > > +struct af_vsockmon_g {
> > > + unsigned short op; /* enum af_vsock_g_ops */
> > > + unsigned int src_cid;
> > > + unsigned int src_port;
> > > + unsigned int dst_cid;
> > > + unsigned int dst_port;
> > > +};
> > > +
> > > +struct af_vsockmon_hdr {
> > > + unsigned short type; /* enum af_vosck_type */
> > > + struct af_vsockmon_g g_hdr;
> > > + union {
> > > + struct virtio_vsock_hdr virtio_hdr;
> > > + } t_hdr;
> > > +};
> > How does endianness work? virtio_hdr uses little-endian fields on the
> > wire. I guess that af_vsockmon_g is always CPU-endian.
> Yes, af_vsockmon_g is CPU-endian. I don't know what criteria is normally
> used regarding the endianness of structs facing user space but I think it is
> better to not modify the vsock transport structs.Endianness must to be documented in this uapi header file.
signature.asc
Description: PGP signature
