On 10/2/26 04:38, Hajime Tazaki wrote: > > David, Lorenzo, Johannes, > > thanks for the comments and inputs. > > On Thu, 01 Oct 2026 19:01:45 +0900, > Johannes Berg wrote: >>> >>> 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. >
I assume there are plenty of other mechanisms. Like testing if fork isn't allowed. > 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. Let's avoid making it harder on users by doing some runtime detection. -- Cheers, David
