qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages
Date: Thu, 12 Sep 2019 22:37:26 +0200	[thread overview]
Message-ID: <b7ddb3f2f546b5f25b1e90c917306b11d5245608.camel@sipsolutions.net> (raw)
In-Reply-To: <20190912122253.GH23174@stefanha-x1.localdomain> (sfid-20190912_142301_873866_C4E851C8)

On Thu, 2019-09-12 at 14:22 +0200, Stefan Hajnoczi wrote:
> 
> The vhost-user spec is unclear and inconsistent.  Patches are welcome.

:)

> A footnote describing the old terminology would be necessary so that
> existing documentation, code, etc can still be decyphered when the spec
> changes the terminology :).

Yeah.

But we (you) would have to decide first what the terminology actually
*should* be :-)

I'd have said something like "host" and "device", but then "host" can
get confusing in the context of qemu, is it the host that the VM is
running on? It's the VM that's hosting the device, but that's a bit confusing in this context.

Client/server might work, but it's not very obvious either (**), and
quite a bit of the text actually gets it wrong right now, so it'd be
very confusing to swap that and have a footnote or similar indicate that
it was described the other way around previously ...

Calling it master/slave as the text does now is a bit confusing to me
because it has DMA (of sorts) and that's called "bus mastering" in most
other contexts, but perhaps that's what would work best nonetheless,
though I'm not really a fan of that terminology.

Perhaps master/device would be nicer, getting the term "device" in there
somewhere would seem appropriate, even if it's not really actually a
device, but from the view inside the "master" VM it is a device...


(**) Btw, is it really true that there's a way to have the device make
the connection to a listening unix domain socket, as implied by the
spec? I cannot find evidence for such a mode in any code...

johannes



  reply	other threads:[~2019-09-12 20:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-02 12:12 [Qemu-devel] [RFC] vhost-user simulation extension Johannes Berg
2019-09-02 12:12 ` [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages Johannes Berg
2019-09-05 20:28   ` Johannes Berg
2019-09-09 16:00     ` Stefan Hajnoczi
2019-09-09 17:34       ` Johannes Berg
2019-09-10 15:03         ` Stefan Hajnoczi
2019-09-10 15:14           ` Johannes Berg
2019-09-10 15:33             ` Michael S. Tsirkin
2019-09-10 15:34               ` Johannes Berg
2019-09-11  6:56                 ` Stefan Hajnoczi
2019-09-11  7:35             ` Stefan Hajnoczi
2019-09-11  8:26               ` Johannes Berg
2019-09-11 15:17                 ` Stefan Hajnoczi
2019-09-11 15:31   ` Stefan Hajnoczi
2019-09-11 15:36     ` Johannes Berg
2019-09-11 15:38       ` Johannes Berg
2019-09-12 12:22       ` Stefan Hajnoczi
2019-09-12 20:37         ` Johannes Berg [this message]
2019-09-06 12:13 ` [Qemu-devel] [RFC] libvhost-user: implement VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS Johannes Berg
2019-09-06 14:22   ` Michael S. Tsirkin
2019-09-06 14:48     ` Johannes Berg
2019-09-06 15:12       ` Michael S. Tsirkin
2019-09-06 15:32         ` Johannes Berg
2019-09-08 13:13           ` Michael S. Tsirkin
2019-09-09 11:35             ` Johannes Berg
2019-09-09 12:41               ` Michael S. Tsirkin
2019-09-09 13:05                 ` Johannes Berg
2019-09-09 13:48                   ` Michael S. Tsirkin
2019-09-09 13:50                     ` Johannes Berg
2019-09-09 14:59                       ` Michael S. Tsirkin
2019-09-09 15:26                         ` Johannes Berg
2019-09-09 15:34                           ` Johannes Berg
2019-09-09 15:45                             ` Michael S. Tsirkin
2019-09-09 15:47                               ` Johannes Berg
2019-09-10 15:52                       ` Johannes Berg
2019-09-11  9:16                         ` Michael S. Tsirkin
2019-09-11  9:20                           ` Johannes Berg
2019-09-11  9:54                             ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b7ddb3f2f546b5f25b1e90c917306b11d5245608.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).