Re: Isar v1.1 Release Candidate 2

["Roberto A. Foglietta" <roberto.foglietta@gmail.com>]

On Mon, 4 May 2026 at 12:02, Zhihang Wei <wzh@ilbers.de> wrote:
>
> Hi everyone,
>
> I have just tagged v1.1-rc2 as release candidate 2 for Isar v1.1.
>

Hi, I propose you consider a couple of patches of mine
for busybox to include in ISAR as external patches.

URL: https://github.com/robang74/busybox/tree/master/patches

patches/
- 0004-replacing-time-functions-for-thread-reentrant-safety-v2.patch

Replacing time functions for thread & reentrant safety, patchset v2

The listed changes following a static code inspection by one of
the most used automatic analyser and reported as critical flaws
but usually BusyBox is compiled static and leverages the fork()
magic which on modern architectures do a copy in memory of the
whole process by copy-on-write (CoW) optimisation.

The functions ctime(), gmtime() and localtime() which uses a static
buffer thus are not re-entrant / thread-safe, and in BusyBox their use
correctly addresses their limitation in the most common scenario above
depicted. However, fork() has its own use cases limitations as well.

The fork() isn't available on no-MMU architectures which usually rely
on vfork() while dynamic cpu/mem allocation in cloud infrastructure is
the opposite architecture spectrum edge in which fork() magic (CoW)
starts to face drawbacks. Plus libc-pthreaded despite being not common
are other cases in which reentrant / thread safety is required.

This patch replaces all those function with their _r() counterparts,
and move BusyBox development/ maintenance towards new frontiers, but
it brings also a penalty in terms of footprint increase:

       text    data     bss     dec     hex filename
    1155501   18124    2056 1175681  11f081 busybox
    1155856   18124    2056 1176036  11f1e4 busybox
    Total 19 fixes:            +355
    -Difference v2:             -57
    1155799   18124    2056 1175979  11f1ab busybox
    Total 19 fixes:            +298

Actually, it is 253 ppm on an almost-all-yes dynamic compiled BusyBox
but on a static linked ELF this figure can be halved or marginalised
by including a subset of commands. Below a static musl-compiled elf64
using more common commands subset:

       text    data     bss     dec     hex filename
     578882     855    6248  585985   8f101 bbox/busybox.elf
     578953     855    6248  586056   8f148 bbox/busybox.elf
    Total v1:                   +71

Moreover, LTO linking as well as milder optimisation than -Os like -O1
can have a 25-33% impact on the size but where CPU process caching is
a relevant factor that can speed up a process run in the way size-only
reduction cannot achieve.

Climbing a mountain starts with a first step towards it.


Best regards,

--
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/CAJGKYO4RJvyf6%3DRz3teCArSUKvmxwLto8tWXgz6O4Ek%2BESz2iQ%40mail.gmail.com.