Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Hajime Tazaki <thehajime@gmail.com>]

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