pthread_mutex_init() just redirects to Zephyr kernel primitive, for
initializing structure fields. So, use the knowledge that it can't
fail (for as long as structure pointer is initialized, and here it's
from pre-allocated array), and ignore return value of
pthread_mutex_init()
Coverity-CID: 203542
Fixes: #18371
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
The solution from #14312 of using -isystem to prioritize the position of
the libc directory bypasses the effect of -ffreestanding with respect to
libc symbols expected to be present in a non-hosted environment.
Further, it breaks C++ with the ARM Embedded toolchain as the system
fails to find the right file with #include_next.
Use a more fine-grained solution that explicitly includes the underlying
newlib header required for <inttypes.h> support before moving on to
include the next available one, whether system or non-system.
Closes#17564
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Follow the approach of newlib to use a file sys/_types.h to specify the
underlying type for POSIX/libc types that must be provided in multiple
headers. The identifier for this type is in the reserved namespace.
Use this type rather than a specific standard type in all headers that
need to provide the type under its public name.
Remove the inclusion of <sys/types.h> from headers that should not bring
in all symbols present in that header, replacing it with the standard
boilerplate to expose the specific symbols that are required.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
time_t and suseconds_t are defined in time.h and sys/types.h. Handle
the duplication by adding ifdef protection around them similar to what
is being done for other types.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Similar to how other sub-libraries are defined in Zephyr tree, e.g.
"fs", "lgvl", etc. This is supposed to help with the need to
explicitly add posix include path to each and every application using
POSIX subsys.
Fixes: #15627
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
This is consistent with how newlib headers are treated, and will
have effect of ninlibc headers to be further down in the include
order. This is important, because some POSIX subsys headers
override those of libc. Without this change, we can't streamline
POSIX build config using zephyr_interface_library_named() cmake
directive, because includes will be in wrong order.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Historically, it used to be "PTHREAD", which is no longer true, as
POSIX subsys offers much more functionality than just Pthreads. Use
detailed name, like "posix_subsys", to avoid possible confusion with
ARCH_POSIX-related matters.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.
Redirects for the web documentation are also included.
Then zephyrbot complained about this:
"
New files added that are not covered in CODEOWNERS:
dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi
Please add one or more entries in the CODEOWNERS file to cover
those files
"
So I assigned them to those who created them. Feel free to readjust
as necessary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
These functions are useful for determining prefixes, as with file system
paths. They are required by littlefs.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
struct tm has fields that were not being set by the implementation,
causing the test to fail when the uninitialized values were compared
with a static initialized result. Zero the structure before filling it.
Closes#17794
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
By the latest convention, libc's define struct timespec in
sys/_timespec.h. This is consistent with Newlib and ensures
about errors due to redefinitions.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Per POSIX, open() is defined in <fcntl.h>. fcntl.h in turn comes from
the underlying libc, either newlib, or minimal libc.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
That's the header which is supposed to define them, there was even
FIXME on that in mqueue.h.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
POSIX subsys defines struct timespec in <time.h> (as POSIX public
API requires), but newlib defines in in sys/_timespec.h, which
inevitably leads to inclusion order and redifinition conflicts.
Follow newlib way and define it in single place, sys/_timespec.h,
which belongs to libc namespace. Thus, we move current definition
to minimal libc, and will use either minlibc's or newlib's
definition, instead of trying to redefine it.
This is similar to the introduction of sys/_timeval.h done earlier.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Newlib libc already provides sys/stat.h, so trying to have sys/stat.h
on the level of POSIX subsys inevitable leads to include order and
definition conflicts. Instead (as most of other sys/* includes)
should come from the underlying libc.
While moving, made unrelated change of removing #include <kernel.h>,
to accommodate the change reviewers.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
For systems with userspace, the sys_sem exist in user memory working
as counter semaphore for user mode thread. The implemention of sys_sem
is based on k_futex. And the majority of the synchronization operations
are performed in user mode to reduce the calling of system call.
And for systems without userspace enabled, sys_sem behaves like k_sem.
Fixes: #15139.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
User mode isn't allowed to generate a panic and this would
lead to a confusing privilege violation exception.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Add a generic API to provide the inverse operation for gmtime and as a
home for future generic time-related functions that are not in POSIX.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Implement the conversion from UNIX time to broken-down civil time per
the gmtime() and gmtime_r() functions.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Provide definitions for a subset of the standard time types that must be
provided by this file, in anticipation of supporting civil time in
Zephyr.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The mempool allocator implementation recursively breaks a memory block
into 4 sub-blocks until it minimally fits the requested memory size.
The size of each sub-blocks is rounded up to the next word boundary to
preserve word alignment on the returned memory, and this is a problem.
Let's consider max_sz = 2072 and n_max = 1. That's our level 0.
At level 1, we get one level-0 block split in 4 sub-blocks whose size
is WB_UP(2072 / 4) = 520. However 4 * 520 = 2080 so we must discard the
4th sub-block since it doesn't fit inside our 2072-byte parent block.
We're down to 3 * 520 = 1560 bytes of usable memory.
Our memory usage efficiency is now 1560 / 2072 = 75%.
At level 2, we get 3 level-1 blocks, and each of them may be split
in 4 sub-blocks whose size is WB_UP(520 / 4) = 132. But 4 * 132 = 528
so the 4th sub-block has to be discarded again.
We're down to 9 * 132 = 1188 bytes of usable memory.
Our memory usage efficiency is now 1188 / 2072 = 57%.
At level 3, we get 9 level-2 blocks, each split into WB_UP(132 / 4)
= 36 bytes. Again 4 * 36 = 144 so the 4th sub-block is discarded.
We're down to 27 * 36 = 972 bytes of usable memory.
Our memory usage efficiency is now 972 / 2072 = 47%.
What should be done instead, is to round _down_ sub-block sizes
not _up_. This way, sub-blocks still align to word boundaries, and
they always fit within their parent block as the total size may
no longer exceed the initial size.
Using the same max_sz = 2072 would yield a memory usage efficiency of
99% at level 3, so let's demo a worst case 2044 instead.
Level 1: 4 sub-blocks of WB_DN(2044 / 4) = 508 bytes.
We're down to 4 * 508 = 2032 bytes of usable memory.
Our memory usage efficiency is now 2032 / 2044 = 99%.
Level 2: 4 * 4 sub-blocks of WB_DN(508 / 4) = 124 bytes.
We're down to 16 * 124 = 1984 bytes of usable memory.
Our memory usage efficiency is now 1984 / 2044 = 97%.
Level 3: 16 * 4 sub-blocks of WB_DN(124 / 4) = 28 bytes.
We're down to 64 * 28 = 1792 bytes of usable memory.
Our memory usage efficiency is now 1792 / 2044 = 88%.
Conclusion: if max_sz is a power of 2 then we get 100% efficiency at
all levens in both cases. But if not, then the rounding-up method has
a far worse degradation curve than the rounding-down method, wasting
more than 50% of memory in some cases.
So let's round sub-block sizes down rather than up, and remove
block_fits() which purpose was to identify sub-blocks that didn't
fit within their parent block and is now useless.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Since commit 39cd2ebef7 ("malloc: make sure returned memory is
properly aligned") the size of struct sys_mem_pool_block size is
rounded up to the next word boundary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Move duplicate hex2bin and add bin2hex function so that application can
use the functions and avoid code duplication.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
The space or plus prefix must appear when requested even with INF and
NAN. And no zero-padding in that case.
Also, 0.0 and -0.0 are distinct values. It is necessary to display
the minus sign with a negative zero.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The precision parameter to the %g conversion indicates the maximum
number of significant digits and not the number of digits to appear
after the radix character. Here's a few examples this patch fixes:
expected before
----------------------------------------------------------
printf("%.3g", 150.12) 150 150.12
printf("%.2g", 150.1) 1.5e+02 150.1
printf("%#.3g", 150.) 150. 150.000
printf("%#.2g", 15e-5) 0.00015 0.00
printf("%#.4g", 1505e-7) 0.0001505 0.0002
printf("%#.4g", 1505e-8) 1.505e-05 1.5050e-05
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The code accounts only for 2 exponent digits even though the exponent
may grow up to 308. Before this change, printf("%g", 1e300) would
produce "1e+N0".
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The on-stack work buffer occupies 201 bytes by default. Now that we've
made the code able to cope with virtually unlimited width and precision
values, we can reduce stack usage to its strict minimum i.e. 25 bytes.
This allows for some additional sprintf tests exercizing wide results.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Even if the code used to limit the precision to the on-stack buffer
size, it was still possible to do:
printf("%f", 1.0e300);
which would overflow the stack and crash the program. Let fix this issue
and remove the precision limitation by recording the number of zeroes to
insert while converting the value and generating those zeroes only
when outputting the data.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Zero-padding of integers took place in the on-stack buffer before
justification. Let's perform that padding on the fly while sending
out data instead.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The z_prf() function currently allocates a 200-byte buffer on the
stack to copy strings into, and then perform left/right alignment
and padding. Not only this is a pretty large chunk of stack usage,
but this imposes limitations on field width and string length. Also
the string is copied not only once but _thrice_ making this code
less than optimal.
Let's rework the code to get rid of both the field width limit and
string length limit, as well as the two extra memory copy instances.
While at it, let's fixes printf("%08s", "abcd") which used to
produce "0000abcd".
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Mimic the glibc behavior when encountering an unknown conversion
specifier rather than silently skipping it.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This makes for nicer code by avoiding repetitions of the same pattern.
Changes to come will make more use of it.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Some cleanups before further changes:
- Remove dead leftover from the "case 's'" code.
- Remove needless parents and casts.
- Remove "register" qualifier as it is ignored. The compiler knows
better these days.
- Adjust tabs assuming standard 8-columns tab spacing.
- Make multi-line comments start with "/*" on a line of its own.
- Make the format string const to match prototypes in other files.
- Declare boolean variable and parameters as bool.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This reverts commit 2a63e342f4.
This needs to be reverted as otherwise the type of ssize_t will be
"unsigned long" which is not correct.
(gdb) ptype ssize_t
type = unsigned long
For example this check would fail in that case
ssize_t foo(void)
{
return -1;
}
...
if (foo() < 0) {
printk("This is never called\n");
}
Fixes#17378
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Removed lvgl sources from CMakefile.txt and only keep zephyr glue
logic.
Further added lvgl module to west.yml.
Signed-off-by: Jan Van Winkel <jan.van_winkel@dxplore.eu>
Compilers (at least gcc and clang) already provide max value definitions
for basic types. It makes sense to rely on them to properly support
both 32-bit and 64-bit builds.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The accounting data stored at the beginning of a memory block used by
malloc must push the returned memory address to a word boundary. This
is already the case on 32-bit systems, but not on 64-bit systems where
e.g. struct k_mem_block_id still has a size of 4.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The current CMSIS v2 implementation is clearly assuming that timeout
arguments being passed to e.g. osDelay() are in units of Zephyr ticks,
not milliseconds as specified by ARM or (inconsistently) assumed by
our test code.
Most tests work with the ~100 Hz default tick rate, but they tend to
fail on precision issues at higher tick rates. Force the CMSIS v2
applications to be 1000 Hz for now as a workaround, and detect the
mismatch as a build failure.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The "bits" field in struct sys_mem_pool_lvl is unioned with a pointer.
That leaves more space for inline free bits on 64-bit targets.
Let's declare it as an array and adjust its size based on the pointer
size. On 32-bit targets the generated code remains identical.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Andrew Boie