On Tue, Apr 12, 2016 at 10:22:21AM -0700, Daniel Leung wrote:
On Tue, Apr 12, 2016 at 10:22:13AM -0400, Benjamin Walsh wrote:
On Tue, Apr 12, 2016 at 09:12:19AM +0200, Tomasz Bursztyka wrote:Is this only about changing the APIs (like adding parameters, etc)?
Hi Daniel and Anas,I already got feedback from people developing either drivers or sample
Saving even a minimal amount of bytes is good to consider, as long
and all the existing drivers in one go as well.The init change will be in another RFC. I am testing locally to see how much
I hope we don't consider Kernel device API (init and stuff) as part of
space we can actually save. If it is minimal or non-existent, there is no need
to do that.
as it does not reduce
features etc... and that RFC is actually fixing things.
How long are we supposed to support this API 1.0? Can't we drop some
AFAIK, the device init interface is not API from my understanding. ApplicationIMO the driver interface is still considered public APIs.
should not be using these in their code. They are internal to the kernel and
Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers.
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. :(
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.
How about adding APIs (but still keep the existing API unmodified)?