Re: Central repo for VirtIO conformance tests?

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 <[email protected]> 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)

If you like I can reach out to OASIS to confirm.

> > You can still use e.g. virtio-dev mailing list for communication.
> >
> > > --
> > > Manos Pitsidianakis
> > > Emulation and Virtualization Engineer at Linaro Ltd
> >