Namespacing of Zephyr headers and API

Paul Sokolovsky


This matter already came up in patch reviews and during BSD Sockets
discussion, and I think it's worth to have a dedicated discussion on
it. So, currently there're 2 problems:

1. Zephyr header files aren't namespaced in any special matter, and may
conflict with headers of 3rd-party components with which a Zephyr
application may integrate.

2. About the same is true for Zephyr API calls either. At least there
subsystem prefixes, like "net_" for network subsys, "sensor_" for
sensor subsys. But there're still no namespacing for Zephyr API as
a whole.

Of these 2 issue, I'd consider 1st to be more serious, as there're
already many short, generic names for Zephyr headers. And indeed, there
was at least one conflict even among in-tree components, where Zephyr's
own sched.h conflicted with Newlib's: . If I were making a
specific proposal, I'd say it's not yet too late to move all headers
under zephyr/, while providing compatibility symlinks for couple of
versions (until interested parties will settle with Windows builds,
where symlinks likely won't be supported).

Issue #2 is less apparent, because using prefixes makes function names
at least long, so possibility of conflict is reduced. But it still

Anyway, the purpose of this mail is not to call for specific solutions,
but to see if other people see the above as problems, or anticipate
that it may become in the future. (I may imagine these matters were
considered early in Zephyr development, when e.g. I wasn't around.
Then, it would be nice to revisit it, and make sure that people joined
recently are in loop).

Paul | Open source software for ARM SoCs
Follow Linaro:!/linaroorg -

Join to automatically receive all group messages.