On Thu, Apr 21, 2022 at 08:52:59AM +0200, Geert Uytterhoeven wrote:
On Thu, Apr 21, 2022 at 1:53 AM Greg Ungerer gerg@linux-m68k.org wrote:
On 21/4/22 00:58, Eric W. Biederman wrote:
In a recent discussion[1] it was reported that the binfmt_flat library support was only ever used on m68k and even on m68k has not been used in a very long time.
The structure of binfmt_flat is different from all of the other binfmt implementations becasue of this shared library support and it made life and code review more effort when I refactored the code in fs/exec.c.
Since in practice the code is dead remove the binfmt_flat shared libarary support and make maintenance of the code easier.
[1] https://lkml.kernel.org/r/81788b56-5b15-7308-38c7-c7f2502c4e15@linux-m68k.or... Signed-off-by: "Eric W. Biederman" ebiederm@xmission.com
Can the binfmt_flat folks please verify that the shared library support really isn't used?
I can definitely confirm I don't use it on m68k. And I don't know of anyone that has used it in many years.
Was binfmt_flat being enabled on arm and sh the mistake it looks like?
I think the question was intended to be
Was *binfmt_flat_shared_flat* being enabled on arm and sh the mistake it looks like?
Early in my work on j2, I tried to research the history of shared flat support on sh, and it turned out the mainline tooling never even supported it, and the out-of-line tooling I eventually found was using all sorts of wrong conditionals for how it did the linking and elf2flt conversion, e.g. mere presence of any PIC-like relocation in any file made it assume the whole program was PIC-compatible. There's no way that stuf was ever used in any meaningful way. It just didn't work.
Quickly dropped that and got plain ELF (no shared text/xip, but no worse than the existing flat support) working, and soon after, FDPIC.
The whole binfmt_flat ecosystem is a mess with no good reason to exist.
Rich