Hi, I'm designing virtio-video protocol [1] and thinking about its structs' layouts. The virtio-video protocol adopts the request-response model like virtio-gpu and virtio-fs. While I looked at these two protocols, I found they used different designs of having request headers. So, I’m wondering what’s the best way of having the request / response header for virtio-video.
On the one hand, virtio-gpu's structs for each control and response contain the virtio_gpu_ctrl_hdr as one of fields: struct virtio_gpu_get_edid { struct virtio_gpu_ctrl_hdr hdr; ... }; struct virtio_gpu_resp_edid { struct virtio_gpu_ctrl_hdr hdr; ... }; On the other hand, virtio-fs separates its header struct and request body like the FUSE protocol: struct fuse_in_header in; union { struct fuse_read_in readin; ... }; When we define a new protocol, which layout is preferred? I'd especially like to know why virtio-gpu decided to use this design and if the design is nice. In the latest proposal of the virtio-video [1], we chose the same design as virtio-gpu like: struct virtio_video_resource_queue { struct virtio_video_cmd_hdr hdr; ... }; struct virtio_video_resource_queue_resp { struct virtio_video_cmd_hdr hdr; ... }; However, I thought it's a bit inconvenient that we cannot know the actual size of a struct before its header. Actually, our device implementation reads the header first to know the size and then reads the whole struct including the header. If it doesn’t make any sense to follow the virtio-gpu’s header design, I’d like to separate the header and the command bodies and make the driver send two structs per command: struct virtio_video_cmd_hdr hdr; // contains what command follows struct virtio_video_resource_queue { ... }; struct virtio_video_resource_queue_resp { ... }; Any types of comments are welcome! Thanks. [1] https://markmail.org/message/dmw3pr4fuajvarth Best regards, Keiichi --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org