Re: Central repo for VirtIO conformance tests?

On Mon, May 19, 2025 at 11:15=E2=80=AFAM Michael S. Tsirkin <[email protected]=
> 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=E2=80=AFAM 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 t=
o
> > > > 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 suit=
e
> > > > with multiple VIRTIO implementations including slim images with Lin=
ux
> > > > 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 backen=
ds.
> > > >
> > > > 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 r=
un
> > > > 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 d=
ue
> > > > 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 se=
lection 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 outs=
ide
> > > 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 ele=
ctronic
>         assent)

So just a Signed-off-by? That massively simplifies things!

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

Yes, that'd be very helpful, thank you.


--=20
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd