Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 31 1月, 2019 1 次提交
    • R
      qemu-io: Add generic function for reinitializing optind. · d339d766
      由 Richard W.M. Jones 提交于 
      On FreeBSD 11.2:

  $ nbdkit memory size=1M --run './qemu-io -f raw -c "aio_write 0 512" $nbd'
  Parsing error: non-numeric argument, or extraneous/unrecognized suffix -- aio_write

After main option parsing, we reinitialize optind so we can parse each
command.  However reinitializing optind to 0 does not work on FreeBSD.
What happens when you do this is optind remains 0 after the option
parsing loop, and the result is we try to parse argv[optind] ==
argv[0] == "aio_write" as if it was the first parameter.

The FreeBSD manual page says:

  In order to use getopt() to evaluate multiple sets of arguments, or to
  evaluate a single set of arguments multiple times, the variable optreset
  must be set to 1 before the second and each additional set of calls to
  getopt(), and the variable optind must be reinitialized.

(From the rest of the man page it is clear that optind must be
reinitialized to 1).

The glibc man page says:

  A program that scans multiple argument vectors,  or  rescans  the  same
  vector  more than once, and wants to make use of GNU extensions such as
  '+' and '-' at  the  start  of  optstring,  or  changes  the  value  of
  POSIXLY_CORRECT  between scans, must reinitialize getopt() by resetting
  optind to 0, rather than the traditional value of 1.  (Resetting  to  0
  forces  the  invocation  of  an  internal  initialization  routine that
  rechecks POSIXLY_CORRECT and checks for GNU extensions in optstring.)

This commit introduces an OS-portability function called
qemu_reset_optind which provides a way of resetting optind that works
on FreeBSD and platforms that use optreset, while keeping it the same
as now on other platforms.

Note that the qemu codebase sets optind in many other places, but in
those other places it's setting a local variable and not using getopt.
This change is only needed in places where we are using getopt and the
associated global variable optind.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>
Message-id: 20190118101114.11759-2-rjones@redhat.com
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
      d339d766
  3. 24 1月, 2019 4 次提交
  5. 22 1月, 2019 1 次提交
  7. 21 1月, 2019 3 次提交
    • D
      sdl: add support for high resolution window icon · a442fe2f
      由 Daniel P. Berrangé 提交于 
      Modern desktop environments can render icons at very large sizes,
especially with high DPI screens. Providing a 32x32 pixel bitmap is
nowhere near sufficient anymore.

When displayed in GNOME shell the QEMU icon looks awful, having been
scaled up to at least x4 its base size. This is compounded by the fact
that the BMP file doesn't do transparency, so while we've removed white
pixels, we still have anti-aliased nearly-white pixels which make the
logo look appalling on black backgrounds.

Loading a high resolution PNG icon addresses both problems, but requires
use of the extra SDL2_image library.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190110120047.25369-4-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      a442fe2f
    • D
      ui: fix icon display for GTK frontend under GNOME Shell with Wayland · 67ea9546
      由 Daniel P. Berrangé 提交于 
      The icon associated with a GtkWindow is just a hint to window managers
and not all of them will honour it. Some will instead want to show the
icon listed by the .desktop file. The desktop file is located based on
the application ID, which is set using g_set_prgname. QEMU has not
historically provided a desktop file or set its app ID, so it got a
broken icon in GNOME shell, which is now fixed.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190110120047.25369-3-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      67ea9546
    • D
      ui: install logo icons to $prefix/share/icons · a8260d38
      由 Daniel P. Berrangé 提交于 
      QEMU currently installs logos to $prefix/share/qemu/ which means no GUI
toolkit or applications can find them by default.

The accepted standards for desktop applications declare that application
logos / icons should be installed under $prefix/share/icons, so use this
directory location.

Pre-rendered icons are provided at the standard sizes expected for GUI
applications, along with the scalable SVG, to ensure maximum portability.

The PNGs are rendered from the SVG using inkscape, however, this is not
wired up into the default make rules to avoid requiring inkscape as a
mandatory tool in build systems / developer workstations.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190110120047.25369-2-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      a8260d38
  9. 18 1月, 2019 2 次提交
  11. 14 1月, 2019 2 次提交
  13. 12 1月, 2019 2 次提交
  15. 11 1月, 2019 1 次提交
  17. 10 1月, 2019 1 次提交
    • M
      configure: bump spice-server required version to 0.12.5 · 1b63665c
      由 Marc-André Lureau 提交于 
      Looking at chardev/spice.c code, I realize compilation was broken for
a while with spice-server < 0.12.3. Let's bump required version
to 0.12.5, released May 19 2014, instead of adding more #ifdef.

