qemu-devel
[Top][All Lists]
Advanced

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

[RFC PATCH 0/2] hw/s390x: modularize virtio-gpu-ccw


From: Halil Pasic
Subject: [RFC PATCH 0/2] hw/s390x: modularize virtio-gpu-ccw
Date: Tue, 16 Mar 2021 13:26:46 +0100

This series explores Daniels idea he proposed in [1], and
is a successor to the v3.

I decided to go with the RFC tag because there are several
things I have doubts about, and I hope somebody more familiar
with the topic can help me out. I kept running into situations
where meson felt like something I have to cheat and defeat.

One thing that required special attention is keeping things functional
from the build tree (i.e. not requiring an install).  First I failed to
generate a meson output form a custom_target() in a qemu target specific
folder. So I decided to generate scripts that can be used both for
installation and during compilation to massage the build tree so that
goal is accomplished.

The solution for running the scripts as a part of the build is kind of
ugly, because for custom_target() output is mandatory, but my output is
invalid. So I lied.

When I thought, I was done with an RFC quality solution, I tested it from
scratch (deleting my builddir), and it turns out for
meson.add_install_script(script_name) script_name is supposed to be
around, and executable already at configure time. So my generated
scripts won't do because not around in the beginning. I decided to work
that around quick and dirty by introducing a wrapper script.

One alternative to this would be to have the logic in a single script in
the source-tree, and just generate the list of modules for each target,
which would be a parameter of this single script along with the target
name. The downside of this is that we require 2 new in source tree
scripts this way as well, but it is less flexible, because it can't be
used for other generated scripts.

Another thing I'm not really super satisfied with is this
modules_restricted interface, but for my use case it does the job, and
when something new emerges we can re-evaluate.

But before I continue agonizing on these matters, I would like to get
some feedback regarding, is this approach to the problem what the
community wants (or is the whole symlinks idea controversial).

[1] https://mail.gnu.org/archive/html/qemu-s390x/2021-03/msg00206.html

Changelog v3 --> RFC:
* switch to the symlinks approach (Daniel)
* split s390x and common in separate patches (Eduardo)


Halil Pasic (2):
  modules: introduce target specific modules
  hw/s390x: modularize virtio-gpu-ccw

 hw/s390x/meson.build               |  8 +++++-
 include/hw/s390x/css.h             |  7 -----
 include/hw/s390x/s390_flic.h       |  3 +++
 include/qemu/module.h              |  2 ++
 meson.build                        | 43 +++++++++++++++++++++++++++++-
 roms/SLOF                          |  2 +-
 roms/opensbi                       |  2 +-
 scripts/call_generated_script.sh   |  6 +++++
 scripts/modules/target-symlinks.sh | 31 +++++++++++++++++++++
 softmmu/runstate.c                 |  1 +
 target/s390x/cpu.h                 |  9 ++++---
 util/module.c                      | 14 ++++++++--
 12 files changed, 112 insertions(+), 16 deletions(-)
 create mode 100755 scripts/call_generated_script.sh
 create mode 100755 scripts/modules/target-symlinks.sh


base-commit: 2615a5e433aeb812c300d3a48e1a88e1303e2339
-- 
2.25.1




reply via email to

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