Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>

On 24 January 2017 at 15:57, Anas Nashif <nashif(a)> wrote:

The reason why we have minimal libc... it did the job for a basic kernel
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 :-)

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
Newlib has a re-entrancy support/infranstructure that needs porting to
the platform in order to get thread safety, I know that such porting
work for zephyr is not in upstream newlib, have we done that work in
the SDK?


Join to automatically receive all group messages.