On Wed, 12 Nov 2025 17:52:56 +0900, Hajime Tazaki wrote: [...] > > However, I'm not yet convinced that all of the complexities presented in > > this patchset (such as completely separate seccomp implementation) are > > actually necessary in support of _just_ the second bullet. These seem to > > me like design choices necessary to support the _first_ bullet [1]. > > separate seccomp implementation is indeed needed due to the design > choice we made, to use a single process to host a (um) userspace. I > think there is no reason to unify the seccomp part because the > signal handlers and filter installation do the different jobs. > > I don't see why you see this as a _complexity_, as functionally both > seccomp handling don't interfere each other. we have prepared > separate sub-directories for nommu to avoid unnecessary if/else > clauses in .c/.h files.
I have the same concern about the complexities introduced by this patch set. The new processing paths it introduces (such as the separate handling for FP/SSE/AVX, FS, signal, syscall, ...) add a lot of unnecessary complexities. I think Johannes's suggestion is a great idea. > we haven't seen any functional regressions > since this RFC version (which was 6.12 kernel). I took a quick look at the code. It appears that patch 02/13 will break the mmu build when UML_TIME_TRAVEL_SUPPORT is enabled. Regards, Tiwei
