From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM2lp-0002Qp-T5 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:34:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM2ll-0002O1-12 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:34:53 -0400 Received: from [199.232.76.173] (port=40435 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM2lk-0002Nq-Pb for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:34:48 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57712) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM2lk-0004BC-8n for qemu-devel@nongnu.org; Wed, 01 Jul 2009 12:34:48 -0400 Date: Wed, 1 Jul 2009 13:34:06 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH] Allow setting qemu process name Message-ID: <20090701133406.3f7bef81@doriath> In-Reply-To: <4A4B8E86.8060501@redhat.com> References: <20090701093251.GA12447@basil.fritz.box> <4A4B64B2.3040106@codemonkey.ws> <4A4B7BC6.8080407@redhat.com> <20090701131921.248b7bdd@doriath> <4A4B8E86.8060501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Andi Kleen , qemu-devel@nongnu.org On Wed, 01 Jul 2009 19:27:50 +0300 Avi Kivity wrote: > On 07/01/2009 07:19 PM, Luiz Capitulino wrote: > >>> Andi Kleen wrote: > >>> > >>>> [this is a port of a old KVM userland patch I had; Avi back then > >>>> suggested to submit it to qemu] > >>>> > >>>> Set the Linux process name to the name argument specified with > >>>> "-name". I find > >>>> this useful to see which guests are taking CPU time in top. > >>>> > >>> This is not a bad idea but it has to be optional and non-default. > >>> Maybe a new command line option? > >>> > >> -name [title=]blah[,process=foobar] > >> > > > > Just a question: do we have a plan on stopping/avoiding adding new > > command-line options? > > > > Not at all. But it makes sense to group related features into a single > command line option IMO. Sure, it's seems better to me as well. I'm just curious on what we are going to do for new features that requires configurable options. The command-line we have is already quite big...