From patchwork Wed Apr 24 13:16:27 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 239224 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id ED1872C00F0 for ; Thu, 25 Apr 2013 00:59:54 +1000 (EST) Received: from localhost ([::1]:45968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UV1An-0006FY-1n for incoming@patchwork.ozlabs.org; Wed, 24 Apr 2013 10:59:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUzYz-0008MB-87 for qemu-devel@nongnu.org; Wed, 24 Apr 2013 09:16:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUzYu-0002Lj-9W for qemu-devel@nongnu.org; Wed, 24 Apr 2013 09:16:45 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:43103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUzYu-0002LD-3X for qemu-devel@nongnu.org; Wed, 24 Apr 2013 09:16:40 -0400 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UUzYr-0003mg-Qu from Thomas_Schwinge@mentor.com for qemu-devel@nongnu.org; Wed, 24 Apr 2013 06:16:37 -0700 Received: from SVR-IES-FEM-03.mgc.mentorg.com ([137.202.0.108]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Apr 2013 06:16:37 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-03.mgc.mentorg.com (137.202.0.108) with Microsoft SMTP Server id 14.2.247.3; Wed, 24 Apr 2013 14:16:35 +0100 From: Thomas Schwinge To: User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Wed, 24 Apr 2013 15:16:27 +0200 Message-ID: <87txmwoyqc.fsf@schwinge.name> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2013 13:16:37.0456 (UTC) FILETIME=[F35ABD00:01CE40ED] X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 X-Mailman-Approved-At: Wed, 24 Apr 2013 10:59:29 -0400 Cc: paul@codesourcery.com Subject: [Qemu-devel] Environment variables for user-mode QEMU X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Hi! We have a need to pass environment variable assignments containing commas to user-mode QEMU. The usage information currently says: You can use -E and -U options or the QEMU_SET_ENV and QEMU_UNSET_ENV environment variables to set and unset environment variables for the target process. It is possible to provide several variables by separating them by commas in getsubopt(3) style. Additionally it is possible to provide the -E and -U options multiple times. $ env -i x86_64-linux-user/qemu-x86_64 -E x=y,y=z /usr/bin/printenv y=z x=y Instead of this, we'd like to see: $ env -i x86_64-linux-user/qemu-x86_64 -E x=y,y=z /usr/bin/printenv x=y,y=z Due to the tokenization based on comma in linux-user/main.c:handle_arg_set_env, there is currently no way to achieve this -- other than pre-setting environment variables before running user-mode QEMU, which obviously isn't always desirable/possible (LD_LIBRARY_PATH, etc.). Assuming there is a consensus, how would you like this implemented? Is it OK to change the semantics of -E (as well as -U, for symmetry?) to not handle multiple environment variable assignments (preliminary patch below), or does that functionality need to be preserved? Something needs to be done about QEMU_SET_ENV and QEMU_UNSET_ENV then (if anyone is using these at all, which we can't disprove), as these are not very useful if they can handle only one environment variable. Or, should we perhaps have a new -env option that causes any later non-option arguments, that contain an equal sign, to be handled as environment variable assignments, just like the env command does? $ env -i x86_64-linux-user/qemu-x86_64 [some options] -env [more options] a=b,c d=e,f=a /usr/bin/printenv a=b,c d=e,f=a I think I might prefer that solution. As it is a new option, it also won't interfere with anyone's usage/expectations of the current behavior. Anyway, here is the incomplete patch, changing the behavior of -E and -U (as well as the corresponding QEMU_SET_ENV and QEMU_UNSET_ENV): Grüße, Thomas diff --git linux-user/main.c linux-user/main.c index 4e92a0b..62ff963 100644 --- linux-user/main.c +++ linux-user/main.c @@ -3204,26 +3204,16 @@ static void handle_arg_log_filename(const char *arg) static void handle_arg_set_env(const char *arg) { - char *r, *p, *token; - r = p = strdup(arg); - while ((token = strsep(&p, ",")) != NULL) { - if (envlist_setenv(envlist, token) != 0) { - usage(); - } + if (envlist_setenv(envlist, arg) != 0) { + usage(); } - free(r); } static void handle_arg_unset_env(const char *arg) { - char *r, *p, *token; - r = p = strdup(arg); - while ((token = strsep(&p, ",")) != NULL) { - if (envlist_unsetenv(envlist, token) != 0) { - usage(); - } + if (envlist_unsetenv(envlist, arg) != 0) { + usage(); } - free(r); } static void handle_arg_argv0(const char *arg)