Re: Inconsistent and ever-changing device naming in Zephyr

Daniel Thompson <daniel.thompson@...>

On 08/02/17 20:39, Paul Sokolovsky wrote:
Hello Daniel,

On Mon, 6 Feb 2017 16:59:26 +0000
Daniel Thompson <> wrote:


a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.

b) Send a strong message to application developers that they should
not rely on any patterns of Zephyr device naming, and even on the
naming at all, and instead should treat it as a configuration
parameter, which ultimately should be set by a user (and thus apps
should make such configuration explicit and easy for users).
Or c) inherit the device names from device tree?

I don't actually remember that much about the proposed DT tooling but
it should certainly be included in this discussion.

It might be made slightly more complex by the presence of aliased
names in DT (often used to bridge SoC datasheet namings into board
based names). I guess Zephyr might prefer to use the most-derived
alias rather then the SoC datasheet name?
I'm not familiar enough with devicetree details to imagine how exactly
that would be done, but Andy's response confirms it's possible to do
something along those ways. But as far as I can see, that still would
depend on establishing common conventions for naming. Perhaps, doing it
via DT would allow to achieve consistency easier, and verify/maintain

But the current question is whether consistency is desirable at all,
i.e. would maintainers of individual SoCs agree each making some
changes to their code/config, and Zephyr maintainers agree to
uphold it afterwards. Given that DT has yet some way to go widely in
Zephyr, discussion or at least consideration of this "consistent
naming" idea might start in parallel.
Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase). However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc).

As a trivial example I'd really dislike a system where "for consistency" we force BSPs to call something "UART-0" when the silkscreen (or front-panel) says "DB9-1".

I guess that is an argument *against* board-to-board consistency!


Join to automatically receive all group messages.