Re: Inconsistent and ever-changing device naming in Zephyr

Maureen Helm

Hi Paul,

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@...]
Sent: Monday, February 06, 2017 7:34 AM
To: devel@...; Anas Nashif <anas.nashif@...>;
Maureen Helm <maureen.helm@...>; sakari.poussa@...;
geoff@...; Daniel Thompson <daniel.thompson@...>
Subject: Inconsistent and ever-changing device naming in Zephyr


Writing on this was in my TODO at least since November, but I expected this to
be a controversial topic, so kind of skipped it. Controversial, as in: different
parties finding to be "obvious" quite different, if not opposite solutions to the
problem. Well, the breakage continues, so this should be raised.

(Recent) facts:

1. Update to Kinetis (BOARD=frdm_k64f) port broke GPIO support in a
(complex) Zephyr-based application, Zephyr.js:

2. A day or two, Arduino 101 I2C support in Zephyr.js was updated, apparently
because Zephyr upgrade broke it. Today it became known that the fix for
Arduino 101 broke FRDM-K64F.

Investigating the issues, the causes of them are:

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!) "gpio_porta".
This is my fault. I was not aware the port names were being used this way. I tend to use the config names rather than the strings themselves. For example, in boards/arm/frdm_k64f/Kconfig.defconfig:

config FXOS8700_GPIO_NAME

Please, please let me know if you encounter problems like this again.

2. Name of (one of) I2C device for arduino_101 changed from "I2C_0" to

This is not the first time when device names change in Zephyr (see reference
above to November 2016), it's the first time (at least for last half-year), when
the naming changes in relatively well developed ports, which leads to cascade
of breakage in the one. And one case, it can be seen how inconsistent naming
(and changes of it) can be.

The question what to do about this. Possible high-level approaches can

a) Establish (well, reconfirm/clarify) and uphold consistent naming conventions
across ports, architectures, and boards.
Since you're most affected, mind making a proposal?

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).

Whether a) is a viable solution in turn depends on paradigmatic decision what
aim Zephyr is trying to achieve:

I. Is it a common platform, literally, an Operating System, providing consistent
means to develop software *across* various hardware?

II. Or is it loose collection of APIs of working with hardware, with the aim of
getting most (or something) of a particular hardware, without pledging much
for consistency and portability across hardware.

It would be nice to get opinions of both the core maintainers and the
maintainers of particular ports, as well as specific suggestions how to deal with
the bugs above.

Paul | Open source software for ARM SoCs Follow Linaro:
D&reserved=0 -

Join to automatically receive all group messages.