OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-dev] [PATCH v4] vsock: add vsock device

On Mon, Mar 21, 2016 at 12:53:23PM +0000, Ian Campbell wrote:

Answers to the first few points.  I'll reply with more tomorrow.

> On Wed, 2016-03-16 at 10:53 +0000, Stefan Hajnoczi wrote:
> The Linux .ko and various things under sysfs end up called "transport-
> virtio" (or s/-/_/g) rather than e.g. "vsock-transport-virtio", which
> would be less generic sounding.

Besides renaming the module to vsock_transport_virtio.c, is there
anything else you noticed that needs to be renamed?

> > diff --git a/trunk/content.tex b/trunk/content.tex
> > index d989d98..4e9f165 100644
> > --- a/trunk/content.tex
> > +++ b/trunk/content.tex
> > @@ -5641,6 +5641,223 @@ descriptor for the \field{sense_len}, \field{residual},
> >  \field{status_qualifier}, \field{status}, \field{response} and
> >  \field{sense} fields.
> > 
> > +\section{Socket Device}\label{sec:Device Types / Socket Device}
> > +
> > +The virtio socket device is a zero-configuration socket communications device.
> > +It facilitates data transfer between the guest and device without using the
> > +Ethernet or IP protocols.
> > +
> > +\subsection{Device ID}\label{sec:Device Types / Socket Device / Device ID}
> > +  13
> The SVN version of the virtio spec seems to include many more device id
> allocations, in particular in the table at the start of Section 5
> ("Device Types") it assigns 13 as "memory balloon" (not the traditional
> one) and 5.5 ("Traditional Memory Balloon Device") says:
>     This is the traditional balloon device. The device number 13 is
>     reserved for a new memory balloon interface, with different
>     semantics, which is expected in a future version of the standard.

Thanks for pointing this out.  I'll select a new device ID.

> > +The ctrl virtqueue is reserved for future use and is currently unused.
> Is the normal way to reflect this in a driver backend implementation by
> exposing a small (perhaps even zero sized) queue?

I'll drop the ctrl virtqueue in the next revision.

Previous revisions had the ctrl virtqueue at index 0, followed by rx and
tx.  Now that the ctrl and event virtqueues are at the end we might as
well make ctrl the last virtqueue.  At that point there's no reason to
reserve it anymore so it can be dropped.

Attachment: signature.asc
Description: PGP signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]