On 2/9/21 1:52 PM, Alex Bennée wrote: > Max Reitz <mre...@redhat.com> writes: >> On 09.02.21 12:24, Alex Bennée wrote: >>> Max Reitz <mre...@redhat.com> writes: >>>> On 04.02.21 14:23, Alex Bennée wrote: >>>>> Cleber Rosa <cr...@redhat.com> writes: >>>>> ... >>>> Ideally, vmlinuz='' would be the default, but there’s a problem with >>>> that: I submitted this test along with the patches that added the >>>> required feature to the Linux kernel, so at that point that feature was >>>> not part of Linux. That’s why you generally have to point it to a Linux >>>> kernel binary you built yourself that has this feature (5.10 does). >>> >>> This is where it deviates from the rest of the check-acceptance tests. >>> Generally I don't have to worry about finding the right image myself. >> >> Yes, but there’s nothing I can do apart from just not having the test as >> part of qemu, which I don’t find better than to just cancel it when not >> run with the necessary parameters. > > No I agree having the tests is useful. > >> >> Or, well, I could let the test download and compile the Linux sources, >> but I don’t think that’s a viable alternative. > > There has been discussion before but I agree it's not viable given the > compile times for such things. > >>> At the least it would be worth pointing to a part of our docs on how >>> to build such an image. >> >> Well, I could perhaps come up with a comprehensive kernel configuration >> that works, but I really don’t think that’s valuable for people who just >> want to run the acceptance tests and don’t care about this test in >> particular. I just don’t think they’re actually going to build a Linux >> kernel just for it. > > Sure - but I was trying to review the series and as part of my review I > generally like to run the things I review. Hence why I stopped as I > couldn't get things running. > >> (Alternatively, I could just build a Linux kernel here on my machine, >> upload the binary and point to it somewhere, e.g. in the cancel message. >> That would be OK for me, and perhaps something I could imagine someone >> might actually use.) > > I've actually done this with some Xen patches I'm working on at the > moment. I'll probably decorate the test with: > > @skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted code') > > with a comment explaining what's waiting to be upstreamed. Once there > are upstream binaries I plan on transitioning the test to those.
Instead of a binary AVOCADO_ALLOW_UNTRUSTED_CODE variable, we could have a list allowed domains/namespaces, that can be increased on the tester discretion. For example these are assumed trusted: . archives.fedoraproject.org . archive.debian.org . cdn.netbsd.org . github.com/torvalds . people.debian.org/~aurel32 . snapshot.debian.org . storage.kernelci.org . www.qemu-advent-calendar.org Then personally interested in testing ARM boards I'd amend: . apt.armbian.com . github.com/philmd . github.com/groeck . github.com/hskinnemoen . github.com/pbatard and Max's repo since I'm interested in testing virtiofs_submounts.