Hello Benjamin, Johannes,
On Mon, 22 Sep 2025 16:41:36 +0900, Johannes Berg wrote: > > On Fri, 2025-09-19 at 08:40 -0700, Christoph Hellwig wrote: > > On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote: > > > From: Benjamin Berg <[email protected]> > > > > > > This patchset is an attempt to start a nolibc port of UML. > > > > It would be useful to explain why that is desirable. > > Agree, it should be here, but FWIW it's been discussed elsewhere on the > linux-um list in the past and basically there are various issues around > it. Off the top of my head: > - glibc enabling new features such as rseq that interact badly with how > UML manages memory (there were fixes for this, it worked sometimes > and sometimes not) > - allocation placement for TLS is problematic (see the SMP series) > - it's (too) easy to accidentally call glibc functions that require > huge amounts of stack space > > There are probably other reasons, but the mixed nature of UML being both > kernel and "hypervisor" code in a single place doesn't mix well with > glibc. just curious - are those issues not happening in other libc implementation ? (e.g., musl-libc) - same question to nolibc: is there any possibility that nolibc will evolve as glibc does, and this evolution introduces the UML issues ? -- Hajime
