From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: "Zhiyong Yang" <zhiyong.yang@intel.com>,
dev@dpdk.org, ciara.loftus@intel.com,
"Marc-André Lureau" <mlureau@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] vhost: fix MQ fails to startup
Date: Fri, 28 Apr 2017 16:00:44 +0800 [thread overview]
Message-ID: <20170428080044.GX11512@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <ffc8dc1c-c86b-1a64-87c6-311ae1c695b1@redhat.com>
On Fri, Apr 28, 2017 at 09:57:20AM +0200, Maxime Coquelin wrote:
> >>>Maybe we could introduce a version message? With that, we could tell
> >>>whether the frontend has fixed the known bug or not.
> >>
> >>That's a possibility, but this is not really the role of a protocol
> >>version. As in this case, the protocol does not change, just an
> >>implementation.
> >
> >Maybe. Well, you might could think this way: we do increase the version
> >when we make a new release (with bugs being fixed).
> >
> >Or, we could also make the version two parts: major and minor. We increase
> >major for major updates (say, new features, etc). We increase minor for
> >bug fixes.
> >
> >The only thing that doesn't make too much sense is the bug is actually
> >from the QEMU implementation but not from the vhost-user spec.
>
> Yes, I was maybe not clear, but that's what I meant when saying that was
> not the role of the protocol version.
Yes, I realized it later: I overlooked it. Sorry.
> >Talking
> >about that, it may make more sense to introduce a new message to carry
> >the frontend version, something like a string "QEMU v2.8".
>
> I don't think this is a good idea as it would create more problems that it
> would solve. Indeed, you would need also the distro version, as for
> example, Red Hat could backport the fix in its QEMU v2.6 package, Ubuntu
> in its v2.7, etc...
I have thought of stable release, say "QEMU v2.8.1". But you are right,
it got way more complex when distro backport is considered :(
--yliu
next prev parent reply other threads:[~2017-04-28 8:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-27 6:34 [PATCH] vhost: fix MQ fails to startup Zhiyong Yang
2017-04-27 7:41 ` Loftus, Ciara
2017-04-27 7:56 ` Maxime Coquelin
2017-04-27 8:05 ` Maxime Coquelin
2017-04-27 8:24 ` Yang, Zhiyong
2017-04-27 8:32 ` Maxime Coquelin
2017-04-27 8:20 ` Yuanhan Liu
2017-04-27 8:52 ` Maxime Coquelin
2017-04-28 2:25 ` Yuanhan Liu
2017-04-28 7:23 ` Maxime Coquelin
2017-04-28 7:35 ` Yuanhan Liu
2017-04-28 7:39 ` Yuanhan Liu
2017-04-28 7:57 ` Maxime Coquelin
2017-04-28 8:00 ` Yuanhan Liu [this message]
2017-04-27 8:12 ` Yuanhan Liu
2017-04-27 8:32 ` Yang, Zhiyong
2017-04-27 9:41 ` [PATCH v2] vhost: workaround " Zhiyong Yang
2017-04-27 10:00 ` Maxime Coquelin
2017-04-28 4:29 ` Yuanhan Liu
2017-05-10 2:07 ` Yang, Zhiyong
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=20170428080044.GX11512@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=mlureau@redhat.com \
--cc=mst@redhat.com \
--cc=zhiyong.yang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.