Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] virtio: premature UAPI addition and undocumented ID gap --
commit 6c8027f028fb5e1fbc1a781cb6e95ed1a88e28f2 Author: Honglei Huang <[email protected]> drm/virtio-gpu: Add VIRTIO_GPU_CAPSET_ROCM capability This commit adds a new GPU capability set VIRTIO_GPU_CAPSET_ROCM to support ROCm compute workloads. It assigns ID 8 because ID 7 is used by VIRCL, and mentions a virtio-gpu specification change is in progress. > diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h > index 4f530d90058c7..3d4dfadc9d789 100644 > --- a/include/uapi/linux/virtio_gpu.h > +++ b/include/uapi/linux/virtio_gpu.h > @@ -321,6 +321,7 @@ struct virtio_gpu_cmd_submit { > #define VIRTIO_GPU_CAPSET_VENUS 4 > #define VIRTIO_GPU_CAPSET_CROSS_DOMAIN 5 > #define VIRTIO_GPU_CAPSET_DRM 6 > +#define VIRTIO_GPU_CAPSET_ROCM 8 [Severity: Medium] Is it safe to introduce VIRTIO_GPU_CAPSET_ROCM (ID 8) to the immutable Linux UAPI while the corresponding virtio specification is still in progress? If the OASIS virtio technical committee rejects the proposal, requests changes, or assigns a different ID during the review process, the Linux UAPI will be permanently divergent or broken. Additionally, should a placeholder macro or documentation be added for the skipped ID 7? Without it in the header, future developers might assume ID 7 is available and mistakenly reallocate it, creating a potential UAPI compatibility issue. > > /* VIRTIO_GPU_CMD_GET_CAPSET_INFO */ > struct virtio_gpu_get_capset_info { -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
