system/device_tree-stub.c

#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qapi/qapi-commands-machine.h"

#ifdef CONFIG_FDT
void qmp_dumpdtb(const char *filename, Error **errp)
{
    ERRP_GUARD();

    error_setg(errp, "This machine doesn't have an FDT");
    error_append_hint(errp, "(this machine type definitely doesn't use FDT)\n");
}
#endif
kconfig: allow compiling out QEMU device tree code per target Introduce a new Kconfig symbol, CONFIG_DEVICE_TREE, that specifies whether to include the common device tree code in system/device_tree.c and to link to libfdt. For now, include it unconditionally if libfdt is available. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2024-05-07 14:13:46 +02:00			`#include "qemu/osdep.h"`
			`#include "qapi/error.h"`
			`#include "qapi/qapi-commands-machine.h"`

			`#ifdef CONFIG_FDT`
			`void qmp_dumpdtb(const char filename, Error *errp)`
			`{`
hw/core/machine.c: Make -machine dumpdtb=file.dtb with no DTB an error Currently if the user requests via -machine dumpdtb=file.dtb that we dump the DTB, but the machine doesn't have a DTB, we silently ignore the option. This is confusing to users, and is a legacy of the old board-specific implementation of the option, where if the execution codepath didn't go via a call to qemu_fdt_dumpdtb() we would never handle the option. Now we handle the option in one place in machine.c, we can provide the user with a useful message if they asked us to dump a DTB when none exists. qmp_dumpdtb() already produces this error; remove the logic in handle_machine_dumpdtb() that was there specifically to avoid hitting it. While we're here, beef up the error message a bit with a hint, and make it consistent about "an FDT" rather than "a FDT". (In the qmp_dumpdtb() case this needs an ERRP_GUARD to make error_append_hint() work when the caller passes error_fatal.) Note that the three places where we might report "doesn't have an FDT" are hit in different situations: (1) in handle_machine_dumpdtb(), if CONFIG_FDT is not set: this is because the QEMU binary was built without libfdt at all. The build system will not let you build with a machine type that needs an FDT but no libfdt, so here we know both that the machine doesn't use FDT and that QEMU doesn't have the support: (2) in the device_tree-stub.c qmp_dumpdtb(): this is used when we had libfdt at build time but the target architecture didn't enable any machines which did "select DEVICE_TREE", so here we know that the machine doesn't use FDT. (3) in qmp_dumpdtb(), if current_machine->fdt is NULL all we know is that this machine never set it. That might be because it doesn't use FDT, or it might be because the user didn't pass an FDT on the command line and the machine doesn't autogenerate an FDT. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2733 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250206151214.2947842-7-peter.maydell@linaro.org 2025-02-06 15:12:14 +00:00			`ERRP_GUARD();`

			`error_setg(errp, "This machine doesn't have an FDT");`
			`error_append_hint(errp, "(this machine type definitely doesn't use FDT)\n");`
kconfig: allow compiling out QEMU device tree code per target Introduce a new Kconfig symbol, CONFIG_DEVICE_TREE, that specifies whether to include the common device tree code in system/device_tree.c and to link to libfdt. For now, include it unconditionally if libfdt is available. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 2024-05-07 14:13:46 +02:00			`}`
			`#endif`