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 08:30:36 -0400 [thread overview]
Message-ID: <20250519082712-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAAjaMXZZX+i86U4_N1_8+czc2kcWP3=NUgLjT8BMemCYBD6uUw@mail.gmail.com>
On Mon, May 19, 2025 at 11:18:36AM +0300, Manos Pitsidianakis wrote:
> On Mon, May 19, 2025 at 11:15 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, May 19, 2025 at 11:03:43AM +0300, Manos Pitsidianakis wrote:
> > > Hello Michael, thanks for the reply,
> > >
> > > On Mon, May 19, 2025 at 10:54 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > 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.
> > >
> > > OK that's doable and completely reasonable.
> > >
> > > > 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.
> > >
> > > We'd be hosting essentially build recipes for the images, for tests
> > > where we use other people's code. The build recipes would have the
> > > same license.
> > >
> > > If I understand the CLA requirement correctly, even if the
> > > contribution is merged by a maintainer who has signed the CLA, the
> > > original contributor who has no write access to the repository, has to
> > > sign the CLA as well?
> >
> >
> > I think is would be the OASIS equivalent of the Linux DCO:
> > Each person making a repo contribution must be bound to the terms of the
> > CLA, by obtaining their signature (which may be an equivalent electronic
> > assent)
>
> So just a Signed-off-by? That massively simplifies things!
Well we need to make sure people read CLA and know what
it implies.
Which unfortunately I can not tell you what it is since
CLA at OASIS site is down:
https://www.oasis-open.org/resources/open-repositories/cla/individual-cla
I will reach out to OASIS to figure it out.
> > If you like I can reach out to OASIS to confirm.
>
> Yes, that'd be very helpful, thank you.
>
>
> --
> Manos Pitsidianakis
> Emulation and Virtualization Engineer at Linaro Ltd
next prev parent reply other threads:[~2025-05-19 12:30 UTC|newest]
Thread overview: 13+ 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
2025-03-31 12:14 ` Daniel P. Berrangé
2025-03-31 12:20 ` Stefan Hajnoczi
2025-03-31 11:58 ` Stefan Hajnoczi
2025-03-31 12:36 ` Alex Bennée
2025-05-19 7:43 ` Manos Pitsidianakis
2025-05-19 7:54 ` Michael S. Tsirkin
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 [this message]
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=20250519082712-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 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.