From: "Daniel P. Berrangé" <berrange@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Bernhard Beschow" <shentey@gmail.com>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
qemu-ppc@nongnu.org,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [PATCH 4/5] configure: Add dtc option
Date: Wed, 11 Jun 2025 09:45:26 +0100 [thread overview]
Message-ID: <aElCJnmjrB-X9M-n@redhat.com> (raw)
In-Reply-To: <cdfc561e-23a9-607a-d9a8-70e07e73e0fd@eik.bme.hu>
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
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.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-06-11 8:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 20:41 [PATCH 0/5] DTB build housekeeping Bernhard Beschow
2025-06-10 20:41 ` [PATCH 1/5] hw: Fix type constant for DTB files Bernhard Beschow
2025-06-11 10:31 ` Thomas Huth
2025-06-10 20:41 ` [PATCH 2/5] pc-bios/dtb/meson: Prefer target name to be outfile, not infile Bernhard Beschow
2025-06-11 10:38 ` Thomas Huth
2025-06-10 20:41 ` [PATCH 3/5] scripts/meson-buildoptions: Sort coroutine_backend choices lexicographically Bernhard Beschow
2025-06-11 0:37 ` BALATON Zoltan
2025-06-11 10:40 ` Thomas Huth
2025-06-11 12:59 ` Kohei Tokunaga
2025-06-10 20:41 ` [PATCH 4/5] configure: Add dtc option Bernhard Beschow
2025-06-11 0:37 ` BALATON Zoltan
2025-06-11 8:45 ` Daniel P. Berrangé [this message]
2025-06-11 11:45 ` BALATON Zoltan
2025-06-12 5:12 ` Paolo Bonzini
2025-06-12 5:46 ` Paolo Bonzini
2025-06-12 21:27 ` Bernhard Beschow
2025-06-12 12:39 ` BALATON Zoltan
2025-06-10 20:41 ` [PATCH 5/5] configure: Require dtc for boards with bundled device trees Bernhard Beschow
2025-06-12 6:09 ` [PATCH 0/5] DTB build housekeeping Paolo Bonzini
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=aElCJnmjrB-X9M-n@redhat.com \
--to=berrange@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=edgar.iglesias@gmail.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=shentey@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.