From: Alexandre Courbot <acourbot@chromium.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Keiichi Watanabe" <keiichiw@chromium.org>,
virtio-dev@lists.oasis-open.org,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Alex Lau" <alexlau@chromium.org>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Dylan Reid" <dgreid@chromium.org>,
"David Staessens" <dstaessens@chromium.org>,
"Dmitry Sepp" <dmitry.sepp@opensynergy.com>,
"Enrico Granata" <egranata@google.com>,
"Frediano Ziglio" <fziglio@redhat.com>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Pawel Osciak" <posciak@chromium.org>,
spice-devel@lists.freedesktop.org,
"David Stevens" <stevensd@chromium.org>,
"Tomasz Figa" <tfiga@chromium.org>,
uril@redhat.com,
"Samiullah Khawaja" <samiullah.khawaja@opensynergy.com>,
"Kiran Pawar" <kiran.pawar@opensynergy.com>
Subject: Re: [PATCH v3 1/2] virtio-video: Add virtio video device specification
Date: Wed, 4 Mar 2020 13:31:19 +0900 [thread overview]
Message-ID: <CAPBb6MWwBbNULCfMxN_KLt_Zd8kmmNy2JPi6XjLF1YgxxCPydw@mail.gmail.com> (raw)
In-Reply-To: <20200227092856.p4kuh5dhh2tk3nnf@sirius.home.kraxel.org>
On Thu, Feb 27, 2020 at 6:29 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> Hi,
>
> > Dmitry's virtio-video driver
> > https://patchwork.linuxtv.org/patch/61717/.
> > Once it becomes fully functional, I'll post a list of possible
> > improvements of protocol.
>
> Cool. Actually implementing things can find design problems
> in the protocol you didn't notice earlier.
>
> > > > +\begin{description}
> > > > +\item[\field{version}] is the protocol version that the device talks.
> > > > + The device MUST set this to 0.
> > >
> > > What is the intended use case for this?
> > >
> > > Given that virtio has feature flags to negotiate support for optional
> > > features and protocol extensions between driver and device, why do you
> > > think this is needed?
> >
> > While feature flags work well when we "extend" the protocol with an
> > optional feature, they don't when we want to "drop" or "modify"
> > features.
> > For example, I guess it'd be useful when we want:
> > * to abandon a non-optional command,
> > * to change a non-optional struct's layout,or
> > * to change the order of commands in which the device expects to be sent.
> >
> > Though it might be possible to handle these changes by feature flags,
> > I suspect the version number allow us to transition protocols more
> > smoothly.
>
> Feature flags can be mandatory, both device and driver can fail
> initialization when a specific feature is not supported by the other
> end. So in case we did screw up things so badly that we have to
> effectively start over (which I hope wouldn't be the case) we can add a
> VERSION_2 feature flag for a new set of commands with new structs and
> new semantics.
>
> With a feature flag both driver and device can choose whenever they want
> support v1 or v2 or both. With a version config field this is more
> limited, the device can't decide to support both. So the bonus points
> for a smooth transition go to the feature flags not the version field ;)
I agree that feature flags would be preferable in general, but I'm
concerned by the fact that there is (IIUC) a limited number of them.
Video tends to change significantly over time, and to have optional
features that would also be presented as feature flags. After a while
we may run out of them, while a new protocol version would allow us to
extend the config struct with some new flags. Or am I missing
something?
I also wonder how "support v1 or v2 or both" would work with feature
flags. In order to make it possible to opt out of v1, I guess we would
need "v1 supported" flag to begin with?
Sorry for the newbie question about feature flags, I'm still in the
process of wrapping my head around virtio. :)
next prev parent reply other threads:[~2020-03-04 4:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 10:20 [PATCH v3 0/2] Virtio video device specification Keiichi Watanabe
2020-02-06 10:20 ` [PATCH v3 1/2] virtio-video: Add virtio " Keiichi Watanabe
2020-02-25 9:59 ` Gerd Hoffmann
2020-02-27 7:24 ` Keiichi Watanabe
2020-02-27 9:28 ` Gerd Hoffmann
2020-03-04 4:31 ` Alexandre Courbot [this message]
2020-03-04 6:42 ` Gerd Hoffmann
2020-03-04 10:07 ` Alexandre Courbot
2020-03-23 12:07 ` Keiichi Watanabe
2020-03-23 13:28 ` Dmitry Sepp
2020-03-23 15:48 ` Keiichi Watanabe
2020-03-25 9:47 ` Dmitry Sepp
2020-03-27 3:35 ` Keiichi Watanabe
2020-03-30 9:53 ` Dmitry Sepp
2020-04-06 9:32 ` Alexandre Courbot
2020-04-06 11:46 ` Keiichi Watanabe
2020-04-07 9:21 ` Dmitry Sepp
2020-04-09 10:46 ` Keiichi Watanabe
2020-04-17 8:08 ` Dmitry Sepp
2020-04-20 9:57 ` Keiichi Watanabe
2020-04-21 8:38 ` Dmitry Sepp
2020-04-24 11:42 ` Keiichi Watanabe
2020-04-27 14:28 ` Dmitry Sepp
2020-04-07 14:49 ` Dmitry Sepp
2020-04-09 10:46 ` Keiichi Watanabe
2020-04-09 13:13 ` Dmitry Sepp
2020-04-24 11:45 ` Keiichi Watanabe
2020-04-27 9:33 ` Dmitry Sepp
2020-05-18 5:17 ` Keiichi Watanabe
2020-05-27 12:12 ` Dmitry Sepp
2020-05-29 14:21 ` Keiichi Watanabe
2020-06-01 7:19 ` Alexandre Courbot
2020-02-06 10:20 ` [PATCH v3 2/2] virtio-video: Define a feature for exported objects from different virtio devices Keiichi Watanabe
2020-02-25 10:01 ` Gerd Hoffmann
2020-02-27 7:24 ` Keiichi Watanabe
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=CAPBb6MWwBbNULCfMxN_KLt_Zd8kmmNy2JPi6XjLF1YgxxCPydw@mail.gmail.com \
--to=acourbot@chromium.org \
--cc=alexlau@chromium.org \
--cc=daniel@ffwll.ch \
--cc=dgreid@chromium.org \
--cc=dmitry.sepp@opensynergy.com \
--cc=dstaessens@chromium.org \
--cc=egranata@google.com \
--cc=fziglio@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=keiichiw@chromium.org \
--cc=kiran.pawar@opensynergy.com \
--cc=kraxel@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=marcheu@chromium.org \
--cc=posciak@chromium.org \
--cc=samiullah.khawaja@opensynergy.com \
--cc=spice-devel@lists.freedesktop.org \
--cc=stevensd@chromium.org \
--cc=tfiga@chromium.org \
--cc=uril@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
/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).