Re: [RFC 2/3] vsockmon: Add vsockmon device

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]