> On Jul 30, 2020, at 4:32 AM, Andrew Jones <drjones@xxxxxxxxxx> wrote: > > On Thu, Jul 30, 2020 at 07:50:39AM +0000, Nadav Amit wrote: >>> On Jul 30, 2020, at 12:35 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> >>> On 30/07/20 09:13, Wanpeng Li wrote: >>>>>> I personally dislike renames as you will have old references lurking in >>>>>> the internet for decades. A rename will result in people continue to using >>>>>> the old code because the old name is the only thing that they know. >>>>> >>>>> +1 for keeping the old name. >>>>> >>>>> cpu-unit-tests might also not be completely fitting (I remember we >>>>> already do test, or will test in the future I/O stuff like PCI, CCW, ...). >>>>> >>>>> IMHO, It's much more a collection of tests to verify >>>>> architecture/standard/whatever compliance (including paravirtualized >>>>> interfaces if available). >>> >>> Good point. >>> >>>> Vote for keeping the old name. >>> >>> Ok, so either old name or alternatively arch-unit-tests? But the >>> majority seems to be for kvm-unit-tests, and if Nadav has no trouble >>> contributing to them I suppose everyone else can too. >> >> Indeed. My employer (VMware) did not give me hard time (so far) in >> contributing to the project just because it has KVM in its name. We (VMware) >> also benefit from kvm-unit-tests, and Paolo and others were receptive to >> changes that I made to make it more kvm/qemu -independent. This is what >> matters. >> >> So I am ok with the name being kvm-unit-tests. But I would ask/recommend >> that the project description [1] be updated to reflect the fact that the >> project is hypervisor-agnostic. > > Good idea. Although while I authored what you see there, I don't really > want to sign up to do all the writing. How about when we create the gitlab > project we also create a .md file that we redirect [1] to? Then anybody > can submit patches for it going forward. Fine with me. Right now the README.md pretty much redirects to [1] in regard to the project definition. >> This should have practical implications. I remember, for example, that I had >> a discussion with Paolo in the past regarding “xpass” being reported as a >> failure. The rationale was that if a test that is expected to fail on KVM >> (since KVM is known to be broken) surprisingly passes, there is some problem >> that should be reported as a failure. I would argue that if the project is >> hypervisor-agnostic, “xpass” is not a failure. > > We can use compile-time or run-time logic that depends on the target to > decide whether a test should be a normal test (pass/fail) or an > xpass/xfail test. This is simple. When I find some time, I will send some patches for that. Regards, Nadav
