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