All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@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>,
	Cornelia Huck <cohuck@redhat.com>,
	Pawel Moll <pawel.moll@arm.com>
Subject: [virtio] Re: [virtio-dev] [PATCH 2/6] notifications: notifications as basic virtio facility
Date: Mon, 14 May 2018 18:24:49 +0100	[thread overview]
Message-ID: <20180514172449.GS5182@stefanha-x1.localdomain> (raw)
In-Reply-To: <1524740402-18934-3-git-send-email-pasic@linux.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]

On Thu, Apr 26, 2018 at 12:59:58PM +0200, Halil Pasic wrote:
> Let's introduce notifications as basic virtio facility early on. This
> shall not only increase the cohesion between core and transport
> description by having a well-defined  place where notifications are
> introduced, but also give us the opportunity to explain some
> discrepancies.
> 
> Namely notifications sent by the device to the driver were often called
> interrupts prior to v1.1. Getting completely rid of that terminology is
> however not viable in case of some names.
> 
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
> Changelog:
> RFC -> v1:
> * implemented Connies suggestions (thanks Connie)
> ---
>  content.tex |   36 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/content.tex b/content.tex
> index 2e103cf..d7e2b18 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -8,6 +8,7 @@ device consists of the following parts:
>  \begin{itemize}
>  \item Device status field
>  \item Feature bits
> +\item Notifications
>  \item Device Configuration space
>  \item One or more virtqueues
>  \end{itemize}
> @@ -150,6 +151,41 @@ requirements documented within these legacy interface sections.
>  Specification text within these sections generally does not apply
>  to non-transitional devices.
>  
> +\section{Notifications}\label{sec:Basic Facilities of a Virtio Device
> +/ Notifications}
> +
> +The notion of sending a notification (driver to device or device
> +to driver) plays an important role in this specification. The
> +modus operandi of the notifications is transport specific.
> +
> +There are three types of notifications: 
> +\begin{itemize}
> +\item device configuration space notification
> +\item available buffers notification
> +\item used buffer notifications. 
> +\end{itemize}

"buffers" vs "buffer"; singular vs plural is likely to be used
inconsistently.  Please choose one (either works).

The previous patch said "the term configuration change notification in
kept where called so and consolidated where it's called configuration
change interrupt or similar", but here you say "device configuration
space notification".  Please choose one name and use it consistently.

> +
> +Device configuration space notifications and used buffer notifications
> +are sent by the device, the recipient is the driver. A device
> +configuration space notification indicates that a configuration space
> +has changed; a used buffer notification indicates that a buffer may
> +have been made used on the virtqueue designated by the notification.
> +
> +Available buffer notifications are sent by the driver, the recipient is
> +the device. This type of notification indicates that a buffer may have
> +been made available on the virtqueue designated by the notification.
> +
> +The semantic, the transport-specific implementations and other
> +important aspects of the different notifications are specified in detail
> +in the following chapters

Missing period.

> +
> +Most transports implement notifications sent by the device to the
> +driver using interrupts. Therefore, in previous versions of this
> +specification, these notifications were often called interrupts.
> +Some names defined in this specification still retain this interrupt
> +terminology. Occasionally, the term event is used to refer to
> +a notification or a receipt of a notification.
> +
>  \section{Device Configuration Space}\label{sec:Basic Facilities of a Virtio Device / Device Configuration Space}
>  
>  Device configuration space is generally used for rarely-changing or
> -- 
> 1.7.1
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2018-05-14 17:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 10:59 [virtio] [PATCH 0/6] rework notifications terminology Halil Pasic
2018-04-26 10:59 ` [virtio] [PATCH 1/6] notifications: unify notifications wording in core Halil Pasic
2018-05-14 16:36   ` [virtio] Re: [virtio-dev] " Stefan Hajnoczi
2018-05-14 19:40     ` Halil Pasic
2018-05-15  9:09       ` Stefan Hajnoczi
2018-04-26 10:59 ` [virtio] [PATCH 2/6] notifications: notifications as basic virtio facility Halil Pasic
2018-05-14 17:24   ` Stefan Hajnoczi [this message]
2018-05-15  9:09     ` [virtio] Re: [virtio-dev] " Halil Pasic
2018-04-26 10:59 ` [virtio] [PATCH 3/6] ccw: map common notifications terminology to ccw Halil Pasic
2018-05-14 17:27   ` [virtio] Re: [virtio-dev] " Stefan Hajnoczi
2018-04-26 11:00 ` [virtio] [PATCH 4/6] pci: map common notifications terminology to PCI Halil Pasic
2018-05-15  8:51   ` Stefan Hajnoczi
2018-04-26 11:00 ` [virtio] [PATCH 5/6] mmio: map common notifications terminology to MMIO Halil Pasic
2018-05-15  8:58   ` Stefan Hajnoczi
2018-05-15  9:25     ` [virtio] Re: [virtio-dev] " Halil Pasic
2018-04-26 11:00 ` [virtio] [PATCH 6/6] notifications: update notifications terminology for devices Halil Pasic
2018-05-15  9:00   ` 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=20180514172449.GS5182@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pawel.moll@arm.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.