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.
--
MST
