On Sat, 14 Dec 2024 06:53:44 +0900, Eric W. Biederman wrote: > > config BINFMT_ELF > > bool "Kernel support for ELF binaries" > > - depends on MMU > > select ELFCORE > > default y > > help > > @@ -58,7 +57,7 @@ config ARCH_USE_GNU_PROPERTY > > config BINFMT_ELF_FDPIC > > bool "Kernel support for FDPIC ELF binaries" > > default y if !BINFMT_ELF > > - depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU) > > + depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) > > select ELFCORE > > help > > ELF FDPIC binaries are based on ELF, but allow the individual load > > You have my apologies I was most definitely confused. BINFMT_ELF > currently does not work without an MMU. no problem. > >> I just react a little strongly to the assertion that elf_fdpic is > >> the only path when I don't see why that should be. > >> > >> Especially for an architecture like user-mode-linux where I would expect > >> it to run the existing binaries for a port. > > > > I understand your concern, and will try to work on improving this > > situation a bit. > > > > Another naive question: are there any past attempts to do the similar > > thing (binfmt_elf without MMU) ? > > At this point what I would recommend is: > > Merge your original patch. Get nommu UML working with binfmt_elf_fdpic.c. > I think it is a proper superset of ELF functionality. > > Then I would make it a long term goal to see about removing redundancy > between binfmt_elf.c and binfmt_elf_fdpic.c with a view to merging them > in the long term. > > There is a lot of mostly duplicate code between the two and > binfmt_elf_fdpic.c does not get half the attention and use binfmt_elf.c > gets. thanks for the recommendation. I'll go for this direction. It would be great if nommu arch (at least) UML can use the regular binfmt_elf. -- Hajime
