qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 01/11] acpi/tests/bits: initial commit of test scripts tha


From: Ani Sinha
Subject: Re: [PATCH v2 01/11] acpi/tests/bits: initial commit of test scripts that are run by biosbits
Date: Tue, 12 Jul 2022 21:08:46 +0530 (IST)
User-agent: Alpine 2.22 (DEB 394 2020-01-19)


On Tue, 12 Jul 2022, John Snow wrote:

> On Tue, Jul 12, 2022, 3:17 AM Ani Sinha <ani@anisinha.ca> wrote:
>
> >
> >
> > On Mon, 11 Jul 2022, John Snow wrote:
> >
> > > On Sun, Jul 10, 2022 at 1:01 PM Ani Sinha <ani@anisinha.ca> wrote:
> > > >
> > > > This is initial commit of cpuid, acpi and smbios python test scripts
> > for
> > > > biosbits to execute. No change has been made to them from the original
> > code
> > > > written by the biosbits author Josh Triplett. They are required to be
> > installed
> > > > into the bits iso file and then run from within the virtual machine
> > booted off
> > > > with biosbits iso.
> > > >
> > > > The original location of these tests are here:
> > > > https://github.com/biosbits/bits/blob/master/python/testacpi.py
> > > > https://github.com/biosbits/bits/blob/master/python/smbios.py
> > > > https://github.com/biosbits/bits/blob/master/python/testcpuid.py
> > > >
> > > > Signed-off-by: Ani Sinha <ani@anisinha.ca>
> > > > ---
> > > >  tests/pytest/acpi-bits/bits-tests/meson.build |   11 +
> > > >  tests/pytest/acpi-bits/bits-tests/smbios.py   | 2430 +++++++++++++++++
> > > >  tests/pytest/acpi-bits/bits-tests/testacpi.py |  283 ++
> > > >  .../pytest/acpi-bits/bits-tests/testcpuid.py  |   83 +
> > > >  4 files changed, 2807 insertions(+)
> > > >  create mode 100644 tests/pytest/acpi-bits/bits-tests/meson.build
> > > >  create mode 100644 tests/pytest/acpi-bits/bits-tests/smbios.py
> > > >  create mode 100644 tests/pytest/acpi-bits/bits-tests/testacpi.py
> > > >  create mode 100644 tests/pytest/acpi-bits/bits-tests/testcpuid.py
> > > >
> > > > diff --git a/tests/pytest/acpi-bits/bits-tests/meson.build
> > b/tests/pytest/acpi-bits/bits-tests/meson.build
> > > > new file mode 100644
> > > > index 0000000000..3056731a53
> > > > --- /dev/null
> > > > +++ b/tests/pytest/acpi-bits/bits-tests/meson.build
> > > > @@ -0,0 +1,11 @@
> > > > +test_files = ['smbios.py', 'testacpi.py', 'testcpuid.py']
> > > > +
> > > > +copytestfiles = custom_target('copy test files',
> > > > +  input : test_files,
> > > > +  output :  test_files,
> > > > +  command : ['cp', '@INPUT@', '@OUTDIR@'],
> > > > +  install : true,
> > > > +  install_dir : 'bits-tests',
> > > > +  build_by_default : true)
> > > > +
> > > > +other_deps += copytestfiles
> > > > diff --git a/tests/pytest/acpi-bits/bits-tests/smbios.py
> > b/tests/pytest/acpi-bits/bits-tests/smbios.py
> > > > new file mode 100644
> > > > index 0000000000..9667d0542c
> > > > --- /dev/null
> > > > +++ b/tests/pytest/acpi-bits/bits-tests/smbios.py
> > > > @@ -0,0 +1,2430 @@
> > > > +# Copyright (c) 2015, Intel Corporation
> > > > +# All rights reserved.
> > > > +#
> > > > +# Redistribution and use in source and binary forms, with or without
> > > > +# modification, are permitted provided that the following conditions
> > are met:
> > > > +#
> > > > +#     * Redistributions of source code must retain the above
> > copyright notice,
> > > > +#       this list of conditions and the following disclaimer.
> > > > +#     * Redistributions in binary form must reproduce the above
> > copyright notice,
> > > > +#       this list of conditions and the following disclaimer in the
> > documentation
> > > > +#       and/or other materials provided with the distribution.
> > > > +#     * Neither the name of Intel Corporation nor the names of its
> > contributors
> > > > +#       may be used to endorse or promote products derived from this
> > software
> > > > +#       without specific prior written permission.
> > > > +#
> > > > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > "AS IS" AND
> > > > +# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> > THE IMPLIED
> > > > +# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> > ARE
> > > > +# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> > BE LIABLE FOR
> > > > +# ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > CONSEQUENTIAL DAMAGES
> > > > +# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> > SERVICES;
> > > > +# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > CAUSED AND ON
> > > > +# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> > TORT
> > > > +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > USE OF THIS
> > > > +# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > > > +
> > > > +"""SMBIOS/DMI module."""
> > > > +
> > > > +import bits
> > > > +import bitfields
> > >
> > > New deps?
> > >
> > > > +import ctypes
> > > > +import redirect
> > >
> > > Also a new dep?
> > >
> > > > +import struct
> > > > +import uuid
> > > > +import unpack
> > >
> > > And another?
> > >
> > > > +import ttypager
> > > > +import sys
> > >
> > > What's the proposed strategy for dependency management for these
> > > tests? I know there's some mail I'm backlogged on ...
> > >
> >
> > For some reason I did not need to add those libraries as dependencies. If
> > needed we can add them in requirements.txt for pyenv.
> >
>
> Probably pulled in as deps to what you do install; pinning them may be
> helpful for repeatability reasons and to avoid playing whackamole with new
> pypi releases during the rc testing phase - speaking from experience with
> the other python test packages in the tree.


Actually wait, I completely forgot something. These test scrips are run
*inside* bios-bits VM, That is, we need not worry about ensuring the
availability of these libraries and the deps they introduce ourselves.
Bios bits takes care of it. It is a software written and maintained
outside of QEMU.

The only python script whose deps we need to worry about is the one I
wrote myself - acpi-bits-test.py .

>
> That said, explicitly enumerating all of the deps is also a costly
> maintenance activity, so ... YMMV.
>
> It depends on how fastidiously the main requirements you state manage their
> own sub deps. Some projects do it well, some don't.
>
> Just something to consider.
>
> --js
>
> >
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]