Hi Benjamin,

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.

IMO the driver interface is still considered public APIs.
Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers.

How long are we supposed to support this API 1.0? Can't we drop some
of its specifics in, let's say, 1.5?
The more we will have to support all of it, the less we will be able
to proceed on some interesting changes.:(

I already got feedback from people developing either drivers or sample
application for Rocket, basically playing to role of customers of
Zephyr, and I can already say that, for people used to writing software
against APIs that experience a very minimal amount of changes (i.e.
VxWorks), they did_not_ like the fact that even a small amount of our
APIs is in flux. It basically causes lost time and frustration.

I'm not advocating anything w.r.t. a policiy for changing APIs right
now, but this is a data point.

Thus why we may enforce a version of the API vs a Zephyr version. And
move on with a new one.
If they want to get stuck with API 1.0 they could use Zephyr 1.2 (1.3
maybe) and that's it.

Our APIs are, on many aspects, like prototype APIs.
It's not surprising we are willing to modify them, and some quite a lot
actually.

Also: we may keep the public API compatible, but the device driver API
below might change.
Unless we want to bloat our drivers.

Tomasz