David, Lorenzo, Johannes,
thanks for the comments and inputs. On Thu, 01 Oct 2026 19:01:45 +0900, Johannes Berg wrote: > > > $ make ARCH=um NOMMU=1 O=build kselftest-all TARGETS=nommu > > > > $ make ARCH=um NOMMU=1 O=build kselftest-install TARGETS=nommu > > > > $ NOMMU=1 ./build/kselftest/kselftest_install/run_kselftest.sh -p \ > > > > -c nommu > > > > > > Is there a way we could derive that from the environment in one of these > > > cases? > > > > I thought maybe uname could help but our LLM overlords tell me no. > > Hajime originally wanted uname to indicate it, but that caused > regressions elsewhere, so we dropped that commit. I guess we could put > _something_ back? systemd uses uname information and our (old) patch changing the format triggered the regression. thus, we dropped it. > > It pointed at something though. > > > > In fs/proc/meminfo.c: > > > > #ifndef CONFIG_MMU > > show_val_kb(m, "MmapCopy: ", > > (unsigned long)atomic_long_read(&mmap_pages_allocated)); > > #endif > > > > So MmapCopy in /proc/meminfo tells us definitively, weirdly enough. > > Hyrum's law and all that, but I guess it's not highly likely to (want > to) change :) a runtime detection is nice. scanning /proc/meminfo might be useful. although it requires to mount procfs (we can actually skip procfs mount as it is optional) so, this is not 100% portable. checking ENOSYS like syscall(SYS_mprotect) might be useful but I wasn't sure if this is always the case of NOMMU or not. My original attempt was to use include/generated/autoconf.h; with that we can omit environmental variable or command argument of NOMMU=1, but gave up with handling standalone build/test case which might miss the generated file (and complicate the patch only for the NOMMU detection). So, specifying NOMMU=1 is my previous, though dirty, conclusion. -- Hajime
