On Wed, Apr 20, 2022 at 12:59:37PM -0400, Rich Felker wrote:
On Wed, Apr 20, 2022 at 09:17:22AM -0700, Palmer Dabbelt wrote:
On Wed, 20 Apr 2022 07:58:03 PDT (-0700), ebiederm@xmission.com 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 don't actually know follow the RISC-V flat support, last I heard it was still sort of just in limbo (some toolchain/userspace bugs th at needed to be sorted out). Damien would know better, though, he's already on the thread. I'll leave it up to him to ack this one, if you were even looking for anything from the RISC-V folks at all (we don't have this in any defconfigs).
For what it's worth, bimfmt_flat (with or without shared library support) should be simple to implement as a binfmt_misc handler if anyone needs the old shared library support (or if kernel wanted to drop it entirely, which I would be in favor of). That's how I handled old aout binaries I wanted to run after aout was removed: trivial binfmt_misc loader.
Yeah, I was trying to understand why systems were using binfmt_flat and not binfmt_elf, given the mention of elf2flat -- is there really such a large kernel memory footprint savings to be had from removing binfmt_elf?
But regardless, yes, it seems like if you're doing anything remotely needing shared libraries with binfmt_flat, such a system could just use ELF instead.