From: "Michael S. Tsirkin" <mst@redhat.com>
To: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Cc: virtio-comment@lists.linux.dev,
"VirtIO Dev List" <virtio-dev@lists.linux.dev>,
"Bill Mills" <bill.mills@linaro.org>,
"David Hildenbrand" <david@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
"Sergio Lopez" <slp@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: Central repo for VirtIO conformance tests?
Date: Mon, 19 May 2025 03:54:01 -0400 [thread overview]
Message-ID: <20250519034810-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAAjaMXZgeNpExoiDKr3RRms_voE0bU9G033gOmawDqsFbGj2Gw@mail.gmail.com>
On Mon, May 19, 2025 at 10:43:33AM +0300, Manos Pitsidianakis wrote:
> Pinging this thread to ask the OASIS people: Would it be possible to
> host a software project (this testsuite) under OASIS but with a
> lighter contribution process? We expect everyone to be contributing to
> them, from open source/proprietary hypervisor developers, to kernel/OS
> developers, hobbyists and professionals alike. So I think a low
> barrier of entry would be reasonable here.
Take a look here pls:
https://www.oasis-open.org/open-repositories/#licensingRules
> Seeing as a test suite is essentially tied to the published VIRTIO
> spec itself it also makes it a good fit semantically. Having a suite
> with multiple VIRTIO implementations including slim images with Linux
> would also give a wider frame of reference for downstream consumers of
> the spec. Currently, the Linux kernel is the de facto (because it's
> also open source) VIRTIO implementation on the frontend side and
> oftentimes we end up looking at what Linux does to implement backends.
>
> We'd like to potentially:
>
> - Expand the array of rootfs images with more Linux userspace tests
> for more devices
> - Expand the array of rootfs images with other open source OSes as
> they gain VIRTIO functionalities
> - Implement missing VIRTIO spec features in our unikernel test and
> also exercise realistic but basic VIRTIO command use scenarios for
> more devices
> - (This is on my personal wishlist) write a VIRTIO fuzzer framework,
> similar in spirit to Google's syzkaller project (unsupervised
> coverage-guided kernel fuzzer)
> - As a stretch goal, provide a reference test runner framework to run
> the images with QEMU and rust-vmm vhost-user backends for people to
> adapt to their setups.
>
> PS: The git repositories Alex linked are temporarily inaccessible due
> to internal unrelated issues, and will be public again.
At the moment, from the above link, and if you want it tied to OASIS
open repositories, it has to be one of:
BSD-3-Clause License (which shall apply if the TC makes no license selection in its approval action); Apache License v 2.0; CC-BY 2.0; CC-BY 4.0; Eclipse Public License v 1.0.
I am not a lawyer, but can full OS images we licensed under one of
these? If not, you are better off creating the repository itself outside
the confines of OASIS.
You can still use e.g. virtio-dev mailing list for communication.
> --
> Manos Pitsidianakis
> Emulation and Virtualization Engineer at Linaro Ltd
next prev parent reply other threads:[~2025-05-19 7:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-31 10:38 Central repo for VirtIO conformance tests? Alex Bennée
2025-03-31 11:52 ` Stefan Hajnoczi
[not found] ` <Z-qHKUveoHc85koj@redhat.com>
2025-03-31 12:20 ` Stefan Hajnoczi
[not found] ` <CAJSP0QW6=SvLwkuTsZTKqCH9OQJdH8XV32hDZ9Z4o6AbCbOqiA@mail.gmail.com>
2025-03-31 12:36 ` Alex Bennée
2025-05-19 7:43 ` Manos Pitsidianakis
2025-05-19 7:54 ` Michael S. Tsirkin [this message]
2025-05-19 8:03 ` Manos Pitsidianakis
2025-05-19 8:15 ` Michael S. Tsirkin
2025-05-19 8:18 ` Manos Pitsidianakis
2025-05-19 12:30 ` Michael S. Tsirkin
2025-05-29 21:34 ` Michael S. Tsirkin
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=20250519034810-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bill.mills@linaro.org \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=dmitry.osipenko@collabora.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=sgarzare@redhat.com \
--cc=slp@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.linux.dev \
--cc=virtio-dev@lists.linux.dev \
/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