From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A2B8C3F2CD for ; Wed, 4 Mar 2020 04:31:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 507BC2146E for ; Wed, 4 Mar 2020 04:31:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="mKz8qgkt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726751AbgCDEbf (ORCPT ); Tue, 3 Mar 2020 23:31:35 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:42658 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726094AbgCDEbf (ORCPT ); Tue, 3 Mar 2020 23:31:35 -0500 Received: by mail-oi1-f196.google.com with SMTP id l12so741836oil.9 for ; Tue, 03 Mar 2020 20:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i1xlbs3ZbDJUunrG0mUnxMqSYzI4Jrrt9ZvoGKTfYcA=; b=mKz8qgktXJjlsD4v4w7CRBUnqXzujHbbWhudDh37GcM/8kPum3j/j3WHX/fK9GmDUE TF0lKoAK2oJTLDxrxHbEOzW9mLfLJedSz5hT2EnY1334JPNFvxK2E27Sza3GmNpG4MHR YEtktMPfSPIc0bZSaYESIvhgzq3ZP4tjaaBPE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i1xlbs3ZbDJUunrG0mUnxMqSYzI4Jrrt9ZvoGKTfYcA=; b=uMuB4S3wBRttR2R/alEB3oJ8N/ReySGcYmQ343kihqMBDAJxeL7E7bWyNeQf0bS+fd eGs8b/+gil4GzxhR4169wv+W7gDXculMrhUCD9NIuvxUtiJkX3xf6XmZR5AtcIT72CI4 S8AfFt0peJE2dudGL+JHZ4vQ+Rtty55r2KWLb5k9CWnO1cOf2SDuy8bpBoec760HrL6w r5eGaOrTTJLSoXZgaHL9MNxwvM6Kf4c5Y25nIg3lhqrXEl2KvxJ530zvlCAlgVenfUQI gQW7Riu4REnzRcXBAmjLOXtt7JZKPxRJeq1dlZM7HKkbSk308Z2DkvmqIfLPOeMRb6ef hRRg== X-Gm-Message-State: ANhLgQ1hGkzPXZ1dhnDTAKnmVjvicVz0yGK6mGJYH2s2SQ40HIMznBNL 8xwieASHWsmtnv7A4LXcYQViAeG3KSw= X-Google-Smtp-Source: ADFU+vsc9rAcCZlwlvdvlWR1SFWlmOYelomKish8GoWX80cvqlj8g/or5oj4XCAjt4nnXJGmkqE1mA== X-Received: by 2002:aca:1317:: with SMTP id e23mr548685oii.109.1583296292712; Tue, 03 Mar 2020 20:31:32 -0800 (PST) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com. [209.85.210.51]) by smtp.gmail.com with ESMTPSA id w15sm7847312oth.1.2020.03.03.20.31.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2020 20:31:31 -0800 (PST) Received: by mail-ot1-f51.google.com with SMTP id j14so761522otq.3 for ; Tue, 03 Mar 2020 20:31:31 -0800 (PST) X-Received: by 2002:a9d:75ca:: with SMTP id c10mr897245otl.97.1583296290586; Tue, 03 Mar 2020 20:31:30 -0800 (PST) MIME-Version: 1.0 References: <20200206102058.247258-1-keiichiw@chromium.org> <20200206102058.247258-2-keiichiw@chromium.org> <20200225095956.7rtwugfru4dbjj7q@sirius.home.kraxel.org> <20200227092856.p4kuh5dhh2tk3nnf@sirius.home.kraxel.org> In-Reply-To: <20200227092856.p4kuh5dhh2tk3nnf@sirius.home.kraxel.org> From: Alexandre Courbot Date: Wed, 4 Mar 2020 13:31:19 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/2] virtio-video: Add virtio video device specification To: Gerd Hoffmann Cc: Keiichi Watanabe , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alex Lau , Daniel Vetter , Dylan Reid , David Staessens , Dmitry Sepp , Enrico Granata , Frediano Ziglio , Hans Verkuil , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Pawel Osciak , spice-devel@lists.freedesktop.org, David Stevens , Tomasz Figa , uril@redhat.com, Samiullah Khawaja , Kiran Pawar Content-Type: text/plain; charset="UTF-8" Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Thu, Feb 27, 2020 at 6:29 PM Gerd Hoffmann 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. :)