Riku Voipio <riku.voi...@iki.fi> wrote on 2014/09/01 11:51:15: > > On Mon, Sep 01, 2014 at 10:12:18AM +0100, Peter Maydell wrote: > > On 1 September 2014 09:51, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > Il 29/08/2014 20:01, Peter Maydell ha scritto: > > >> [cc'ing MJT for more distro opinion since I think fundamentally > > >> the choice we ought to make upstream is "what's not going to > > >> screw over distros"... Paolo, is there a RedHat QEMU maintainer > > >> who would have an opinion here?] > > > > > > There's Cole Robinson. > > > > > > BTW, Fedora doesn't use the binfmt scripts from QEMU > > > > That's ok, nobody with any sense doesn't. > > > > >, but does reuse the > > > binfmt lines. We'd just add Ps and we'd be fine. > > > > But this would break all your existing users' existing > > chroot setups. That's the question I'm after an answer to: > > what do you (as a distro) think would be acceptable as > > transitional breakage, if anything? > > > > > However, the problem is not really for distros. Packagers just read the > > > release notes and adjust whatever needs to be adjusted. The problem is > > > for people who compile from source and are bit by conflicting binfmt > > > formats from their distro. > > Or people with chroots from older/different distros, already > having a qemu-static inside. > > > This is one reason I like the "one binary name for O and > > one for P" approach. > > Maybe the new binary name could be something more generic than qemu-x-binfmt. > Say qemu-x-user. Then distributions and users can drop the old binary > name over time, and we are back to one binary again eventually. > > > > The solution could be to extend binfmt_misc so that it sets two > > > environment variables BINFMT_MISC_PID and BINFMT_MISC_ORIG_ARGV0. The > > > former is set to the pid of the binfmt "interpreter" program, the latter > > > to the argv[0] value. Then QEMU can check if BINFMT_MISC_PID matches > > > getpid() and, if so, trust the BINFMT_MISC_ORIG_ARGV0 value. > > > Certainly if we're in a position to get the kernel to be more > > informative about how it invoked us that would be the ideal. > > There is AT_FLAGS, that seems unused atm (only ever set to 0). > > http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L240 > > As indeed I afree with Paolo that (in hindsight) it was misdesign for the > kernel to tell the application how it invoked us..
Did this go anywhere ? Is there a solution in sight? Jocke
