Skip to content

Clarify Z_ APIs naming conventions and intended scope #36811

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fabiobaltieri opened this issue Jul 8, 2021 · 2 comments
Closed

Clarify Z_ APIs naming conventions and intended scope #36811

fabiobaltieri opened this issue Jul 8, 2021 · 2 comments
Labels
area: API Changes to public APIs Enhancement Changes/Updates/Additions to existing features

Comments

@fabiobaltieri
Copy link
Member

Hi, I was trying understand the intended scope and recommended usage of Z_ prefixed macros in Zephyr, specifically Z_STRUCT_SECTION_ITERABLE, but I haven't been able to find explicit documentation about it.

My understanding from the usage in the device model code, and the commit that excludes them from the external documentation (fb4d9c0) is that Z_ symbols are considered internal. Does this mean that they should not be used outside of the core code base?

The iterable macros would be useful at application level, so I'm wondering if we should add a non internal wrapper and documentation for those (or just use them as is).

For context, the only documentation I found about naming is an old page in the wiki (https://github.com/zephyrproject-rtos/zephyr/wiki/Naming-Conventions).

Tagging @nashif (from the patch and wiki) and @KAGA164 (implemented nfc support in NCS using these), who may know more about this.

Thanks!

@fabiobaltieri fabiobaltieri added the Enhancement Changes/Updates/Additions to existing features label Jul 8, 2021
@fabiobaltieri fabiobaltieri changed the title Clarify API naming conventions and intended scope Clarify Z_ APIs naming conventions and intended scope Jul 8, 2021
@carlescufi carlescufi added the area: API Changes to public APIs label Jul 13, 2021
@carlescufi
Copy link
Member

@fabiobaltieri we have #29569 to track this, although unfortunately we haven't had much time lately to discuss this due to other priorities. Maybe you could close this one and add a comment there?

@fabiobaltieri
Copy link
Member Author

Thanks @carlescufi, yes I'll close this and track the issue you mentioned, which answers my initial question. I may open a separate PR to propose publishing the iterables APIs but that's a different topic altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

No branches or pull requests

2 participants