From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: virtio@lists.oasis-open.org, virtio-dev@lists.oasis-open.org,
"Michael S. Tsirkin" <mst@redhat.com>,
Pawel Moll <pawel.moll@arm.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: [virtio] Re: [PATCH v2 1/6] notifications: unify notifications wording in core
Date: Wed, 13 Jun 2018 11:44:43 +0200 [thread overview]
Message-ID: <20180613114443.4f7a6bba.cohuck@redhat.com> (raw)
In-Reply-To: <1528733518-24950-2-git-send-email-pasic@linux.ibm.com>
On Mon, 11 Jun 2018 18:11:53 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:
> Let us unify the wording when talking about notifications. This change
> establishes the terms available buffer notification for what was usually
> simply called notification or virtqueue notification in v1.0 and used
> buffer notification for what was usually called interrupt.
>
> The term configuration change notification in kept where called so and
> consolidated where it's called configuration change interrupt or
> similar.
>
> The changes done here are limited to the core part, and don't
> conceptually involve neither the transports nor the devices (references
> are updated though). Future changes should address these parts.
>
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
> cl-os.tex | 2 +-
> conformance.tex | 8 +++---
> content.tex | 26 +++++++++++--------
> packed-ring.tex | 61 ++++++++++++++++++++++++++--------------------
> split-ring.tex | 72 ++++++++++++++++++++++++++++++++-----------------------
> 5 files changed, 96 insertions(+), 73 deletions(-)
>
> diff --git a/content.tex b/content.tex
> index be18234..e1dcaea 100644
> --- a/content.tex
> +++ b/content.tex
(...)
> @@ -388,10 +391,11 @@ reads unless notified.
>
> \subsection{Notification of Device Configuration Changes}\label{sec:General Initialization And Device Operation / Device Operation / Notification of Device Configuration Changes}
>
> -For devices where the device-specific configuration information can be changed, an
> -interrupt is delivered when a device-specific configuration change occurs.
> +For devices where the device-specific configuration information can be
> +changed, a configuration change notification is delivered when a
Perhaps better "is sent", to keep in line with the used/available
buffer notifications?
> +device-specific configuration change occurs.
>
> -In addition, this interrupt is triggered by the device setting
> +In addition, this notification is triggered by the device setting
> DEVICE_NEEDS_RESET (see \ref{sec:Basic Facilities of a Virtio Device / Device Status Field / DEVICENEEDSRESET}).
>
> \section{Device Cleanup}\label{sec:General Initialization And Device Operation / Device Cleanup}
(...)
> @@ -309,22 +310,20 @@ in the ring.
>
> \subsection{Driver and Device Event Suppression}
> \label{sec:Packed Virtqueues / Driver and Device Event Suppression}
> -In many systems driver and device notifications involve
> +In many systems used and available buffer notifications involve
> significant overhead. To mitigate this overhead,
> each virtqueue includes two identical structures used for
> controlling notifications between the device and the driver.
>
> The Driver Event Suppression structure is read-only by the
> -device and controls the events sent by the device
> -to the driver (e.g. interrupts).
> +device and controls the used buffer notifications (sent by the device
> +to the driver).
Drop the brackets?
>
> The Device Event Suppression structure is read-only by
> -the driver and controls the events sent by the driver
> -to the device (e.g. IO).
> +the driver and controls the available buffer notifications (sent by the
> +driver to the device).
Here as well.
>
> -Each of these Event Suppression structures controls
> -both Descriptor Ring events and structure events, and
> -each includes the following fields:
> +Each of these Event Suppression includes the following fields:
"Event Suppression" what? Keep "structures"?
>
> \begin{description}
> \item [Descriptor Ring Change Event Flags] Takes values:
> @@ -352,9 +351,9 @@ matches this value and a descriptor is
> made available/used respectively.
> \end{description}
>
> -After writing out some descriptors, both the device and the driver
> +After writing out some descriptors, the device/driver
Keep this unchanged?
> are expected to consult the relevant structure to find out
> -whether an interrupt/notification should be sent.
> +whether a(n) used/available buffer notification should be sent.
"whether a used respectively an available buffer notification..."?
>
> \subsubsection{Structure Size and Alignment}
> \label{sec:Packed Virtqueues / Structure Size and Alignment}
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
next prev parent reply other threads:[~2018-06-13 9:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 16:11 [virtio] [PATCH v2 0/6] rework notifications terminology Halil Pasic
2018-06-11 16:11 ` [virtio] [PATCH v2 1/6] notifications: unify notifications wording in core Halil Pasic
2018-06-13 9:44 ` Cornelia Huck [this message]
2018-06-13 13:14 ` [virtio] " Halil Pasic
2018-06-13 13:04 ` Stefan Hajnoczi
2018-06-13 13:22 ` Halil Pasic
2018-06-11 16:11 ` [virtio] [PATCH v2 2/6] notifications: notifications as basic virtio facility Halil Pasic
2018-06-13 9:48 ` [virtio] " Cornelia Huck
2018-06-13 13:07 ` Stefan Hajnoczi
2018-06-13 13:38 ` Halil Pasic
2018-06-11 16:11 ` [virtio] [PATCH v2 3/6] ccw: map common notifications terminology to ccw Halil Pasic
2018-06-13 9:50 ` [virtio] " Cornelia Huck
2018-06-11 16:11 ` [virtio] [PATCH v2 4/6] pci: map common notifications terminology to PCI Halil Pasic
2018-06-13 9:51 ` [virtio] " Cornelia Huck
2018-06-11 16:11 ` [virtio] [PATCH v2 5/6] mmio: map common notifications terminology to MMIO Halil Pasic
2018-06-13 9:59 ` [virtio] " Cornelia Huck
2018-06-11 16:11 ` [virtio] [PATCH v2 6/6] notifications: update notifications terminology for devices Halil Pasic
2018-06-13 10:00 ` [virtio] " Cornelia Huck
2018-06-13 13:09 ` Stefan Hajnoczi
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=20180613114443.4f7a6bba.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pawel.moll@arm.com \
--cc=stefanha@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtio@lists.oasis-open.org \
/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