From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
Usama Arif <usama.arif@bytedance.com>,
virtio-dev@lists.oasis-open.org, stefanha@redhat.com,
ndragazis@arrikto.com, fam.zheng@bytedance.com,
liangma@liangbit.com
Subject: Re: [virtio-dev] Re: [PATCH 1/4] content: Introduce driver/device auxiliary notifications
Date: Thu, 11 Aug 2022 07:15:15 -0400 [thread overview]
Message-ID: <20220811071300-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <87ilmzcffd.fsf@redhat.com>
On Thu, Aug 11, 2022 at 11:12:06AM +0200, Cornelia Huck wrote:
> >> OTOH when reading the spec, it my strike one as strange, that for example
> >> CCW does not mention aux notifications at all. One idea: maybe we could
> >> add a note, or a subsection, or something, which states the list of
> >> general optional virtio facilities or features not supported by the given
> >> transport on the spec level for a given incarnation of the spec.
> >
> > Yes I think each transport should list features it does not
> > support, and a feature specific to some transports must
> > also require that other transports disable it and
> > that drivers do not ack it.
> > Otherwise it's too easy for devices to offer the feature bit
> > by mistake.
>
> Do we need to add a requirement for every transport-specific feature, or
> would it be sufficient to add a statement like "if a feature requires a
> transport-specific implementation, a device using that transport MUST
> NOT offer that feature"?
I'd prefer to list the features explicitly.
In particular is kind of forces whoever is proposing
the feature into at least be aware that other transports
exist and that the proposal is incomplete.
> >
> >> I think making the people not motivated to do the design and write the
> >> spec for all the platforms add to that list is a reasonable middle
> >> ground. It would also make the differences very clear, and the same goes
> >> for the intention (i.e. not omitted by mistake).
>
> Hm. On the one hand, I like that it would add a laundry list for
> transports regarding features that might be implemented. On the other
> hand, I think the main problem is not enough people with enough
> understanding and bandwidth to add new features everywhere... but I
> suppose that needs to be fixed in a different place anyway.
next prev parent reply other threads:[~2022-08-11 11:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220330152105.3770439-1-usama.arif@bytedance.com>
[not found] ` <20220330152105.3770439-5-usama.arif@bytedance.com>
2022-08-09 20:06 ` [virtio-dev] Re: [PATCH 4/4] vhost-user: add vhost-user device type Michael S. Tsirkin
2022-08-11 10:05 ` Usama Arif
2022-08-11 11:20 ` Michael S. Tsirkin
2022-08-12 9:51 ` [External] " Usama Arif
[not found] ` <20220330152105.3770439-2-usama.arif@bytedance.com>
2022-08-09 20:07 ` [PATCH 1/4] content: Introduce driver/device auxiliary notifications Michael S. Tsirkin
2022-08-10 9:54 ` [virtio-dev] " Cornelia Huck
2022-08-10 12:45 ` Michael S. Tsirkin
2022-08-10 13:07 ` [virtio-dev] " Cornelia Huck
2022-08-10 17:59 ` Halil Pasic
2022-08-10 17:41 ` Halil Pasic
2022-08-10 19:23 ` Michael S. Tsirkin
2022-08-11 9:12 ` Cornelia Huck
2022-08-11 11:15 ` Michael S. Tsirkin [this message]
2022-08-11 14:41 ` Halil Pasic
2022-08-11 17:27 ` Halil Pasic
2022-08-11 8:53 ` Cornelia Huck
2022-08-11 14:09 ` Halil Pasic
2022-08-11 16:20 ` David Hildenbrand
2022-03-30 15:26 [virtio-dev] [PATCH 0/4] Introduce aux. notifications and virtio-vhost-user Usama Arif
2022-03-30 15:26 ` [virtio-dev] [PATCH 1/4] content: Introduce driver/device auxiliary notifications Usama Arif
2022-04-04 10:06 ` [virtio-dev] " Stefan Hajnoczi
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=20220811071300-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=fam.zheng@bytedance.com \
--cc=liangma@liangbit.com \
--cc=ndragazis@arrikto.com \
--cc=pasic@linux.ibm.com \
--cc=stefanha@redhat.com \
--cc=usama.arif@bytedance.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 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.