Endianness and layout of driver/device exchange structures

[Gnurou]

Right now there is no decided endianness or architecture decided for the representation of the V4L2 structures used on virtqueues.

Architecture is rather obvious, 64-bit V4L2 headers should be used.

Endianness is less obvious. Converting endianness in structures requires quite some boilerplate. Maybe we can have the guest decide which endianness to use?

In any case, it looks like we might need to define our own set of V4L2 structures with the desired layout, both in C and Rust.

[Gnurou]

On the device side, we should be able to partially address the issue if we build v4l2r in 64-bit mode (i.e. ask it to generate 64-bit headers). We can then maybe use some macros (or better, and existing crate) to handle endianness.

[Gnurou]

Addressing this will also require the proxy V4L2 device to use different versions of the V4L2 structures for doing its own ioctls. We might want to turn it into its own crate and make it depend on a different build of v4l2r.

Since the virtio-media v4l2r bindings will be compiled with the 64-bit layout, it's probably a good idea to rename or alias them using the vmedia_ prefix instead of v4l2_.