qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com,
	stephen@networkplumber.org, chenbo.xia@intel.com,
	thomas@monjalon.net, dmarchan@redhat.com
Subject: Re: [PATCH 1/3] docs: vhost-user: replace _SLAVE_ with _BACKEND_
Date: Mon, 30 Jan 2023 06:10:29 -0500	[thread overview]
Message-ID: <20230130060904-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230130104548.13262-2-maxime.coquelin@redhat.com>

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



  reply	other threads:[~2023-01-30 11:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 10:45 [PATCH 0/3] Vhost-user: replace _SLAVE_ with _BACKEND_ Maxime Coquelin
2023-01-30 10:45 ` [PATCH 1/3] docs: vhost-user: " Maxime Coquelin
2023-01-30 11:10   ` Michael S. Tsirkin [this message]
2023-01-30 10:45 ` [PATCH 2/3] libvhost-user: Adopt new backend naming Maxime Coquelin
2023-01-30 11:11   ` Michael S. Tsirkin
2023-01-30 10:45 ` [PATCH 3/3] vhost-user: " Maxime Coquelin
2023-01-30 11:12   ` Michael S. Tsirkin
2023-01-30 11:08 ` [PATCH 0/3] Vhost-user: replace _SLAVE_ with _BACKEND_ Michael S. Tsirkin
2023-01-30 11:48   ` Maxime Coquelin
2023-01-30 16:44 ` Stephen Hemminger via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230130060904-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=chenbo.xia@intel.com \
    --cc=dmarchan@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).