On Thu, 12 Jun 2025, Paolo Bonzini wrote:
On 6/11/25 13:45, BALATON Zoltan wrote:
On Wed, 11 Jun 2025, Daniel P. Berrangé wrote:
On Wed, Jun 11, 2025 at 02:37:08AM +0200, BALATON Zoltan wrote:
On Tue, 10 Jun 2025, Bernhard Beschow wrote:
The next patch will make dtc mandatory for boards with a bundled DTB,
causing
these boards to be omitted when dtc is missing. Allow packagers to force
the
build of those boards by providing an option.
I don't like this. This might result in some machines missing from some
distros if they don't notice this and forget to update their packages and
these are machines I care about.
"Someone might not notice & screw up" is pretty much an argument for
not doing anything at all. We publish release notes to alert distros
More like "if it ain't broke don't fix it".
to these kind of changes which is a reasonable effort on our part.
Distros need to play their part by reading them and adapting to the
changes. They can also compare the available options with new and
old QEMU to identify any new build features they need to handle when
updating.
Also what guarantees that we don't get
bugs
by compiling the device tree with different dtc versions which might
generate different binaries? The binaries we have now are known to work
and
don't take much space so keeping them for convenience might be simpler.
If
it worked so far why change it now?
Ultimately the DTC project has responsibility to not cause regressions
in new releases they issue, as is the case for any 3rd party dep that
we rely on.
We have CI jobs that can run on different distros. If we have coverage
of the boards in functional test suite that provides a way to validate the
operation with differing DTC versions as a sanity check.
Distributing pre-built binaries in source release tarballs is a long
standing issue with QEMU's releases. If we can eliminate the pre-bbuilt
DTB and only ship the source that is a good thing IMHO.
If this was using dtc from the submodule when not using system libfdt
then
at least it would not result in dropped machines and we had a known
working
dtc to compile with. Why isn't that used when we already have it for
libfdt?
Are there any platforms that we target which still lack dtc ? The
submodule was there to plug gaps in distro support long ago, but
if every distro has dtc available the submodule is redundant.
OK, can we then make libfdt and dtc mandatory and not build at all instead
of disabling boards without it?
Disabling libfdt was done because of the x86 microvm board, which was adding
a libfdt dependency to all of qemu-system-x86_64.
However, several targets still have a hard dependency on libfdt, plus libfdt
is supported as a subproject and will be built together with the emulators.
So the impact of the change was minimal, and limited only to people using
--disable-libfdt or --disable-download on the configure command line. This
is not true of Bernard's proposal to use dtc.
For now, one possibility is just to make dtc mandatory whenever one of this
boards is used; the best would be to be able to use the dtc that comes from
the libfdt subproject. This however requires patching dtc's meson.build so
that it calls meson.override_find_program (and it could also use
meson.override_dependency while you're at it).
I'll send a patch to the upstream dtc project and you can add it to QEMU via
diff_files (see commit 64644bc4eab2f for an example).
This seems getting too complicated just to get rid of some small binaries
so I'd just leave it as it is now but if Bernhard wants to make this
change I'm OK with it as long as my boards won't get disabled in configs
where now they are built I.e. if no system dtc is found now the dtbs are
installed; if this used dtc from submodule instead that would be OK but
dropping the board is not. I'm also OK with replacing the submodule with
always requiring system libfdt and dtc but that may be more work for
distros to update their package dependencies.
Regards,
BALATON Zoltan
