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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.