[PATCH 0/5] api: Deprecate the API
From: Simon Glass <sjg@chromium.org> The existing U-Boot API is quite old and doesn't support driver model. Adding new functions is a manual process and no one has attempted this in the 10 years that driver model has been present. Undertaking such a task would be laborious and would require continued effort to maintain. A better approach would be to create a library containing all of U-Boot, then have the API be generated by a script from a list of functions. This would allow for a more flexible and maintainable interface. In preparation for this new direction, this series renames the existing API components to clearly mark them as legacy: - Rename api/ to legacy_api/ - Rename examples/api/ to examples/legacy_api/ - Rename include/api.h and include/api_public.h to include/legacy_api*.h - Rename API_BUILD to LEGACY_API_BUILD - Rename CONFIG_API to CONFIG_LEGACY_API - Rename api_init() to legacy_api_init() This provides a clean namespace for implementing the new library-based API approach while maintaining backward compatibility for existing users of the legacy interface. This series also sets a deadline for removal of the legacy API. Simon Glass (5): api: Rename legacy API files and examples api: Rename the api/ directory Kconfig: Rename API to LEGACY_API api: Rename api_init() to legacy_api_init() doc: api: Add a migration deadline Kconfig | 2 +- Makefile | 2 +- common/board_r.c | 6 ++--- doc/develop/driver-model/migration.rst | 12 ++++++++++ examples/Makefile | 2 +- examples/{api => legacy_api}/.gitignore | 0 examples/{api => legacy_api}/Makefile | 8 +++---- examples/{api => legacy_api}/crt0.S | 0 examples/{api => legacy_api}/demo.c | 2 +- examples/{api => legacy_api}/glue.c | 2 +- examples/{api => legacy_api}/glue.h | 0 examples/{api => legacy_api}/libgenwrap.c | 2 +- include/{api.h => legacy_api.h} | 10 +++++---- include/{api_public.h => legacy_api_public.h} | 6 ++--- include/net-common.h | 2 +- include/net-legacy.h | 2 +- {api => legacy_api}/Kconfig | 22 +++++++++++-------- {api => legacy_api}/Makefile | 0 {api => legacy_api}/README | 2 +- {api => legacy_api}/api.c | 4 ++-- {api => legacy_api}/api_display.c | 2 +- {api => legacy_api}/api_net.c | 2 +- {api => legacy_api}/api_platform-arm.c | 2 +- {api => legacy_api}/api_platform-mips.c | 2 +- {api => legacy_api}/api_platform-powerpc.c | 2 +- {api => legacy_api}/api_private.h | 2 +- {api => legacy_api}/api_storage.c | 2 +- lib/Makefile | 2 +- lib/vsprintf.c | 6 ++--- net/lwip/net-lwip.c | 4 ++-- net/net.c | 4 ++-- test/common/print.c | 2 +- test/lib/unicode.c | 2 +- 33 files changed, 69 insertions(+), 51 deletions(-) rename examples/{api => legacy_api}/.gitignore (100%) rename examples/{api => legacy_api}/Makefile (87%) rename examples/{api => legacy_api}/crt0.S (100%) rename examples/{api => legacy_api}/demo.c (99%) rename examples/{api => legacy_api}/glue.c (99%) rename examples/{api => legacy_api}/glue.h (100%) rename examples/{api => legacy_api}/libgenwrap.c (96%) rename include/{api.h => legacy_api.h} (63%) rename include/{api_public.h => legacy_api_public.h} (96%) rename {api => legacy_api}/Kconfig (62%) rename {api => legacy_api}/Makefile (100%) rename {api => legacy_api}/README (98%) rename {api => legacy_api}/api.c (99%) rename {api => legacy_api}/api_display.c (94%) rename {api => legacy_api}/api_net.c (98%) rename {api => legacy_api}/api_platform-arm.c (96%) rename {api => legacy_api}/api_platform-mips.c (95%) rename {api => legacy_api}/api_platform-powerpc.c (97%) rename {api => legacy_api}/api_private.h (97%) rename {api => legacy_api}/api_storage.c (99%) -- 2.43.0 base-commit: a417edcb4a4d6453eb97489dfc1707fbce45dd38 branch: ulic
From: Simon Glass <sjg@chromium.org> The API is not very useful these days, since it doesn't support driver model. It is laborious to add new functions to the API as there are so many needed. A better approach would be to create a library containing all of U-Boot, then have the API be generated by a script containing a list of functions, perhaps with wildcards. Then a stub could be created, with a list of entry points, which links with and calls through into the library. In preparation for heading in this direction, rename some of the existing files and directories: - examples/api -> examples/legacy_api - include/api*.h -> include/legacy_api*.h - API_BUILD to LEGACY_API_BUILD Co-developed-by: Claude <noreply@anthropic.com> Signed-off-by: Simon Glass <sjg@chromium.org> --- api/api.c | 2 +- api/api_display.c | 2 +- api/api_net.c | 2 +- api/api_platform-arm.c | 2 +- api/api_platform-mips.c | 2 +- api/api_platform-powerpc.c | 2 +- api/api_storage.c | 2 +- common/board_r.c | 2 +- examples/{api => legacy_api}/.gitignore | 0 examples/{api => legacy_api}/Makefile | 8 ++++---- examples/{api => legacy_api}/crt0.S | 0 examples/{api => legacy_api}/demo.c | 2 +- examples/{api => legacy_api}/glue.c | 2 +- examples/{api => legacy_api}/glue.h | 0 examples/{api => legacy_api}/libgenwrap.c | 2 +- include/{api.h => legacy_api.h} | 4 ++-- include/{api_public.h => legacy_api_public.h} | 6 +++--- lib/Makefile | 2 +- lib/vsprintf.c | 6 +++--- test/common/print.c | 2 +- test/lib/unicode.c | 2 +- 21 files changed, 26 insertions(+), 26 deletions(-) rename examples/{api => legacy_api}/.gitignore (100%) rename examples/{api => legacy_api}/Makefile (87%) rename examples/{api => legacy_api}/crt0.S (100%) rename examples/{api => legacy_api}/demo.c (99%) rename examples/{api => legacy_api}/glue.c (99%) rename examples/{api => legacy_api}/glue.h (100%) rename examples/{api => legacy_api}/libgenwrap.c (96%) rename include/{api.h => legacy_api.h} (89%) rename include/{api_public.h => legacy_api_public.h} (96%) diff --git a/api/api.c b/api/api.c index b892c5c278a..458eaf0c5a4 100644 --- a/api/api.c +++ b/api/api.c @@ -15,7 +15,7 @@ #include <linux/delay.h> #include <linux/errno.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include <u-boot/crc.h> #include "api_private.h" diff --git a/api/api_display.c b/api/api_display.c index 8fd078c8c4a..83ff89d3680 100644 --- a/api/api_display.c +++ b/api/api_display.c @@ -3,7 +3,7 @@ * Copyright (c) 2011 The Chromium OS Authors. */ -#include <api_public.h> +#include <legacy_api_public.h> #include <log.h> #include <linux/types.h> diff --git a/api/api_net.c b/api/api_net.c index 264ff530563..0bedcce4df5 100644 --- a/api/api_net.c +++ b/api/api_net.c @@ -8,7 +8,7 @@ #include <config.h> #include <net.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #define DEBUG #undef DEBUG diff --git a/api/api_platform-arm.c b/api/api_platform-arm.c index 9afba66c244..3d2a3e0bd45 100644 --- a/api/api_platform-arm.c +++ b/api/api_platform-arm.c @@ -10,7 +10,7 @@ #include <config.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include <asm/global_data.h> diff --git a/api/api_platform-mips.c b/api/api_platform-mips.c index 262b35a2777..b5632320290 100644 --- a/api/api_platform-mips.c +++ b/api/api_platform-mips.c @@ -7,7 +7,7 @@ #include <config.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include <asm/global_data.h> diff --git a/api/api_platform-powerpc.c b/api/api_platform-powerpc.c index 2c1ab043af6..6b76afd955f 100644 --- a/api/api_platform-powerpc.c +++ b/api/api_platform-powerpc.c @@ -10,7 +10,7 @@ #include <config.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include <asm/global_data.h> diff --git a/api/api_storage.c b/api/api_storage.c index c663e7df942..23f043fbb5d 100644 --- a/api/api_storage.c +++ b/api/api_storage.c @@ -6,7 +6,7 @@ */ #include <config.h> -#include <api_public.h> +#include <legacy_api_public.h> #include <part.h> #include <scsi.h> #include <linux/types.h> diff --git a/common/board_r.c b/common/board_r.c index ca1498de11e..a141312f918 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -10,7 +10,7 @@ */ #include <config.h> -#include <api.h> +#include <legacy_api.h> #include <bootstage.h> #include <cpu_func.h> #include <cyclic.h> diff --git a/examples/api/.gitignore b/examples/legacy_api/.gitignore similarity index 100% rename from examples/api/.gitignore rename to examples/legacy_api/.gitignore diff --git a/examples/api/Makefile b/examples/legacy_api/Makefile similarity index 87% rename from examples/api/Makefile rename to examples/legacy_api/Makefile index ec1643e4875..07a31e219b6 100644 --- a/examples/api/Makefile +++ b/examples/legacy_api/Makefile @@ -2,8 +2,8 @@ # # (C) Copyright 2007 Semihalf -# Provide symbol API_BUILD to signal that the API example is being built. -KBUILD_CPPFLAGS += -DAPI_BUILD +# Provide symbol LEGACY_API_BUILD to signal that the legacy API example is being built. +KBUILD_CPPFLAGS += -DLEGACY_API_BUILD ifeq ($(ARCH),powerpc) LOAD_ADDR = 0x40000 @@ -26,13 +26,13 @@ endif # Resulting ELF and binary exectuables will be named demo and demo.bin extra-y = demo -# Source files located in the examples/api directory +# Source files located in the examples/legacy_api directory OBJ-y += crt0.o OBJ-y += demo.o OBJ-y += glue.o OBJ-y += libgenwrap.o -# Source files which exist outside the examples/api directory +# Source files which exist outside the examples/legacy_api directory EXT_COBJ-y += lib/crc32.o EXT_COBJ-y += lib/ctype.o EXT_COBJ-y += lib/div64.o diff --git a/examples/api/crt0.S b/examples/legacy_api/crt0.S similarity index 100% rename from examples/api/crt0.S rename to examples/legacy_api/crt0.S diff --git a/examples/api/demo.c b/examples/legacy_api/demo.c similarity index 99% rename from examples/api/demo.c rename to examples/legacy_api/demo.c index 9a55f76c504..ea1a8746812 100644 --- a/examples/api/demo.c +++ b/examples/legacy_api/demo.c @@ -8,7 +8,7 @@ #include <stdio.h> #include <env.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include "glue.h" diff --git a/examples/api/glue.c b/examples/legacy_api/glue.c similarity index 99% rename from examples/api/glue.c rename to examples/legacy_api/glue.c index 478f7b6cfb4..4f7012ea730 100644 --- a/examples/api/glue.c +++ b/examples/legacy_api/glue.c @@ -5,7 +5,7 @@ #include <env.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include <u-boot/crc.h> #include "glue.h" diff --git a/examples/api/glue.h b/examples/legacy_api/glue.h similarity index 100% rename from examples/api/glue.h rename to examples/legacy_api/glue.h diff --git a/examples/api/libgenwrap.c b/examples/legacy_api/libgenwrap.c similarity index 96% rename from examples/api/libgenwrap.c rename to examples/legacy_api/libgenwrap.c index bfd88e100d6..9ada33fb15b 100644 --- a/examples/api/libgenwrap.c +++ b/examples/legacy_api/libgenwrap.c @@ -13,7 +13,7 @@ #include <hang.h> #include <linux/delay.h> #include <linux/types.h> -#include <api_public.h> +#include <legacy_api_public.h> #include "glue.h" diff --git a/include/api.h b/include/legacy_api.h similarity index 89% rename from include/api.h rename to include/legacy_api.h index 83412a7c87f..85bd80b2e33 100644 --- a/include/api.h +++ b/include/legacy_api.h @@ -4,8 +4,8 @@ * Written by Simon Glass <sjg@chromium.org> */ -#ifndef __API_H -#define __API_H +#ifndef __LEGACY_API_H +#define __LEGACY_API_H /** * api_init() - Initialize API for external applications diff --git a/include/api_public.h b/include/legacy_api_public.h similarity index 96% rename from include/api_public.h rename to include/legacy_api_public.h index e89572c00a4..d8bb5807460 100644 --- a/include/api_public.h +++ b/include/legacy_api_public.h @@ -5,8 +5,8 @@ * Written by: Rafal Jaworowski <raj@semihalf.com> */ -#ifndef _API_PUBLIC_H_ -#define _API_PUBLIC_H_ +#ifndef _LEGACY_API_PUBLIC_H_ +#define _LEGACY_API_PUBLIC_H_ #include <linux/types.h> @@ -139,4 +139,4 @@ struct display_info { int screen_cols; }; -#endif /* _API_PUBLIC_H_ */ +#endif /* _LEGACY_API_PUBLIC_H_ */ diff --git a/lib/Makefile b/lib/Makefile index af191913873..1db1e3c9000 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -23,7 +23,7 @@ obj-$(CONFIG_AES) += aes.o obj-$(CONFIG_AES) += aes/ obj-$(CONFIG_$(PHASE_)BINMAN_FDT) += binman.o -ifndef API_BUILD +ifndef LEGACY_API_BUILD ifneq ($(CONFIG_CHARSET),) obj-y += charset.o endif diff --git a/lib/vsprintf.c b/lib/vsprintf.c index c7340a047b2..c072b44140b 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -308,7 +308,7 @@ static __maybe_unused char *string16(char *buf, char *end, u16 *s, return buf; } -#if CONFIG_IS_ENABLED(EFI_DEVICE_PATH_TO_TEXT) && !defined(API_BUILD) +#if CONFIG_IS_ENABLED(EFI_DEVICE_PATH_TO_TEXT) && !defined(LEGACY_API_BUILD) static char *device_path_string(char *buf, char *end, void *dp, int field_width, int precision, int flags) { @@ -469,7 +469,7 @@ static char *pointer(const char *fmt, char *buf, char *end, void *ptr, switch (*fmt) { /* Device paths only exist in the EFI context. */ -#if CONFIG_IS_ENABLED(EFI_DEVICE_PATH_TO_TEXT) && !defined(API_BUILD) +#if CONFIG_IS_ENABLED(EFI_DEVICE_PATH_TO_TEXT) && !defined(LEGACY_API_BUILD) case 'D': return device_path_string(buf, end, ptr, field_width, precision, flags); @@ -630,7 +630,7 @@ repeat: case 's': /* U-Boot uses UTF-16 strings in the EFI context only. */ #if (CONFIG_IS_ENABLED(EFI_LOADER) || IS_ENABLED(CONFIG_EFI_APP)) && \ - !defined(API_BUILD) + !defined(LEGACY_API_BUILD) if (qualifier == 'l') { str = string16(str, end, va_arg(args, u16 *), field_width, precision, flags); diff --git a/test/common/print.c b/test/common/print.c index c48efc2783f..3fe24dc3e9d 100644 --- a/test/common/print.c +++ b/test/common/print.c @@ -59,7 +59,7 @@ static int print_guid(struct unit_test_state *uts) COMMON_TEST(print_guid, 0); #endif -#if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(API_BUILD) +#if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(LEGACY_API_BUILD) /* Test efi_loader specific printing */ static int print_efi_ut(struct unit_test_state *uts) { diff --git a/test/lib/unicode.c b/test/lib/unicode.c index 673470c8d2c..5bd3629b153 100644 --- a/test/lib/unicode.c +++ b/test/lib/unicode.c @@ -100,7 +100,7 @@ static int unicode_test_u16_strcpy(struct unit_test_state *uts) LIB_TEST(unicode_test_u16_strcpy, 0); /* U-Boot uses UTF-16 strings in the EFI context only. */ -#if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(API_BUILD) +#if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(LEGACY_API_BUILD) static int unicode_test_string16(struct unit_test_state *uts) { char buf[20]; -- 2.43.0
From: Simon Glass <sjg@chromium.org> Rename this directory legacy_api since it is now considered legacy. Co-developed-by: Claude <noreply@anthropic.com> Signed-off-by: Simon Glass <sjg@chromium.org> --- Kconfig | 2 +- Makefile | 2 +- {api => legacy_api}/Kconfig | 0 {api => legacy_api}/Makefile | 0 {api => legacy_api}/README | 0 {api => legacy_api}/api.c | 0 {api => legacy_api}/api_display.c | 0 {api => legacy_api}/api_net.c | 0 {api => legacy_api}/api_platform-arm.c | 0 {api => legacy_api}/api_platform-mips.c | 0 {api => legacy_api}/api_platform-powerpc.c | 0 {api => legacy_api}/api_private.h | 0 {api => legacy_api}/api_storage.c | 0 13 files changed, 2 insertions(+), 2 deletions(-) rename {api => legacy_api}/Kconfig (100%) rename {api => legacy_api}/Makefile (100%) rename {api => legacy_api}/README (100%) rename {api => legacy_api}/api.c (100%) rename {api => legacy_api}/api_display.c (100%) rename {api => legacy_api}/api_net.c (100%) rename {api => legacy_api}/api_platform-arm.c (100%) rename {api => legacy_api}/api_platform-mips.c (100%) rename {api => legacy_api}/api_platform-powerpc.c (100%) rename {api => legacy_api}/api_private.h (100%) rename {api => legacy_api}/api_storage.c (100%) diff --git a/Kconfig b/Kconfig index 3b136a5f897..bf30179db93 100644 --- a/Kconfig +++ b/Kconfig @@ -731,7 +731,7 @@ config LDR_CPU generally used on processors from Analog Devices, but may be also be useful for other vendors. -source "api/Kconfig" +source "legacy_api/Kconfig" endmenu # General setup diff --git a/Makefile b/Makefile index b43e028a06e..088de1d1de4 100644 --- a/Makefile +++ b/Makefile @@ -865,7 +865,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) -libs-$(CONFIG_API) += api/ +libs-$(CONFIG_API) += legacy_api/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/ libs-y += boot/ libs-$(CONFIG_CMDLINE) += cmd/ diff --git a/api/Kconfig b/legacy_api/Kconfig similarity index 100% rename from api/Kconfig rename to legacy_api/Kconfig diff --git a/api/Makefile b/legacy_api/Makefile similarity index 100% rename from api/Makefile rename to legacy_api/Makefile diff --git a/api/README b/legacy_api/README similarity index 100% rename from api/README rename to legacy_api/README diff --git a/api/api.c b/legacy_api/api.c similarity index 100% rename from api/api.c rename to legacy_api/api.c diff --git a/api/api_display.c b/legacy_api/api_display.c similarity index 100% rename from api/api_display.c rename to legacy_api/api_display.c diff --git a/api/api_net.c b/legacy_api/api_net.c similarity index 100% rename from api/api_net.c rename to legacy_api/api_net.c diff --git a/api/api_platform-arm.c b/legacy_api/api_platform-arm.c similarity index 100% rename from api/api_platform-arm.c rename to legacy_api/api_platform-arm.c diff --git a/api/api_platform-mips.c b/legacy_api/api_platform-mips.c similarity index 100% rename from api/api_platform-mips.c rename to legacy_api/api_platform-mips.c diff --git a/api/api_platform-powerpc.c b/legacy_api/api_platform-powerpc.c similarity index 100% rename from api/api_platform-powerpc.c rename to legacy_api/api_platform-powerpc.c diff --git a/api/api_private.h b/legacy_api/api_private.h similarity index 100% rename from api/api_private.h rename to legacy_api/api_private.h diff --git a/api/api_storage.c b/legacy_api/api_storage.c similarity index 100% rename from api/api_storage.c rename to legacy_api/api_storage.c -- 2.43.0
From: Simon Glass <sjg@chromium.org> Update Kconfig use use CONFIG_LEGACY_API since the API is now deprecated. Signed-off-by: Simon Glass <sjg@chromium.org> --- Makefile | 2 +- common/board_r.c | 4 ++-- examples/Makefile | 2 +- include/net-common.h | 2 +- include/net-legacy.h | 2 +- legacy_api/Kconfig | 22 +++++++++++++--------- legacy_api/README | 2 +- net/lwip/net-lwip.c | 4 ++-- net/net.c | 4 ++-- 9 files changed, 24 insertions(+), 20 deletions(-) diff --git a/Makefile b/Makefile index 088de1d1de4..7011535bb2f 100644 --- a/Makefile +++ b/Makefile @@ -865,7 +865,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) -libs-$(CONFIG_API) += legacy_api/ +libs-$(CONFIG_LEGACY_API) += legacy_api/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/ libs-y += boot/ libs-$(CONFIG_CMDLINE) += cmd/ diff --git a/common/board_r.c b/common/board_r.c index a141312f918..1bb0eb37e9b 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -686,8 +686,8 @@ static void initcall_run_r(void) #endif INITCALL(stdio_add_devices); INITCALL(jumptable_init); -#if CONFIG_IS_ENABLED(API) - INITCALL(api_init); +#if CONFIG_IS_ENABLED(LEGACY_API) + INITCALL(legacy_api_init); #endif INITCALL(console_init_r); /* fully init console as a device */ #if CONFIG_IS_ENABLED(DISPLAY_BOARDINFO_LATE) diff --git a/examples/Makefile b/examples/Makefile index bf518bd221b..bf51f1a5018 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -7,5 +7,5 @@ subdir-ccflags-y += -finstrument-functions -DFTRACE endif subdir-y += standalone -subdir-$(CONFIG_API) += api +subdir-$(CONFIG_LEGACY_API) += api endif diff --git a/include/net-common.h b/include/net-common.h index 0829e05f94b..9d26c26cf5f 100644 --- a/include/net-common.h +++ b/include/net-common.h @@ -198,7 +198,7 @@ int usb_ether_init(void); int eth_init(void); /* Initialize the device */ int eth_start_udev(struct udevice *dev); /* ->start() if not already running */ int eth_send(void *packet, int length); /* Send a packet */ -#if defined(CONFIG_API) || defined(CONFIG_EFI_LOADER) +#if defined(CONFIG_LEGACY_API) || defined(CONFIG_EFI_LOADER) int eth_receive(void *packet, int length); /* Receive a packet*/ extern void (*push_packet)(void *packet, int length); #endif diff --git a/include/net-legacy.h b/include/net-legacy.h index a7dbcec1506..41a898bb7d1 100644 --- a/include/net-legacy.h +++ b/include/net-legacy.h @@ -105,7 +105,7 @@ int eth_env_get_enetaddr_by_index(const char *base_name, int index, int eth_send(void *packet, int length); /* Send a packet */ -#if defined(CONFIG_API) || defined(CONFIG_EFI_LOADER) +#if defined(CONFIG_LEGACY_API) || defined(CONFIG_EFI_LOADER) int eth_receive(void *packet, int length); /* Receive a packet*/ extern void (*push_packet)(void *packet, int length); #endif diff --git a/legacy_api/Kconfig b/legacy_api/Kconfig index b58f293107f..6dc96455ff0 100644 --- a/legacy_api/Kconfig +++ b/legacy_api/Kconfig @@ -1,23 +1,27 @@ -config API - bool "Enable U-Boot API" +config LEGACY_API + bool "Enable Legacy U-Boot API" depends on CC_IS_GCC help - This option enables the U-Boot API. See api/README for more information. + This option enables the legcay U-Boot API. See legacy_api/README for + more information. -menu "API" - depends on API + Note that this is deprecated and not intended to be used. It will be + removed by the end of 2027. + +menu "LEGACY API" + depends on LEGACY_API config SYS_MMC_MAX_DEVICE - int "Maximum number of MMC devices exposed via the API" + int "Maximum number of MMC devices exposed via the legacy API" default 1 config EXAMPLES - bool "Compile API examples" + bool "Compile legacy API examples" depends on !SANDBOX default y if ARCH_QEMU_ARM help - U-Boot provides an API for standalone applications. Examples are - provided in directory examples/. + U-Boot provides an legacy API for standalone applications. Examples + are provided in directory examples/. config STANDALONE_LOAD_ADDR depends on EXAMPLES diff --git a/legacy_api/README b/legacy_api/README index 6df225f584b..e635735f689 100644 --- a/legacy_api/README +++ b/legacy_api/README @@ -24,7 +24,7 @@ U-Boot machine/arch independent API for external apps for example it doesn't keep states, but relies on hints from the app and so on - - optional (CONFIG_API) + - optional (CONFIG_LEGACY_API) 2. Calls diff --git a/net/lwip/net-lwip.c b/net/lwip/net-lwip.c index 2cc5749d459..bf3bdd6f950 100644 --- a/net/lwip/net-lwip.c +++ b/net/lwip/net-lwip.c @@ -18,7 +18,7 @@ /* xx:xx:xx:xx:xx:xx\0 */ #define MAC_ADDR_STRLEN 18 -#if defined(CONFIG_API) || defined(CONFIG_EFI_LOADER) +#if defined(CONFIG_LEGACY_API) || defined(CONFIG_EFI_LOADER) void (*push_packet)(void *, int len) = 0; #endif static int net_try_count; @@ -303,7 +303,7 @@ int net_lwip_rx(struct udevice *udev, struct netif *netif) void net_process_received_packet(uchar *in_packet, int len) { -#if defined(CONFIG_API) || defined(CONFIG_EFI_LOADER) +#if defined(CONFIG_LEGACY_API) || defined(CONFIG_EFI_LOADER) if (push_packet) (*push_packet)(in_packet, len); #endif diff --git a/net/net.c b/net/net.c index 7b9fc3fb0df..d2a698aea2f 100644 --- a/net/net.c +++ b/net/net.c @@ -158,7 +158,7 @@ static unsigned net_ip_id; /* Ethernet bcast address */ const u8 net_bcast_ethaddr[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; const u8 net_null_ethaddr[6]; -#if defined(CONFIG_API) || defined(CONFIG_EFI_LOADER) +#if defined(CONFIG_LEGACY_API) || defined(CONFIG_EFI_LOADER) void (*push_packet)(void *, int len) = 0; #endif /* Network loop state */ @@ -1248,7 +1248,7 @@ void net_process_received_packet(uchar *in_packet, int len) if (len < ETHER_HDR_SIZE) return; -#if defined(CONFIG_API) || defined(CONFIG_EFI_LOADER) +#if defined(CONFIG_LEGACY_API) || defined(CONFIG_EFI_LOADER) if (push_packet) { (*push_packet)(in_packet, len); return; -- 2.43.0
From: Simon Glass <sjg@chromium.org> Complete the rename of this API so that it is clear it is considered deprecated. Signed-off-by: Simon Glass <sjg@chromium.org> --- include/legacy_api.h | 6 ++++-- legacy_api/api.c | 2 +- legacy_api/api_private.h | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/legacy_api.h b/include/legacy_api.h index 85bd80b2e33..6ada4000715 100644 --- a/include/legacy_api.h +++ b/include/legacy_api.h @@ -8,13 +8,15 @@ #define __LEGACY_API_H /** - * api_init() - Initialize API for external applications + * legacy_api_init() - Initialize legacy API for external applications * * Initialize API for external (standalone) applications running on top of * U-Boot. It is called during the generic post-relocation init sequence. * + * Note that this is deprecated. + * * Return: 0 if OK */ -int api_init(void); +int legacy_api_init(void); #endif diff --git a/legacy_api/api.c b/legacy_api/api.c index 458eaf0c5a4..a3d3a8eccae 100644 --- a/legacy_api/api.c +++ b/legacy_api/api.c @@ -638,7 +638,7 @@ int syscall(int call, int *retval, ...) return 1; } -int api_init(void) +int legacy_api_init(void) { struct api_signature *sig; diff --git a/legacy_api/api_private.h b/legacy_api/api_private.h index bb23821c2c0..1871ba4f431 100644 --- a/legacy_api/api_private.h +++ b/legacy_api/api_private.h @@ -8,7 +8,7 @@ #ifndef _API_PRIVATE_H_ #define _API_PRIVATE_H_ -int api_init(void); +int legacy_api_init(void); void platform_set_mr(struct sys_info *, unsigned long, unsigned long, int); int platform_sys_info(struct sys_info *); -- 2.43.0
From: Simon Glass <sjg@chromium.org> Set a deadline of the end of 2027 for removal of what is now the legacy API. Signed-off-by: Simon Glass <sjg@chromium.org> --- doc/develop/driver-model/migration.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/doc/develop/driver-model/migration.rst b/doc/develop/driver-model/migration.rst index b40a6af9d11..50689282b39 100644 --- a/doc/develop/driver-model/migration.rst +++ b/doc/develop/driver-model/migration.rst @@ -118,3 +118,15 @@ Deadline: 2023.04 The serial subsystem has supported the driver model since late 2014. Maintainers should submit patches switching over to using CONFIG_DM_SERIAL and other base driver model options in time for inclusion in the 2022.10 release. + +CONFIG_LEGACY_API +----------------- +Deadline: 2028.01 + +U-Boot has long supported an API which allows external programs to call entry +points in U-Boot. This API does not support driver model and is not widely used. +It is being replaced by a library approach (libu-boot.a/so) which is more +flexible and could potentially support an automatically generated stub with +those entry points. + +The API will be removed for the 2028.01 release. -- 2.43.0
Hi Simon Glass, On 5/9/2025 9:18 pm, Simon Glass wrote:
From: Simon Glass <sjg@chromium.org>
The existing U-Boot API is quite old and doesn't support driver model. Adding new functions is a manual process and no one has attempted this in the 10 years that driver model has been present. Undertaking such a task would be laborious and would require continued effort to maintain.
A better approach would be to create a library containing all of U-Boot, then have the API be generated by a script from a list of functions. This would allow for a more flexible and maintainable interface.
In preparation for this new direction, this series renames the existing API components to clearly mark them as legacy:
- Rename api/ to legacy_api/ - Rename examples/api/ to examples/legacy_api/ - Rename include/api.h and include/api_public.h to include/legacy_api*.h - Rename API_BUILD to LEGACY_API_BUILD - Rename CONFIG_API to CONFIG_LEGACY_API - Rename api_init() to legacy_api_init()
This provides a clean namespace for implementing the new library-based API approach while maintaining backward compatibility for existing users of the legacy interface.
This series also sets a deadline for removal of the legacy API.
[...] I’d like to ask for some clarification regarding the roadmap and plans for ulib: 1. Is there a roadmap or timeline for when ulib support is expected to be merged into mainline and considered stable for external usage? 2. What is the long-term vision for ulib in relation to the deprecation of the legacy API and standalone application support? 3. Are there particular areas, such as ARM architecture enablement, where additional community contributions or testing would be especially helpful? 4. Any other guidance for users or contributors interested in adopting or supporting ulib going forward? 5. We’re interested in aligning our work and potential contributions with the project’s direction, so any details you can provide would be much appreciated. Thanks. Best regards, Tien Fong
Hi Tien Fong, On Wed, 10 Dec 2025 at 00:24, Chee, Tien Fong <tienfong.chee@altera.com> wrote:
Hi Simon Glass,
On 5/9/2025 9:18 pm, Simon Glass wrote:
From: Simon Glass <sjg@chromium.org>
The existing U-Boot API is quite old and doesn't support driver model. Adding new functions is a manual process and no one has attempted this in the 10 years that driver model has been present. Undertaking such a task would be laborious and would require continued effort to maintain.
A better approach would be to create a library containing all of U-Boot, then have the API be generated by a script from a list of functions. This would allow for a more flexible and maintainable interface.
In preparation for this new direction, this series renames the existing API components to clearly mark them as legacy:
- Rename api/ to legacy_api/ - Rename examples/api/ to examples/legacy_api/ - Rename include/api.h and include/api_public.h to include/legacy_api*.h - Rename API_BUILD to LEGACY_API_BUILD - Rename CONFIG_API to CONFIG_LEGACY_API - Rename api_init() to legacy_api_init()
This provides a clean namespace for implementing the new library-based API approach while maintaining backward compatibility for existing users of the legacy interface.
This series also sets a deadline for removal of the legacy API.
[...]
I’d like to ask for some clarification regarding the roadmap and plans for ulib:
1. Is there a roadmap or timeline for when ulib support is expected to be merged into mainline and considered stable for external usage?
Thanks for your interest. I am happy to contribute things to Tom's tree if he is willing. The sheer volume of patches makes it difficult as we don't have a lot of reviewers.
2. What is the long-term vision for ulib in relation to the deprecation of the legacy API and standalone application support?
ulib is designed to link against a GPL application. Is that what you are looking for? If not, as you probably saw from the documentation there is a rename.syms file which helps to form the API. I have not looked at it, but the easiest solution would be to create an 'api.syms' file to define a function table similar to the legacy API. The build_api.py would need to be enhanced to write this table, perhaps based on a file which lists the things present in that API. Then we would need a header file with static inlines to redirect calls to uclass_first_device() etc. to the function table, i.e. api->uclass_first_device() I would be happy to take an initial look if you think that makes sense.
3. Are there particular areas, such as ARM architecture enablement, where additional community contributions or testing would be especially helpful?
Yes, ARM enablement would be useful! It should be fairly close (x86 works OK).
4. Any other guidance for users or contributors interested in adopting or supporting ulib going forward?
For now this is a Concept feature, but I am happy to review patches and PRs and get them applied to the Concept tree.
5. We’re interested in aligning our work and potential contributions with the project’s direction, so any details you can provide would be much appreciated.
You have probably already seen the blob post. https://u-boot.org/blog/u-boot-as-a-library-introducing-ulib-a-bridge-to-the... Let me know if you have any other questions or comments. Regards, Simon
Hi Simon, On 11/12/2025 9:11 pm, Simon Glass wrote:
[CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
Hi Tien Fong,
On Wed, 10 Dec 2025 at 00:24, Chee, Tien Fong <tienfong.chee@altera.com> wrote:
Hi Simon Glass,
On 5/9/2025 9:18 pm, Simon Glass wrote:
From: Simon Glass <sjg@chromium.org>
The existing U-Boot API is quite old and doesn't support driver model. Adding new functions is a manual process and no one has attempted this in the 10 years that driver model has been present. Undertaking such a task would be laborious and would require continued effort to maintain.
A better approach would be to create a library containing all of U-Boot, then have the API be generated by a script from a list of functions. This would allow for a more flexible and maintainable interface.
In preparation for this new direction, this series renames the existing API components to clearly mark them as legacy:
- Rename api/ to legacy_api/ - Rename examples/api/ to examples/legacy_api/ - Rename include/api.h and include/api_public.h to include/legacy_api*.h - Rename API_BUILD to LEGACY_API_BUILD - Rename CONFIG_API to CONFIG_LEGACY_API - Rename api_init() to legacy_api_init()
This provides a clean namespace for implementing the new library-based API approach while maintaining backward compatibility for existing users of the legacy interface.
This series also sets a deadline for removal of the legacy API.
[...]
I’d like to ask for some clarification regarding the roadmap and plans for ulib:
1. Is there a roadmap or timeline for when ulib support is expected to be merged into mainline and considered stable for external usage? Thanks for your interest. I am happy to contribute things to Tom's tree if he is willing. The sheer volume of patches makes it difficult as we don't have a lot of reviewers.
2. What is the long-term vision for ulib in relation to the deprecation of the legacy API and standalone application support? ulib is designed to link against a GPL application. Is that what you are looking for?
If not, as you probably saw from the documentation there is a rename.syms file which helps to form the API. I have not looked at it, but the easiest solution would be to create an 'api.syms' file to define a function table similar to the legacy API. The build_api.py would need to be enhanced to write this table, perhaps based on a file which lists the things present in that API. Then we would need a header file with static inlines to redirect calls to uclass_first_device() etc. to the function table, i.e. api->uclass_first_device()
I would be happy to take an initial look if you think that makes sense.
3. Are there particular areas, such as ARM architecture enablement, where additional community contributions or testing would be especially helpful? Yes, ARM enablement would be useful! It should be fairly close (x86 works OK).
4. Any other guidance for users or contributors interested in adopting or supporting ulib going forward? For now this is a Concept feature, but I am happy to review patches and PRs and get them applied to the Concept tree.
5. We’re interested in aligning our work and potential contributions with the project’s direction, so any details you can provide would be much appreciated. You have probably already seen the blob post.
https://u-boot.org/blog/u-boot-as-a-library-introducing-ulib-a-bridge-to-the...
Let me know if you have any other questions or comments.
Thanks for your detailed answers and guidance. We appreciate your openness to contributions, especially for ARM enablement, and your willingness to review patches. To help us with planning and adoption on our side, we’re wondering if there’s any rough estimate or target for when ulib might be merged into mainline U-Boot and considered stable for external use. We understand there are a lot of patches and review bandwidth is a factor, but even a general sense of priorities or timing would be helpful for our project planning. I’ve CC’d Tom to invite his input as well, in case there’s any additional perspective on mainline priorities or what would help move ulib forward. Thanks again for your work on this. Please let us know how we can best contribute, especially around ARM support. Best regards, Tien Fong
On Mon, Dec 15, 2025 at 05:44:00PM +0800, Chee, Tien Fong wrote:
Hi Simon,
On 11/12/2025 9:11 pm, Simon Glass wrote:
[CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
Hi Tien Fong,
On Wed, 10 Dec 2025 at 00:24, Chee, Tien Fong <tienfong.chee@altera.com> wrote:
Hi Simon Glass,
On 5/9/2025 9:18 pm, Simon Glass wrote:
From: Simon Glass <sjg@chromium.org>
The existing U-Boot API is quite old and doesn't support driver model. Adding new functions is a manual process and no one has attempted this in the 10 years that driver model has been present. Undertaking such a task would be laborious and would require continued effort to maintain.
A better approach would be to create a library containing all of U-Boot, then have the API be generated by a script from a list of functions. This would allow for a more flexible and maintainable interface.
In preparation for this new direction, this series renames the existing API components to clearly mark them as legacy:
- Rename api/ to legacy_api/ - Rename examples/api/ to examples/legacy_api/ - Rename include/api.h and include/api_public.h to include/legacy_api*.h - Rename API_BUILD to LEGACY_API_BUILD - Rename CONFIG_API to CONFIG_LEGACY_API - Rename api_init() to legacy_api_init()
This provides a clean namespace for implementing the new library-based API approach while maintaining backward compatibility for existing users of the legacy interface.
This series also sets a deadline for removal of the legacy API.
[...]
I’d like to ask for some clarification regarding the roadmap and plans for ulib:
1. Is there a roadmap or timeline for when ulib support is expected to be merged into mainline and considered stable for external usage? Thanks for your interest. I am happy to contribute things to Tom's tree if he is willing. The sheer volume of patches makes it difficult as we don't have a lot of reviewers.
2. What is the long-term vision for ulib in relation to the deprecation of the legacy API and standalone application support? ulib is designed to link against a GPL application. Is that what you are looking for?
If not, as you probably saw from the documentation there is a rename.syms file which helps to form the API. I have not looked at it, but the easiest solution would be to create an 'api.syms' file to define a function table similar to the legacy API. The build_api.py would need to be enhanced to write this table, perhaps based on a file which lists the things present in that API. Then we would need a header file with static inlines to redirect calls to uclass_first_device() etc. to the function table, i.e. api->uclass_first_device()
I would be happy to take an initial look if you think that makes sense.
3. Are there particular areas, such as ARM architecture enablement, where additional community contributions or testing would be especially helpful? Yes, ARM enablement would be useful! It should be fairly close (x86 works OK).
4. Any other guidance for users or contributors interested in adopting or supporting ulib going forward? For now this is a Concept feature, but I am happy to review patches and PRs and get them applied to the Concept tree.
5. We’re interested in aligning our work and potential contributions with the project’s direction, so any details you can provide would be much appreciated. You have probably already seen the blob post.
https://u-boot.org/blog/u-boot-as-a-library-introducing-ulib-a-bridge-to-the...
Let me know if you have any other questions or comments.
Thanks for your detailed answers and guidance. We appreciate your openness to contributions, especially for ARM enablement, and your willingness to review patches.
To help us with planning and adoption on our side, we’re wondering if there’s any rough estimate or target for when ulib might be merged into mainline U-Boot and considered stable for external use. We understand there are a lot of patches and review bandwidth is a factor, but even a general sense of priorities or timing would be helpful for our project planning.
I’ve CC’d Tom to invite his input as well, in case there’s any additional perspective on mainline priorities or what would help move ulib forward.
Thanks again for your work on this. Please let us know how we can best contribute, especially around ARM support.
It's on Simon to bring his proposals to the community at large. I've not heard anything about this proposal so I have no idea what he's planning and so there's no plans at this time for it to be in mainline. If there's something that Altera needs that can't be met with either an EFI application or the current legacy API, that would be worth bringing up as a new discussion on the project mailing list, which this list is not. -- Tom
participants (3)
-
Chee, Tien Fong -
Simon Glass -
Tom Rini