(this patch combines changes from an early version and some of
Frediano "[PATCH 2/2] spice: Bump required spice-server version to
0.12.6")

According to repology, all the distros that are build target platforms
for QEMU include it:

      RHEL-7: 0.14.0
      Debian (Stretch): 0.12.8
      Debian (Jessie): 0.12.5
      FreeBSD (ports): 0.14.0
      OpenSUSE Leap 15: 0.14.0
      Ubuntu (Xenial): 0.12.6

Note that a previous version of this patch was bumping version to
0.12.6. Unfortunately, Debian Jessie (oldstable) is stuck with spice
server 0.12.5, and QEMU should keep building until after 2y of current
stable (Stretch), which will be around June 17th 2019. Qemu 4.1
should thus be free of bumping to spice-server 0.12.6 during 4.1
development cycle.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20181128155932.16171-1-marcandre.lureau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      1b63665c
  19. 09 1月, 2019 1 次提交
  21. 08 1月, 2019 1 次提交
  23. 26 12月, 2018 1 次提交
  25. 14 12月, 2018 1 次提交
  27. 12 12月, 2018 3 次提交
    • T
      configure: Remove old -fno-gcse workaround for GCC 4.6.x and 4.7.[012] · d376e9de
      由 Thomas Huth 提交于 
      Now that we require at least GCC 4.8, we don't need this als workaround
for 4.6 and 4.7 anymore.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NThomas Huth <thuth@redhat.com>
      d376e9de
    • T
      configure: Remove obsolete check for Clang < 3.2 · 40f87e26
      由 Thomas Huth 提交于 
      Since we have got a check for Clang >= 3.4 now, we do not need to
check for older Clang versions in the configure test for 128-bit ints
anymore.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NThomas Huth <thuth@redhat.com>
      40f87e26
    • T
      configure: Add a test for the minimum compiler version · efc6c070
      由 Thomas Huth 提交于 
      So far we only had implicit requirements for the minimum compiler version,
e.g. we require at least GCC 4.1 for the support of atomics. However,
such old compiler versions are not tested anymore by the developers, so
they are not really supported anymore. Since we recently declared explicitly
what platforms we intend to support, we can also get more explicit on the
compiler version now. The supported distributions use the following version
of GCC:

      RHEL-7: 4.8.5
      Debian (Stretch): 6.3.0
      Debian (Jessie): 4.8.4
      OpenBSD (ports): 4.9.4
      FreeBSD (ports): 8.2.0
      OpenSUSE Leap 15: 7.3.1
      Ubuntu (Xenial): 5.3.1
      macOS (Homebrew): 8.2.0

So we can safely assume GCC 4.8 these days. For Clang, the situation is
a little bit more ambiguous, since it is sometimes not available in the
main distros but rather third party repositories. At least Debian Jessie
uses version 3.5, and EPEL7 for RHEL7 uses 3.4, so let's use 3.4 as
minimum Clang version now - we still can adjust this later if necessary.

Unfortunately Apple uses different version numbers for the Clang that is
included in their Xcode suite, so we need to check the version numbers
for Xcode separately. Xcode 5.1 seems to be the first one that has been
shipped with LLVM 3.4, so use this version as the minimum there.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Signed-off-by: NThomas Huth <thuth@redhat.com>
      efc6c070
  29. 20 11月, 2018 1 次提交
  31. 13 11月, 2018 1 次提交
  33. 06 11月, 2018 4 次提交
    • P
      configure: Use LINKS loop for all build tree symlinks · 39950353
      由 Peter Maydell 提交于 
      A few places in configure were doing ad-hoc calls to
the symlink function to set up symlinks from the build tree
back to the source tree. We have a loop that does this
already for all files and directories listed in the LINKS
environment variable; use that instead.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      39950353
    • P
      configure: Rename FILES variable to LINKS · e29e5c6e
      由 Peter Maydell 提交于 
      The FILES variable is used to accumulate a list of things to symlink
from the source tree into the build tree.  These don't have to be
individual files; symlinking an entire directory of data files is
also fine.  Rename it to something less confusing before we add a few
directories to it.

Improve the comment to clarify what DIRS and LINKS do and why
it's not a good idea to add things to LINKS with wildcarding.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      e29e5c6e
    • P
      tests: Move tests/hex-loader-check-data/ to tests/data/hex-loader/ · 4b2ff65a
      由 Peter Maydell 提交于 
      Currently tests/hex-loader-check-data contains data files used
by the hexloader-test, and configure individually symlinks those
data files into the build directory using a wildcard.

Using a wildcard like this is a bad idea, because if a new
data file is added, nothing causes configure to be rerun,
and so no symlink is added for the new file. This can cause
tests to spuriously fail when they can't find their data.
Instead, it's better to symlink an entire directory of
data files. We already have such a directory: tests/data.

Move the data files from tests/hex-loader-check-data/ to
tests/data/hex-loader/, and remove the unnecessary symlinking.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      4b2ff65a
    • P
      tests: Move tests/acpi-test-data/ to tests/data/acpi/ · 438c78da
      由 Peter Maydell 提交于 
      Currently tests/acpi-test-data contains data files used by the
bios-tables-test, and configure individually symlinks those
data files into the build directory using a wildcard.

Using a wildcard like this is a bad idea, because if a new
data file is added, nothing causes configure to be rerun,
and so no symlink is added for the new file. This can cause
tests to spuriously fail when they can't find their data.
Instead, it's better to symlink an entire directory of
data files. We already have such a directory: tests/data.

Move the data files from tests/acpi-test-data/ to
tests/data/acpi/, and remove the unnecessary symlinking.

We can remove entirely the note in rebuild-expected-aml.sh
about copying any new data files, because now they will
be in the source directory, not the build directory, and
no copying is required.

(We can't just change the existing tests/acpi-test-data/
to being a symlinked directory, because if we did that and
a developer switched git branches from one after that change
to one before it then configure would end up trashing all
the test files by making them symlinks to themselves.
Changing their path avoids this annoyance.)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      438c78da
  35. 31 10月, 2018 2 次提交
  37. 26 10月, 2018 2 次提交
  39. 24 10月, 2018 1 次提交
  41. 20 10月, 2018 1 次提交
  43. 19 10月, 2018 4 次提交