Re: [PATCH v3 1/6] notifications: unify notifications wording in core

[Cornelia Huck <cohuck@redhat.com>]

On Mon, 25 Jun 2018 14:21:27 +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>
> ---
> v2 -> v3
> * Addressed all comments by Connie and Stefan (changed both directions
> with the my nonsensical "i.e.'s" that was pointed out by Stefan)
> * Added unrelated grammar fix s/writes entry/writes an entry/ (Stefan)
> ---
>  cl-os.tex       |    2 +-
>  conformance.tex |    8 +++---
>  content.tex     |   26 +++++++++++--------
>  packed-ring.tex |   60 ++++++++++++++++++++++++++--------------------
>  split-ring.tex  |   72 ++++++++++++++++++++++++++++++++-----------------------
>  5 files changed, 96 insertions(+), 72 deletions(-)
> 

> diff --git a/content.tex b/content.tex
> index be18234..9b1f3e1 100644
> --- a/content.tex
> +++ b/content.tex
(...)
> @@ -235,12 +236,13 @@ transmit and one for receive.}.
>  Driver makes requests available to device by adding
>  an available buffer to the queue - i.e. adding a buffer
>  describing the request to a virtqueue, and optionally triggering
> -a driver event - i.e. sending a notification to the device.
> +a driver event - i.e. sending an available buffer notification
> +to the device.
>  
>  Device executes the requests and - when complete - adds
>  a used buffer to the queue - i.e. lets the driver
>  know by marking the buffer as used. Device can then trigger
> -a device event - i.e. send an interrupt to the driver.
> +a device event - i.e. send a used buffer notification to the driver.
>  
>  Device reports the number of bytes it has written to memory for
>  each buffer it uses. This is referred to as ``used length''.

Unrelated: Device and driver are missing the definite article in some
places. Might be an idea for an additional patch :)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>