Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>

On 25 January 2017 at 11:57, Marcus Shawcroft
<marcus.shawcroft(a)> wrote:
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?
Incidentally, there is work going on in newlib upstream at the moment
to provide more flexible support for re-targeting such locking
mechanisms in pre-built binary toolchains. This was (at least partly)
motivated by the mbed-os team realizing that they could not sensibly
wire up locking/reentrancy support when using the pre-canned newlib
binaries shipped with generic arm-none-eabi toolchains...


Join to automatically receive all group messages.