On Tue, Jan 24, 2017 at 10:57:21AM -0500, Anas Nashif wrote:
On Fri, Jan 20, 2017 at 7:09 AM, Szymon Janc <ext.szymon.janc(a)tieto.com>
Hi,The reason why we have minimal libc... it did the job for a basic kernel
On Fri, Jan 20, 2017 at 12:21 PM, Anas Nashif <nashif(a)gmail.com> wrote:
On Fri, Jan 20, 2017 at 5:26 AM, Marcus Shawcroft <
utilize PRIu32. The fact that newlib and minimal libc different in the way
On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:
As Anas said, I don’t think we can expect 3rd party software to
the typedef (u)int32_t seems like a pointless difference for us to maintain
and have to deal with a lot of pain if one switches between them.
This is not a choice between alternatives. There are two separate
1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.
We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under
and apply 2, the question is if we want to enforce usage of PRI macros.
Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.
But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).
That sounds reasonable to me. Change minimal libc to align with newlib
A bit off topic, but could someone shed some light on why Zephyr has
support for two libc implementations?
ie Why not just always use newlib ?
implementation and mostly was used only for testing the kernel internals.
It is also a control we have (had), making sure the kernel does not rely on
libc functions and is self-contained. There is lots of history behind that,
probably Ben can add to this :-)
That's basically it.
IMHO, I think that this reasoning was bogus anyway, and only meant we
had (probably worse) re-implementation of some libc routines, with
different names, or not. :-/
Over the last 2 years I have seen developers implement clones of libc
functions to overcome the lack of support of those functions in the minimal
libc. We have been adding libc function on individual basis, sometimes
pulling those functions from different sources creating a frankenstein libc
implementation that will be difficult to maintain going forward.
Given that the zephyr project now is more than just a kernel and that any
application based on Zephyr will most likely want to use newlib anyways, I
do not think there is a reason why we should continue using minimal libc as
the default, we need however to keep an eye on usage of libc functions
inside the kernel and monitor the footprint (ram and rom) if we follow this