On Sat, Oct 22, 2022 at 22:05 Michael S. Tsirkin <m...@redhat.com> wrote:
> On Sat, Oct 22, 2022 at 06:28:32AM +0530, Ani Sinha wrote: > > > > > > On Fri, Oct 21, 2022 at 21:32 Alex Bennée <alex.ben...@linaro.org> > wrote: > > > > > > Ani Sinha <a...@anisinha.ca> writes: > > > > > On Fri, 21 Oct, 2022, 5:52 pm Ani Sinha, <a...@anisinha.ca> wrote: > > > > > > On Fri, 21 Oct, 2022, 5:26 pm Alex Bennée, < > alex.ben...@linaro.org> > > wrote: > > > > > > Ani Sinha <a...@anisinha.ca> writes: > > > > > > > On Fri, Oct 21, 2022 at 3:10 PM Michael S. Tsirkin < > m...@redhat.com> > > wrote: > > > >> > > > >> On Fri, Oct 21, 2022 at 10:30:09AM +0100, Alex Bennée wrote: > > > >> > > > > >> > Ani Sinha <a...@anisinha.ca> writes: > > > >> > > > > >> > > On Fri, Oct 21, 2022 at 2:02 PM Michael S. Tsirkin < > > m...@redhat.com> wrote: > > > >> > >> > > > >> > >> On Fri, Oct 21, 2022 at 05:45:15AM +0530, Ani Sinha wrote: > > > >> > >> > And have multiple platform specific branches in bits > that have > > fixes for those > > > >> > >> > platforms so that bits can run there. Plus the existing > test > > can be enhanced to > > > >> > >> > pull in binaries from those branches based on the > platform on > > which it is being > > > >> > >> > run. > > > >> > >> > > > > >> > >> > > > >> > >> What a mess. > > > >> > >> Who is going to be testing all these million platforms? > > > >> > > > > > >> > > I am not talking about branches in QEMU but branches in > bits. > > > >> > > If you are going to test multiple platforms, you do need > to build > > bits > > > >> > > binaries for them. There is no way around it. > > > >> > > bits is not all platform independent python. It does have > binary > > executables. > > > >> > > > > > >> > > Currently bits is built only for the x86 platform. Other > > platforms are > > > >> > > not tested. I doubt if anyone even tried building bits for > arm or > > > >> > > mips. > > > >> > > > > >> > I'm not worried about test bits on other targets, but we do > run x86 > > > >> > targets on a number of hosts. The current reliance on a > special > > patched > > > >> > host build tool for only one architecture is the problem. > If we > > just > > > >> > download the iso that problem goes away. > > > >> > > > >> 👍what he said. > > > > > > > > Yes, in that case the problem is that upstream bits does not > pass all > > > > the test out of the box. Hence we are taking this approach of > keeping > > > > some test scripts in QEMU repo and modifying them. Then > generating the > > > > iso with the modified scripts. It also helps developers who > want to > > > > write new tests or make enhancements to existing tests. > > > > If modifications need to be made to tests, they need to be > versioned. > > > > We have gone through the route of not using submodules and I am > not > > > > going to open that can of worms again. > > > > > > We have added a mirror of biosbits to the QEMU project so there > is no > > > reason why we can't track changes and modifications there (we do > this > > > for TestFloat which is forked from the upstream SoftFloat code). > > > > > > One last option. Commit this patch set but also double commit patch 3 to > the > > bits repo so that we can build an iso that would successfully run all > tests for > > a separate platform independent test to be written later. > > > > Then we will have two tests: > > > > - this one for developers writing new test. > > - platform independent one for a basic sanity. > > > > I’m just documenting the fact that I have proposed ideas that can work > where > > all can be happy. It’s up to others to take it or keep objecting and > killing > > motivations for freelance contributors. > > I think it's ok to apply this as is for starters. > Anyone has objections? > > Down the road I think things should be refactored slightly to work as > follows: > - test developers can check out biosbits repo to create the iso > - everyone else gets iso downloaded It will be difficult to convince test developers to check out another repo and go back and forth between two repos. If the bits repo was a sub module that’s another story. Test developers should use the test scripts from qemu repo. Someone then later can incrementally commit these new tests into bits repo and generate newer iso at some periodic intervals. Since I am the maintainer of the bits repo I can do the second part. > > Objections to this plan? > > > > > > > > > > > > > > > > > >
