Skip to content
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

log subsystem APIs need to be clearly namespaced as public or private #19497

Closed
andrewboie opened this issue Oct 1, 2019 · 4 comments
Closed
Assignees
Labels
area: Logging bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug Stale

Comments

@andrewboie
Copy link
Contributor

andrewboie commented Oct 1, 2019

The expectation is that the naming of functions, macros, and globals for logging follow the Zephyr coding standard that private APIs are prefixed with "z_".

Hence I would expect that symbols or macros starting with "log_" are public, and private stuff would be prefixed with "z_log_". However this appears to be inconsistently done. There are a lot of things which are scoped public but appear to be private, some examples would be log_N(), log_printf_arg_checker(), log_generic_from_user(), many macros, the list goes on.

There are also some private macros which are prefixed with _ or __ in violation of our coding standard, these should start with Z_.

Because of this, it's not clear what the public surface of logging is, it's clearly not everything that begins with log_, and we need to re-namespace the internal stuff to clearly indicate it is private. Among other things this will make maintenance easier since we will not have to treat the private stuff as contracts that have to go through the deprecation process if we need to change them.

Overall, I think we need something like:

  • Public, application facing APIs and macros all prefixed with log_ or LOG_
  • Public APIs which are used by log backend implementations all prefixed with log_backend_ or LOG_BACKEND_ (or whatever we like, just be consistent)
  • Remaining internal APIs and macros all prefixed with z_log_/Z_LOG_
@andrewboie andrewboie added bug The issue is a bug, or the PR is fixing a bug area: Logging labels Oct 1, 2019
@andrewboie
Copy link
Contributor Author

Marking this as a bug since we have clear MISRA-C violations and we are treating APIs which are private as public.

@aescolar
Copy link
Member

aescolar commented Oct 1, 2019

CC @nordic-krch @jakub-uC

@dleach02 dleach02 added the priority: low Low impact/importance bug label Oct 1, 2019
@github-actions
Copy link

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Sep 19, 2020
@github-actions github-actions bot closed this as completed Oct 5, 2020
@andrewboie andrewboie removed the Stale label Oct 5, 2020
@andrewboie andrewboie reopened this Oct 5, 2020
@github-actions
Copy link

github-actions bot commented Dec 5, 2020

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Logging bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug Stale
Projects
None yet
Development

No branches or pull requests

4 participants