Exactly! And that sounds like it would have been the smartest move from the start. Something like this doesn't need to be in the kernel. It doesn't need to be in glibc, and doesn't need to be in ld. There are probably performance advantages that you miss out on by using binfmt_misc, but that's the perfect way to get your solution working without any external dependencies. You create two userspace tools: 1) an app that stitches together multiple binaries into a FatELF file, and 2) a launcher program that, when given the path to a FatELF file, picks the correct embedded binary and runs it. #2 might need some fancy tricks with the dynamic loader, but it's certainly doable.
Assuming people do like it and use it, only then do you try to get it integrated into the system proper. Why try to push something into three pieces of software very core to Linux and Linux development when there's no evidence that there will be any developer, distro, or user adoption?
Exactly! And that sounds like it would have been the smartest move from the start. Something like this doesn't need to be in the kernel. It doesn't need to be in glibc, and doesn't need to be in ld. There are probably performance advantages that you miss out on by using binfmt_misc, but that's the perfect way to get your solution working without any external dependencies. You create two userspace tools: 1) an app that stitches together multiple binaries into a FatELF file, and 2) a launcher program that, when given the path to a FatELF file, picks the correct embedded binary and runs it. #2 might need some fancy tricks with the dynamic loader, but it's certainly doable.
Assuming people do like it and use it, only then do you try to get it integrated into the system proper. Why try to push something into three pieces of software very core to Linux and Linux development when there's no evidence that there will be any developer, distro, or user adoption?