[PATCH v3 0/6] rework notifications terminology

From
Cornelia Huck <>
Date
2018-06-25T14:45:00+00:00
ID
Thread
[PATCH v3 0/6] rework notifications terminology
On Mon, 25 Jun 2018 14:21:27 +0200
Halil Pasic <> 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 <>
> ---
> 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 <>