On Thu, Jul 03, 2014 at 03:26:09PM +0200, Maxime Villard wrote: > > Being able to automatically invoke a suitable emulator for user > > binaries of the wrong OS and/or architecture would be very helpful for > > crossbuilding difficult packages. > > But this isn't related to the priority problem, right?
Right, I think Justin mentioned it just because it was worth mentioning and tangentially related. > Perhaps I haven't been clear enough; the question is: > > - exec_elf32 is a module, and is enabled with EXEC_ELF32 (#define). > - exec_elf32 (module) is dormant on 64bit systems. > - linux32 and netbsd32 *don't need* exec_elf32 (module), but need > EXEC_ELF32 (#define). > - my plan is to keep EXEC_ELF32 defined on 64bit systems, but to disable > exec_elf32 (module). > - Problem: linux32 has exec_elf32 (module) as dependency. > - Question: do I remove this dependency, given the fact that netbsd32 > too does not have it? Well ok. It looks to me like the problem is that the EXEC_ELF32 and EXEC_ELF64 code each provides a "native" struct execsw entry, but obviously only one of them can be native at once so the other one won't ever work. It seems like the solution, then, is to take the "native" struct execsw entries out of the EXEC_ELF32 and EXEC_ELF64 code, and instead always provide a single native struct execsw entry in exec_elf.c based on ARCH_ELFSIZE. That will always work for native binaries, and a 64-bit machine with compat32 (of whatever flavor) will load one or more additional execsw entries via compat32 that use compat32. And then the compat_linux32, compat_netbsd32, etc. can all depend on the EXEC_ELF32 module like they need to. AIUI, btw, it is wrong for this dependency to depend on whether EXEC_ELF32 is defined during compilation; theoretically if EXEC_ELF32 is compiled into the kernel the module should still depend on it and will still "load" it properly. (However, it's possible that the reason such logic is in place is that this doesn't actually work in practice.) The question is whether taking the "native" execsw entries out of the EXEC_ELF32 and EXEC_ELF64 code will break the module system. I'm not clear on this. -- David A. Holland [email protected]
