From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZSi-0000yh-L2 for qemu-devel@nongnu.org; Fri, 22 Jan 2016 06:01:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMZSc-0006nr-II for qemu-devel@nongnu.org; Fri, 22 Jan 2016 06:01:04 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:49871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZSc-0006nm-8L for qemu-devel@nongnu.org; Fri, 22 Jan 2016 06:00:58 -0500 References: <1453091602-21843-1-git-send-email-petrosagg@gmail.com> <56A0AEF7.8060606@vivier.eu> <56A20571.5030309@vivier.eu> From: Laurent Vivier Message-ID: <56A20BDB.5080209@vivier.eu> Date: Fri, 22 Jan 2016 12:00:43 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] linux-user: add option to intercept execve() syscalls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: lucas.kaldstrom@hotmail.co.uk, Riku Voipio , Petros Angelatos , QEMU Developers Le 22/01/2016 11:47, Peter Maydell a écrit : > On 22 January 2016 at 10:33, Laurent Vivier wrote: >> Le 22/01/2016 11:01, Petros Angelatos a écrit : >>> This was my initial approach too, but argv[0] can be just the filename >>> like "qemu-arm-static". And while I could add extra logic to look this >>> up in the PATH, someone could run it from a completely different >>> location. Then I looked for a way to get the path of the current >>> executable but every platform has its own way of doing that and I >>> didn't want to add all these cases. >>> >>> https://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe >> >> linux-user works only on linux. >> qemu uses glib-2.0, so you can use g_find_program_in_path(). > > If QEMU was started via execle() to set the environment of the > executed process and that specified environment has a different > PATH, then g_find_program_in_path() will give the wrong answer. > Using AT_EXECFN (perhaps with a fallback to /proc/self/exe) seems > like a better approach to me. I agree, you can use getauxval(AT_EXECFN). >>> questions. Is it ok that I deleted part of the patch for my reply to >>> code review, or should I have replied inline without deleting >> >> Generally, it's better to not delete parts. So, someone tacking the mail >> thread at a moment can read the whole history in the last mail. > > I tend to happily delete parts and assume that readers have > access to the thread (via the archive or in their mail readers). > Not deleting bits makes it hard to read replies if there's > a conversation about a small part of a large patch. Yes, I do that also... :) Laurent