From: "Alex Bennée" <alex.bennee@linaro.org>
To: stratos-dev@op-lists.linaro.org, virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org
Cc: Matt Spencer <Matt.Spencer@arm.com>,
Peter Griffin <peter.griffin@linaro.org>,
Gerd Hoffmann <kraxel@redhat.com>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Peter Hilber <peter.hilber@opensynergy.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: [virtio-comment] virtio-media-source for cloud native workloads?
Date: Wed, 22 Jun 2022 14:08:59 +0100 [thread overview]
Message-ID: <87fsjwrfx5.fsf@linaro.org> (raw)
Hi,
In my last survey of assigned device numbers I went through all the
currently assigned device numbers and attempted to glean their current
status. However we currently don't have any devices that might be useful
in a Cloud Native development environment.
To define terms cloud native is the idea you can build a workload
processing element as a VM and run it in the cloud. It consumes data
from virtio-devices and processes it in someway. This VM can then be
moved from being hosted in the cloud and into a real platform which
still provides it's data via a virtio device. The idea being you get the
same behaviour (as well as allowing for data to be recorded so future
debugging/tuning work can be done in the cloud).
Currently most of the virtio devices are actually data sinks - for
example for virtio-video the guest pushes data to the video device for
it to process. What we need is a device(s?) to be a source of data to
feed to these workloads.
Why virtio-media-source? Well rather than creating a device for every
data type maybe it would make more sense to have a generic device which
can advertise the data stream info in it's configuration space. This
would allow the kernel driver to then route the data to the appropriate
kernel subsystem (e.g. v4l or alsa).
Would having a virtio driver potentially feeding different sub-systems
based on configuration be a problem?
What do people think?
--
Alex Bennée
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
reply other threads:[~2022-06-22 13:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=87fsjwrfx5.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Matt.Spencer@arm.com \
--cc=arnd.bergmann@linaro.org \
--cc=kraxel@redhat.com \
--cc=mathieu.poirier@linaro.org \
--cc=mst@redhat.com \
--cc=peter.griffin@linaro.org \
--cc=peter.hilber@opensynergy.com \
--cc=stefanha@redhat.com \
--cc=stratos-dev@op-lists.linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=virtio-comment@lists.oasis-open.org \
--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