[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] docs: vhost-user: replace _SLAVE_ with _BACKEND_
From: |
Michael S. Tsirkin |
Subject: |
Re: [PATCH 1/3] docs: vhost-user: replace _SLAVE_ with _BACKEND_ |
Date: |
Mon, 30 Jan 2023 06:10:29 -0500 |
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
- [PATCH 0/3] Vhost-user: replace _SLAVE_ with _BACKEND_, Maxime Coquelin, 2023/01/30
- [PATCH 3/3] vhost-user: Adopt new backend naming, Maxime Coquelin, 2023/01/30
- [PATCH 1/3] docs: vhost-user: replace _SLAVE_ with _BACKEND_, Maxime Coquelin, 2023/01/30
- Re: [PATCH 1/3] docs: vhost-user: replace _SLAVE_ with _BACKEND_,
Michael S. Tsirkin <=
- [PATCH 2/3] libvhost-user: Adopt new backend naming, Maxime Coquelin, 2023/01/30
- Re: [PATCH 0/3] Vhost-user: replace _SLAVE_ with _BACKEND_, Michael S. Tsirkin, 2023/01/30
- Re: [PATCH 0/3] Vhost-user: replace _SLAVE_ with _BACKEND_, Stephen Hemminger, 2023/01/30