Re: [PATCH v2 00/11] Start porting UML to nolibc

Hajime Tazaki
2025-09-23T23:58:53Z

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 <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.

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