Thu, Mar 02, 2023 at 02:05:22PM CET, [email protected] wrote: >Add commands to find out which commands does each group support, >as well as enable their use by driver. >This will be especially useful once we have multiple group types. > >An alternative is per-type VQs. This is possible but will >require more per-transport work. Discovery through the vq >helps keep things contained. > >Signed-off-by: Max Gurtovoy <[email protected]> >Signed-off-by: Michael S. Tsirkin <[email protected]>
[...] >+ >+The driver issues the command VIRTIO_ADMIN_CMD_LIST_QUERY to >+query the list of commands valid for this group and before sending >+any commands for any member of a group. >+ >+The driver then enables use of some of the opcodes by sending to >+the device the command VIRTIO_ADMIN_CMD_LIST_USE with a subset >+of the list returned by VIRTIO_ADMIN_CMD_LIST_QUERY that is >+both understood and used by the driver. To my untrained ear, this sounds somewhat similar to the feature negotiantion mechanism. Why the fact that device/driver supports some command can't be covered by just another feature? Looks like unnecassary complexicity to negotiate supported commands like this. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
