Re: [virtio-dev] Re: [RFC PATCH v6] virtio-video: Add virtio video device specification

[Alexander Gordeev <alexander.gordeev@opensynergy.com>]

On 28.04.23 06:02, Alexandre Courbot wrote:
> This is going to be my last answer to this thread ; I don't think I
> have more technical arguments to give than I already have and the
> discussion is drifting into territory I am not interested in engaging.
> At the end of the day it's up to the virtio folks to make a decision
> about what the best course of action is. If we end up with
> fragmentation, so be it, it will still be better than the current
> situation anyway.

I agree with the summary. I think we have discussed all the things in
depth and even reached some understanding.
Could you please at least share your feedback on my proposal for the
QUEUE/DRAIN completion handling?

> On Thu, Apr 27, 2023 at 11:11âPM Alexander Gordeev
> <alexander.gordeev@opensynergy.com> wrote:
> > On 25.04.23 18:04, Cornelia Huck wrote:
> > > [I'm replying here, as that seems to be the last message in the thread,
> > > and my reply hopefully catches everyone interested here.]
> > >
> > > To do a very high level summary, we have (at least) two use cases for
> > > virtio-video, that unfortunately have quite different requirements. Both
> > > want to encode/decode video, but in different environments.
> > >
> > > - The "restricted" case: Priority is on security, and the attack surface
> > >     should be kept as small as possible, for example, by avoiding unneded
> > >     complexity in the interface. Fancy allocations and management should
> > >     be avoided. The required functionality is also quite clearly defined.
> > > - The "feature-rich" case: Priority is on enabling features, and being
> > >     able to re-use existing V4L2 support is considered a big plus. Both
> > >     device and driver implementations will be implemented in a full OS
> > >     environment, so all kind of helpers are already available.
> > >
> > > (This is not to say that one case does not care about functionality or
> > > security; it's mostly a case of different priorities and environments.)
> >
> > I'm thinking about the latter as more like a "compatibility" case, but
> > the "feature-rich" is also a good name.
> >
> > > I had been hoping that it would be possible to find kind of a common
> > > ground between the two cases, but reading the thread, I'm not quite as
> > > hopeful anymore... if we really don't manage to find an approach to make
> > > the different requirements co-exist, a separate virtio-v4l2 device might
> > > be the way to go -- but I've not totally given up hope yet.
> >
> >   From our side I can say, that moving from the current state even to a
> > well-defined subset of V4L2 would require a lot of work, bring literally
> > zero advantages for our use-case, while bringing some disadvantages. I
> > think we had a good progress so far, we don't want to give up the
> > achievements and now this is a great opportunity to do even better
> > because our priorities will not collide anymore.
>
> In other words, virtio-v4l2 does not bring you any direct benefit and
> switching would have a cost, acknowledged. But I don't think it's
> reasonable to split the standard just for one project.

I've acknowledged this in many emails already. But I wouldn't argue that
long if this is only about costs. I'm a developer after all. (I'm not
paying my salary myself.) I believe, that virtio-video is simply better
for a whole class of use-cases, including ours.

> > On the other side I don't think Alexandre and his team are really
> > interested in doing the extra work of clearly defining the subset of
> > V4L2, writing larger specifications, going through all the hassle with
> > making the guest pages sharing work (again) and supporting this case in
> > their driver for us for something that is planned to be a very simple
> > device and driver. Please correct me if I'm wrong here.
>
> You are wrong and stop making things up about what our intent is.
> Guest pages are a must-have for us, as I've already said. I also
> proposed in a former email to do just what you said I wouldn't
> (defining a valid subset of V4L2 for each device), and you ignored it.

Hmm, I haven't ignored it, I just didn't have time to answer, sorry. I
answered it a few minutes ago.
Are guest pages a must have because some of the user-space apps want to
use them? Or is the conversion of memory types in the driver also a must
have to you? As far as I can understand your use-case, the former is a
must have, but the latter is not. At the same time the latter is a must
have for us. We already have this implemented this in the virtio-video
spec and virtio-video driver. Also I believe the virtio-video spec is
much clearer and better defined, compared to V4L2 UAPI, so we'd like to
focus on improving the current state, not downgrading to V4L2 UAPI.

> I won't engage any more in this discussion as I don't think your
> position can be moved, and I have better things to do with my time
> than constantly repeat what I said earlier. Do your thing, I'll do
> mine, and at the end the virtio folks will decide what they want.

So be it.

--
Alexander Gordeev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone: +49 30 60 98 54 0 - 88
Fax: +49 (30) 60 98 54 0 - 99
EMail: alexander.gordeev@opensynergy.com

www.opensynergy.com

Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
GeschÃftsfÃhrer/Managing Director: RÃgis Adjamah

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>