From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOOGc-0000JP-M5 for qemu-devel@nongnu.org; Mon, 01 Sep 2014 05:51:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOOGb-0005Ej-JO for qemu-devel@nongnu.org; Mon, 01 Sep 2014 05:51:18 -0400 Received: from [2001:4b98:dc0:45:216:3eff:fe3d:166f] (port=33230 helo=afflict.kos.to) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOOGb-0005EX-EB for qemu-devel@nongnu.org; Mon, 01 Sep 2014 05:51:17 -0400 Date: Mon, 1 Sep 2014 12:51:15 +0300 From: Riku Voipio Message-ID: <20140901095115.GA31799@afflict.kos.to> References: <20140825090917.GA14835@afflict.kos.to> <540433A8.5040509@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] linux-user: enabling binfmt P flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Joakim Tjernlund , Riku Voipio , Michael Tokarev , Alexander Graf , QEMU Developers , Cole Robinson , Paolo Bonzini On Mon, Sep 01, 2014 at 10:12:18AM +0100, Peter Maydell wrote: > On 1 September 2014 09:51, Paolo Bonzini 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.. Riku Riku