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 benjamin.berg@intel.com
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.
johannes