Re: [XEN][PATCH] common/libfdt: optimize usage

[Grygorii Strashko <grygorii_strashko@xxxxxxxx>]

Hi

On 14.11.25 20:01, Grygorii Strashko wrote:
> From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
>
> Now all libfdt features are built-it unconditionally, but...
>
> X86: The libfdt is used on x86 only to parse Hyperlaunch/dom0less Xen
> nodes, so full libfdt is not needed in this case and minimal, RO
> configuration can be used.
>
> ARM - situation is more complicated:
> 1) ARM reads Host DT (fdt.c RO)
> 2) ARM reads passthrough DT (RO)
> 3) ARM generates dom0/hwdom DT from Host DT (there is a mix of WIP and SW APIs)
> 4) ARM generates domU DT (there is a mix of WIP and SW APIs)
> 4) With EFI enabled - ARM needs RW API and fdt_empty_tree
> 5) With CONFIG_OVERLAY_DTB - ARM needs RW and fdt_overlay API
>
> Hence, add possibility for optimizing libfdt usage by introducing separate
> Kconfig options for each libfdt feature and select them where needed.
>
> Following libfdt modules are not used after this change:
>   Makefile.libfdt
>   fdt_addresses.c
>   fdt_strerror.c
>   fdt_check.c
>
> Signed-off-by: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
> ---
> Not sure about using DOMAIN_BUILD_HELPERS for selecting
> LIBFDT features, as DOMAIN_BUILD_HELPERS doesn't exactly
> says that domain's DT will be generated when selected.
>
>   xen/arch/arm/Kconfig       |  4 ++++
>   xen/common/Kconfig         |  4 ++++
>   xen/common/libfdt/Kconfig  | 14 ++++++++++++++
>   xen/common/libfdt/Makefile | 12 +++++++++---
>   4 files changed, 31 insertions(+), 3 deletions(-)
>   create mode 100644 xen/common/libfdt/Kconfig
Before continue Kconfig related discussion...

I've been thinking what if we use libfdt as a library (.a)?
We'd get the same result as linker can do optimization basing
on obj granularity while linking with library (.a).

OK. I've started experimenting - obvious choice is to use "lib-y" and
build system will do the rest. But in this case we'll lose ".init" and
libfdt will be built-in.

I've tried to preserve exiting behavior when libfdt is moved in ".init", but,
honestly got lost a bit in Xen build system.

Below diff is what I've came up with - probably no exactly right.

Does it make sense?

diff --git a/xen/Makefile b/xen/Makefile
index a4d53526bd0b..3fb77ab19853 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -464,6 +464,7 @@ ALL_OBJS-y                += arch/$(SRCARCH)/built_in.o
 ALL_OBJS-$(CONFIG_CRYPTO) += crypto/built_in.o
 
 ALL_LIBS-y                := lib/lib.a
+ALL_LIBS-$(CONFIG_LIBFDT) += common/libfdt/libfdt.a
 
 include $(srctree)/arch/$(SRCARCH)/arch.mk
 
 $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y): _c_flags += $(cov-cflags-y)
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index 6ce679f98f47..e315252c88eb 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -1,21 +1,28 @@
-include $(src)/Makefile.libfdt
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
 
+obj-libfdt-y := fdt.o fdt_ro.o
+obj-libfdt-y += fdt_wip.o
+obj-libfdt-y += fdt_sw.o
+obj-libfdt-y += fdt_rw.o
+obj-libfdt-y += fdt_empty_tree.o
+obj-libfdt-y += fdt_overlay.o
+
 # For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during runtime.
 ifneq ($(CONFIG_OVERLAY_DTB),y)
 OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
-nocov-y += libfdt.o
+nocov-y += $(obj-libfdt-y)
 endif
 
-obj-y += libfdt.o
-
 CFLAGS-y += -I$(srctree)/include/xen/libfdt/
 
-$(obj)/libfdt.o: $(obj)/libfdt-temp.o FORCE
-       $(call if_changed,objcopy)
+#lib-y += $(obj-libfdt-y)
 
-$(obj)/libfdt-temp.o: $(addprefix $(obj)/,$(LIBFDT_OBJS)) FORCE
-       $(call if_changed,ld)
+$(obj)/libfdt-temp.a: $(addprefix $(obj)/,$(obj-libfdt-y)) FORCE
+       $(call if_changed,ar)
+
+$(obj)/libfdt.a: $(obj)/libfdt-temp.a FORCE
+       $(call if_changed,objcopy)
 
-targets += libfdt-temp.o $(LIBFDT_OBJS)
+extra-y += libfdt.a $(obj-libfdt-y)
+targets += libfdt-temp.a $(obj-libfdt-y)

--
Best regards,
-grygorii