| Message ID | 20230130104548.13262-2-maxime.coquelin@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Vhost-user: replace _SLAVE_ with _BACKEND_ | expand |
On Mon, Jan 30, 2023 at 11:45:46AM +0100, Maxime Coquelin wrote: > Backend's message and protocol features names were still > using "_SLAVE_" naming. For consistency with the new naming > convention and to get rid of the remaining harmful > language, replace it with _BACKEND_. > > Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> let's drop "to get rid of the remaining harmful language" as don't get rid of it. consistency is sufficient motivation. > --- > docs/interop/vhost-user.rst | 40 ++++++++++++++++++------------------- > 1 file changed, 20 insertions(+), 20 deletions(-) > > diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst > index 3f18ab424e..8a5924ea75 100644 > --- a/docs/interop/vhost-user.rst > +++ b/docs/interop/vhost-user.rst > @@ -315,7 +315,7 @@ in the ancillary data: > * ``VHOST_USER_SET_VRING_KICK`` > * ``VHOST_USER_SET_VRING_CALL`` > * ``VHOST_USER_SET_VRING_ERR`` > -* ``VHOST_USER_SET_SLAVE_REQ_FD`` > +* ``VHOST_USER_SET_BACKEND_REQ_FD`` (previous name ``VHOST_USER_SET_SLAVE_REQ_FD``) > * ``VHOST_USER_SET_INFLIGHT_FD`` (if ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD``) > > If *front-end* is unable to send the full message or receives a wrong > @@ -516,7 +516,7 @@ expected to reply with a zero payload, non-zero otherwise. > > The back-end relies on the back-end communication channel (see :ref:`Back-end > communication <backend_communication>` section below) to send IOTLB miss > -and access failure events, by sending ``VHOST_USER_SLAVE_IOTLB_MSG`` > +and access failure events, by sending ``VHOST_USER_BACKEND_IOTLB_MSG`` > requests to the front-end with a ``struct vhost_iotlb_msg`` as > payload. For miss events, the iotlb payload has to be filled with the > miss message type (1), the I/O virtual address and the permissions > @@ -540,15 +540,15 @@ Back-end communication > ---------------------- > > An optional communication channel is provided if the back-end declares > -``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` protocol feature, to allow the > +``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` protocol feature, to allow the > back-end to make requests to the front-end. > > -The fd is provided via ``VHOST_USER_SET_SLAVE_REQ_FD`` ancillary data. > +The fd is provided via ``VHOST_USER_SET_BACKEND_REQ_FD`` ancillary data. > > -A back-end may then send ``VHOST_USER_SLAVE_*`` messages to the front-end > +A back-end may then send ``VHOST_USER_BACKEND_*`` messages to the front-end > using this fd communication channel. > > -If ``VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD`` protocol feature is > +If ``VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD`` protocol feature is > negotiated, back-end can send file descriptors (at most 8 descriptors in > each message) to front-end via ancillary data using this fd communication > channel. > @@ -835,7 +835,7 @@ Note that due to the fact that too many messages on the sockets can > cause the sending application(s) to block, it is not advised to use > this feature unless absolutely necessary. It is also considered an > error to negotiate this feature without also negotiating > -``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK``, > +``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK``, > the former is necessary for getting a message channel from the back-end > to the front-end, while the latter needs to be used with the in-band > notification messages to block until they are processed, both to avoid > @@ -855,12 +855,12 @@ Protocol features > #define VHOST_USER_PROTOCOL_F_RARP 2 > #define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 > #define VHOST_USER_PROTOCOL_F_MTU 4 > - #define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5 > + #define VHOST_USER_PROTOCOL_F_BACKEND_REQ 5 > #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN 6 > #define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7 > #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8 > #define VHOST_USER_PROTOCOL_F_CONFIG 9 > - #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10 > + #define VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD 10 > #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11 > #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 > #define VHOST_USER_PROTOCOL_F_RESET_DEVICE 13 > @@ -1059,8 +1059,8 @@ Front-end message types > in the ancillary data. This signals that polling will be used > instead of waiting for the call. Note that if the protocol features > ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and > - ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message > - isn't necessary as the ``VHOST_USER_SLAVE_VRING_CALL`` message can be > + ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message > + isn't necessary as the ``VHOST_USER_BACKEND_VRING_CALL`` message can be > used, it may however still be used to set an event file descriptor > or to enable polling. > > @@ -1077,8 +1077,8 @@ Front-end message types > invalid FD flag. This flag is set when there is no file descriptor > in the ancillary data. Note that if the protocol features > ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and > - ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message > - isn't necessary as the ``VHOST_USER_SLAVE_VRING_ERR`` message can be > + ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message > + isn't necessary as the ``VHOST_USER_BACKEND_VRING_ERR`` message can be > used, it may however still be used to set an event file descriptor > (which will be preferred over the message). > > @@ -1139,7 +1139,7 @@ Front-end message types > respond with zero in case the specified MTU is valid, or non-zero > otherwise. > > -``VHOST_USER_SET_SLAVE_REQ_FD`` > +``VHOST_USER_SET_BACKEND_REQ_FD`` (previous name ``VHOST_USER_SET_SLAVE_REQ_FD``) > :id: 21 > :equivalent ioctl: N/A > :request payload: N/A > @@ -1150,7 +1150,7 @@ Front-end message types > > This request should be sent only when > ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, and protocol > - feature bit ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` bit is present in > + feature bit ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` bit is present in > ``VHOST_USER_GET_PROTOCOL_FEATURES``. If > ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the back-end must > respond with zero for success, non-zero otherwise. > @@ -1429,7 +1429,7 @@ Back-end message types > For this type of message, the request is sent by the back-end and the reply > is sent by the front-end. > > -``VHOST_USER_SLAVE_IOTLB_MSG`` > +``VHOST_USER_BACKEND_IOTLB_MSG`` (previous name ``VHOST_USER_SLAVE_IOTLB_MSG``) > :id: 1 > :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type) > :request payload: ``struct vhost_iotlb_msg`` > @@ -1444,7 +1444,7 @@ is sent by the front-end. > ``VIRTIO_F_IOMMU_PLATFORM`` feature has been successfully > negotiated. > > -``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG`` > +``VHOST_USER_BACKEND_CONFIG_CHANGE_MSG`` (previous name ``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG``) > :id: 2 > :equivalent ioctl: N/A > :request payload: N/A > @@ -1459,7 +1459,7 @@ is sent by the front-end. > ``VHOST_USER_NEED_REPLY`` flag, the front-end must respond with zero when > operation is successfully completed, or non-zero otherwise. > > -``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG`` > +``VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG`` (previous name ``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG``) > :id: 3 > :equivalent ioctl: N/A > :request payload: vring area description > @@ -1482,7 +1482,7 @@ is sent by the front-end. > ``VHOST_USER_PROTOCOL_F_HOST_NOTIFIER`` protocol feature has been > successfully negotiated. > > -``VHOST_USER_SLAVE_VRING_CALL`` > +``VHOST_USER_BACKEND_VRING_CALL`` (previous name ``VHOST_USER_SLAVE_VRING_CALL``) > :id: 4 > :equivalent ioctl: N/A > :request payload: vring state description > @@ -1496,7 +1496,7 @@ is sent by the front-end. > > The state.num field is currently reserved and must be set to 0. > > -``VHOST_USER_SLAVE_VRING_ERR`` > +``VHOST_USER_BACKEND_VRING_ERR`` (previous name ``VHOST_USER_SLAVE_VRING_ERR``) > :id: 5 > :equivalent ioctl: N/A > :request payload: vring state description > -- > 2.39.1
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 3f18ab424e..8a5924ea75 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -315,7 +315,7 @@ in the ancillary data: * ``VHOST_USER_SET_VRING_KICK`` * ``VHOST_USER_SET_VRING_CALL`` * ``VHOST_USER_SET_VRING_ERR`` -* ``VHOST_USER_SET_SLAVE_REQ_FD`` +* ``VHOST_USER_SET_BACKEND_REQ_FD`` (previous name ``VHOST_USER_SET_SLAVE_REQ_FD``) * ``VHOST_USER_SET_INFLIGHT_FD`` (if ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD``) If *front-end* is unable to send the full message or receives a wrong @@ -516,7 +516,7 @@ expected to reply with a zero payload, non-zero otherwise. The back-end relies on the back-end communication channel (see :ref:`Back-end communication <backend_communication>` section below) to send IOTLB miss -and access failure events, by sending ``VHOST_USER_SLAVE_IOTLB_MSG`` +and access failure events, by sending ``VHOST_USER_BACKEND_IOTLB_MSG`` requests to the front-end with a ``struct vhost_iotlb_msg`` as payload. For miss events, the iotlb payload has to be filled with the miss message type (1), the I/O virtual address and the permissions @@ -540,15 +540,15 @@ Back-end communication ---------------------- An optional communication channel is provided if the back-end declares -``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` protocol feature, to allow the +``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` protocol feature, to allow the back-end to make requests to the front-end. -The fd is provided via ``VHOST_USER_SET_SLAVE_REQ_FD`` ancillary data. +The fd is provided via ``VHOST_USER_SET_BACKEND_REQ_FD`` ancillary data. -A back-end may then send ``VHOST_USER_SLAVE_*`` messages to the front-end +A back-end may then send ``VHOST_USER_BACKEND_*`` messages to the front-end using this fd communication channel. -If ``VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD`` protocol feature is +If ``VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD`` protocol feature is negotiated, back-end can send file descriptors (at most 8 descriptors in each message) to front-end via ancillary data using this fd communication channel. @@ -835,7 +835,7 @@ Note that due to the fact that too many messages on the sockets can cause the sending application(s) to block, it is not advised to use this feature unless absolutely necessary. It is also considered an error to negotiate this feature without also negotiating -``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK``, +``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK``, the former is necessary for getting a message channel from the back-end to the front-end, while the latter needs to be used with the in-band notification messages to block until they are processed, both to avoid @@ -855,12 +855,12 @@ Protocol features #define VHOST_USER_PROTOCOL_F_RARP 2 #define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 #define VHOST_USER_PROTOCOL_F_MTU 4 - #define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5 + #define VHOST_USER_PROTOCOL_F_BACKEND_REQ 5 #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN 6 #define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7 #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8 #define VHOST_USER_PROTOCOL_F_CONFIG 9 - #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10 + #define VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD 10 #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11 #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 #define VHOST_USER_PROTOCOL_F_RESET_DEVICE 13 @@ -1059,8 +1059,8 @@ Front-end message types in the ancillary data. This signals that polling will be used instead of waiting for the call. Note that if the protocol features ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and - ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message - isn't necessary as the ``VHOST_USER_SLAVE_VRING_CALL`` message can be + ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message + isn't necessary as the ``VHOST_USER_BACKEND_VRING_CALL`` message can be used, it may however still be used to set an event file descriptor or to enable polling. @@ -1077,8 +1077,8 @@ Front-end message types invalid FD flag. This flag is set when there is no file descriptor in the ancillary data. Note that if the protocol features ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and - ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message - isn't necessary as the ``VHOST_USER_SLAVE_VRING_ERR`` message can be + ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message + isn't necessary as the ``VHOST_USER_BACKEND_VRING_ERR`` message can be used, it may however still be used to set an event file descriptor (which will be preferred over the message). @@ -1139,7 +1139,7 @@ Front-end message types respond with zero in case the specified MTU is valid, or non-zero otherwise. -``VHOST_USER_SET_SLAVE_REQ_FD`` +``VHOST_USER_SET_BACKEND_REQ_FD`` (previous name ``VHOST_USER_SET_SLAVE_REQ_FD``) :id: 21 :equivalent ioctl: N/A :request payload: N/A @@ -1150,7 +1150,7 @@ Front-end message types This request should be sent only when ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, and protocol - feature bit ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` bit is present in + feature bit ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` bit is present in ``VHOST_USER_GET_PROTOCOL_FEATURES``. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the back-end must respond with zero for success, non-zero otherwise. @@ -1429,7 +1429,7 @@ Back-end message types For this type of message, the request is sent by the back-end and the reply is sent by the front-end. -``VHOST_USER_SLAVE_IOTLB_MSG`` +``VHOST_USER_BACKEND_IOTLB_MSG`` (previous name ``VHOST_USER_SLAVE_IOTLB_MSG``) :id: 1 :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type) :request payload: ``struct vhost_iotlb_msg`` @@ -1444,7 +1444,7 @@ is sent by the front-end. ``VIRTIO_F_IOMMU_PLATFORM`` feature has been successfully negotiated. -``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG`` +``VHOST_USER_BACKEND_CONFIG_CHANGE_MSG`` (previous name ``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG``) :id: 2 :equivalent ioctl: N/A :request payload: N/A @@ -1459,7 +1459,7 @@ is sent by the front-end. ``VHOST_USER_NEED_REPLY`` flag, the front-end must respond with zero when operation is successfully completed, or non-zero otherwise. -``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG`` +``VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG`` (previous name ``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG``) :id: 3 :equivalent ioctl: N/A :request payload: vring area description @@ -1482,7 +1482,7 @@ is sent by the front-end. ``VHOST_USER_PROTOCOL_F_HOST_NOTIFIER`` protocol feature has been successfully negotiated. -``VHOST_USER_SLAVE_VRING_CALL`` +``VHOST_USER_BACKEND_VRING_CALL`` (previous name ``VHOST_USER_SLAVE_VRING_CALL``) :id: 4 :equivalent ioctl: N/A :request payload: vring state description @@ -1496,7 +1496,7 @@ is sent by the front-end. The state.num field is currently reserved and must be set to 0. -``VHOST_USER_SLAVE_VRING_ERR`` +``VHOST_USER_BACKEND_VRING_ERR`` (previous name ``VHOST_USER_SLAVE_VRING_ERR``) :id: 5 :equivalent ioctl: N/A :request payload: vring state description
Backend's message and protocol features names were still using "_SLAVE_" naming. For consistency with the new naming convention and to get rid of the remaining harmful language, replace it with _BACKEND_. Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> --- docs/interop/vhost-user.rst | 40 ++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-)