qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Cleber Rosa" <crosa@redhat.com>,
	"Caio Carrara" <ccarrara@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] Acceptance tests: host arch to target arch name mapping
Date: Wed, 17 Oct 2018 16:43:15 -0300	[thread overview]
Message-ID: <20181017194315.GA18379@kermit-br-ibm-com> (raw)
In-Reply-To: <CAFEAcA_gyQvmq48QquNiFhGef-FWPeDKRUSk3wf7hS=_=xm_XQ@mail.gmail.com>

On Wed, Oct 17, 2018 at 07:40:51PM +0100, Peter Maydell wrote:
> On 17 October 2018 at 18:38, Cleber Rosa <crosa@redhat.com> wrote:
> >
> >
> > On 10/17/18 12:29 PM, Eduardo Habkost wrote:
> >> On Wed, Oct 17, 2018 at 01:34:41PM +0100, Peter Maydell wrote:
> >>> So, why does the test code need to care? It's not clear
> >>> from the patch... My expectation would be that you'd
> >>> just test all the testable target architectures,
> >>> regardless of what the host architecture is.
> >>
> >> I tend to agree.  Maybe the right solution is to get rid of the
> >> os.uname().  I think the default should be testing all QEMU
> >> binaries that were built, and the host architecture shouldn't
> >> matter.
>
> Yes, looking at os.uname() also seems like an odd thing
> for the tests to be doing here. The test framework
> should be as far as possible host-architecture agnostic.
> (For some of the KVM cases there probably is a need to
> care, but those are exceptions, not the rule.)
>
> > I'm in favor of exercising all built targets, but that seems to me to be
> > on another layer, above the test themselves. This change is about the
> > behavior of a test when not told about the target arch (and thus binary)
> > it should use.
>
> At that level, I think the right answer is "tell the user
> they need to specify the qemu executable they are trying to test".
> In particular, there is no guarantee that the user has actually
> built the executable for the target that corresponds to the
> host, so it doesn't work to try to default to that anyway.
>
> thanks
> -- PMM
>

I agree with Peter.  We can make qemu_bin parameter mandatory.  If it is not
given, error out.  Trying to guess it based on host architecture turns out to be
troublesome.

If we decide to follow this approach of not guessing QEMU binary, we should
update docs/devel/testing.rst to make it crystal clear qemu_bin parameter is
mandatory.

--
Murilo

  parent reply	other threads:[~2018-10-17 19:43 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16 23:22 [Qemu-devel] [PATCH] Acceptance tests: host arch to target arch name mapping Cleber Rosa
2018-10-17 10:09 ` Philippe Mathieu-Daudé
2018-10-17 16:23   ` Cleber Rosa
2018-10-17 12:34 ` Peter Maydell
2018-10-17 16:29   ` Eduardo Habkost
2018-10-17 17:38     ` Cleber Rosa
2018-10-17 18:40       ` Peter Maydell
2018-10-17 19:05         ` Cleber Rosa
2018-10-17 19:20           ` Peter Maydell
2018-10-17 19:09         ` Eduardo Habkost
2018-10-17 19:25           ` Cleber Rosa
2018-10-17 19:48             ` Eduardo Habkost
2018-10-17 20:54               ` Cleber Rosa
2018-10-17 22:12                 ` Eduardo Habkost
2018-10-17 23:17                   ` Cleber Rosa
2018-10-18  2:02                     ` Eduardo Habkost
2018-10-17 20:46           ` Murilo Opsfelder Araujo
2018-10-17 20:59             ` Cleber Rosa
2018-10-17 22:15               ` Eduardo Habkost
2018-10-17 22:47                 ` Cleber Rosa
2018-10-18  1:54                   ` Eduardo Habkost
2018-10-17 19:43         ` Murilo Opsfelder Araujo [this message]
2018-10-17 20:05           ` Eduardo Habkost
2018-10-17 20:33             ` Wainer dos Santos Moschetta
2018-10-17 21:10               ` Cleber Rosa
2018-10-17 21:34                 ` Eduardo Habkost
2018-10-17 21:16               ` Eduardo Habkost
2018-10-17 21:34                 ` Cleber Rosa
2018-10-17 16:31   ` Cleber Rosa
2018-10-17 16:51     ` Daniel P. Berrangé
2018-10-17 17:46       ` Cleber Rosa
2018-10-17 14:54 ` Wainer dos Santos Moschetta
2018-10-17 18:24   ` Cleber Rosa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181017194315.GA18379@kermit-br-ibm-com \
    --to=muriloo@linux.ibm.com \
    --cc=ccarrara@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).