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