[virtio-dev,RFC,v1,1/2] content: define what an exported object is

Define a mechanism for sharing objects between different virtio
devices.

Signed-off-by: David Stevens <stevensd@chromium.org>
---
 content.tex | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

Operation}\label{sec:General Initialization And Device Operation}

 We start with an overview of device initialization, then expand on the

On Wed, Jan 22, 2020 at 04:16:24PM +0900, David Stevens wrote:
> Define a mechanism for sharing objects between different virtio
> devices.
> 
> Signed-off-by: David Stevens <stevensd@chromium.org>
> ---
>  content.tex | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/content.tex b/content.tex
> index b1ea9b9..6c6dd59 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -373,6 +373,24 @@ \section{Driver Notifications}
> \label{sec:Virtqueues / Driver notifications}
> 
>  \input{shared-mem.tex}
> 
> +\section{Exporting Objects}\label{sec:Basic Facilities of a Virtio
> Device / Exporting Objects}
> +
> +When an object created by one virtio device needs to be
> +shared with a seperate virtio device, the first device can
> +export the object by generating a \field{uuid}

This is a field where?

> which the
> +guest can pass to the second device to identify the object.


s/guest/Driver/ ?

> +
> +What constitutes an object, how to export objects, and
> +how to import objects are defined by the individual device
> +types. The generation method of a \field{uuid} is dependent
> +upon the implementation of the exporting device.
> +
> +Whether a particular exported object can be imported into
> +a device is dependent upon the implementations of the exporting
> +and importing devices. Generally speaking, the guest should
> +have some knowledge of the host configuration before trying to
> +use exported objects.

this last paragraph seems to be too general to be really useful.

Also - what are guest and host here?


> +
>  \chapter{General Initialization And Device
> Operation}\label{sec:General Initialization And Device Operation}
> 
>  We start with an overview of device initialization, then expand on the
> -- 
> 2.25.0.341.g760bfbb309-goog
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

> > +When an object created by one virtio device needs to be
> > +shared with a seperate virtio device, the first device can
> > +export the object by generating a \field{uuid}
>
> This is a field where?

It's a property of the exported object, but I guess it doesn't really
correspond to any concrete field. I'll remove \field.

> > which the
> > +guest can pass to the second device to identify the object.
>
> s/guest/Driver/ ?

The uuid can be passed to a second device controlled by a different
driver, so I think 'driver' by itself is ambiguous. I'm using guest as
a shorthand for 'system which includes the drivers and software which
sits on top of the drivers', and that meaning does seem to be
compatible with language in the rest of the spec. If that shorthand
isn't acceptable, I can rewrite the sentence passively as '... a uuid
which can then be passed to a second device ...'.

> Also - what are guest and host here?

There are a number of places in the virtio spec where 'guest' is used
to refer to the system where drivers run and where 'host' is used to
refer to the system where devices run. I guess those terms aren't
concretely defined within the spec, but they do seem to have a well
understood meaning. Or is the guest/host language discouraged in new
additions to the spec?

-David

On Wed, Jan 22, 2020 at 07:13:41PM +0900, David Stevens wrote:
> > > +When an object created by one virtio device needs to be
> > > +shared with a seperate virtio device, the first device can
> > > +export the object by generating a \field{uuid}
> >
> > This is a field where?
> 
> It's a property of the exported object, but I guess it doesn't really
> correspond to any concrete field. I'll remove \field.
> 
> > > which the
> > > +guest can pass to the second device to identify the object.
> >
> > s/guest/Driver/ ?
> 
> The uuid can be passed to a second device controlled by a different
> driver, so I think 'driver' by itself is ambiguous. I'm using guest as
> a shorthand for 'system which includes the drivers and software which
> sits on top of the drivers', and that meaning does seem to be
> compatible with language in the rest of the spec. If that shorthand
> isn't acceptable, I can rewrite the sentence passively as '... a uuid
> which can then be passed to a second device ...'.
> 
> > Also - what are guest and host here?
> 
> There are a number of places in the virtio spec where 'guest' is used
> to refer to the system where drivers run and where 'host' is used to
> refer to the system where devices run. I guess those terms aren't
> concretely defined within the spec, but they do seem to have a well
> understood meaning. Or is the guest/host language discouraged in new
> additions to the spec?
> 
> -David

Yes - generally most devices are/should be implementable in hardware.
In that setup guest/host doesn't make sense.
We haven't reworked all of spec with that in mind yet,
and in some cases such as the balloon it's actually specific to
virtualization.