From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Ani Sinha <anisinha@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] acpi/tests/bios-tables-test: add an environment variable for iasl location
Date: Wed, 17 May 2023 12:07:55 -0400 [thread overview]
Message-ID: <20230517120710-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <87r0rflzd4.fsf@linaro.org>
On Wed, May 17, 2023 at 04:58:06PM +0100, Alex Bennée wrote:
>
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > On Wed, May 17, 2023 at 04:16:47PM +0100, Alex Bennée wrote:
> >>
> >> Ani Sinha <anisinha@redhat.com> writes:
> >>
> >> >> On 17-May-2023, at 8:06 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >>
> >> >> On Wed, May 17, 2023 at 07:57:53PM +0530, Ani Sinha wrote:
> >> >>>
> >> >>>
> >> >>>> On 17-May-2023, at 7:47 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> >>>>
> >> >>>> On Wed, May 17, 2023 at 05:37:51PM +0530, Ani Sinha wrote:
> >> >>>>> Currently the meson based QEMU build process locates the iasl binary from the
> >> >>>>> current PATH and other locations [1] and uses that to set CONFIG_IASL which is
> >> >>>>> then used by the test.
> >> >>>>>
> >> >>>>> This has two disadvantages:
> >> >>>>> - If iasl was not previously installed in the PATH, one has to install iasl
> >> >>>>> and rebuild QEMU in order to pick up the iasl location. One cannot simply
> >> >>>>> use the existing bios-tables-test binary because CONFIG_IASL is only set
> >> >>>>> during the QEMU build time by meson and then bios-tables-test has to be
> >> >>>>> rebuilt with CONFIG_IASL set in order to use iasl.
> >>
> >> Usually we work the other way by checking at configure time and skipping
> >> the feature if the prerequisites are not in place. We do this with gdb:
> >>
> >> ../../configure --gdb=/home/alex/src/tools/binutils-gdb.git/builds/all/install/bin/gdb
> >>
> >> which checks gdb is at least new enough to support the features we need:
> >>
> >> if test -n "$gdb_bin"; then
> >> gdb_version=$($gdb_bin --version | head -n 1)
> >> if version_ge ${gdb_version##* } 9.1; then
> >> echo "HAVE_GDB_BIN=$gdb_bin" >> $config_host_mak
> >> gdb_arches=$("$source_path/scripts/probe-gdb-support.py" $gdb_bin)
> >> else
> >> gdb_bin=""
> >> fi
> >> fi
> >>
> >> >>>>> - Sometimes, the stock iasl that comes with distributions is simply not good
> >> >>>>> enough because it does not support the latest ACPI changes - newly
> >> >>>>> introduced tables or new table attributes etc. In order to test ACPI code
> >> >>>>> in QEMU, one has to clone the latest acpica upstream repository and
> >> >>>>> rebuild iasl in order to get support for it. In those cases, one may want
> >> >>>>> the test to use the iasl binary from a non-standard location.
> >>
> >> I think configure should be checking if iasl is new enough and reporting
> >> to the user at configure time they need to do something different. We
> >> don't want to attempt to run tests that will fail unless the user has
> >> added the right magic to their environment.
> >
> > iasl is a disassembler we trigger for user convenience in case tests
> > fail. It will never cause tests to fail.
>
> Fair enough. But I still think the place to report it is in configure.
> Maybe something like:
>
> iasl : /usr/bin/iasl (version 20200925, might not handle all ACPI)
>
> in the Host Binaries section. Re-configuring shouldn't cause too much of
> the build to be regenerated although we could certainly do better in
> this regard.
won't all of it be regenerated? a header everyone includes changes.
--
MST
next prev parent reply other threads:[~2023-05-17 16:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 12:07 [PATCH] acpi/tests/bios-tables-test: add an environment variable for iasl location Ani Sinha
2023-05-17 14:17 ` Michael S. Tsirkin
2023-05-17 14:27 ` Ani Sinha
2023-05-17 14:36 ` Michael S. Tsirkin
2023-05-17 14:49 ` Ani Sinha
2023-05-17 15:16 ` Alex Bennée
2023-05-17 15:25 ` Michael S. Tsirkin
2023-05-17 15:58 ` Alex Bennée
2023-05-17 16:07 ` Michael S. Tsirkin [this message]
2023-05-17 16:20 ` Alex Bennée
2023-05-18 6:01 ` Ani Sinha
2023-05-18 10:40 ` Michael S. Tsirkin
2023-05-18 11:01 ` Ani Sinha
2023-05-19 17:13 ` Paolo Bonzini
2023-05-20 7:25 ` Ani Sinha
2023-05-20 9:36 ` Paolo Bonzini
2023-05-20 15:13 ` Ani Sinha
2023-05-22 10:21 ` Paolo Bonzini
2023-05-18 11:19 ` Ani Sinha
2023-05-18 6:11 ` Ani Sinha
2023-05-17 15:48 ` Ani Sinha
2023-05-17 16:07 ` Alex Bennée
2023-05-17 16:43 ` Bernhard Beschow
2023-05-18 5:55 ` Ani Sinha
2023-05-18 10:27 ` Michael S. Tsirkin
2023-05-21 8:54 ` Michael S. Tsirkin
2023-05-21 14:51 ` Ani Sinha
2023-05-22 10:34 ` Ani Sinha
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=20230517120710-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=anisinha@redhat.com \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).