public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Asias He <asias.hejun@gmail.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	kvm@vger.kernel.org, Avi Kivity <avi@redhat.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Prasad Joshi <prasadjoshi124@gmail.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [PATCH 1/2] kvm tools: Use '-c' for '--cpus', not '--console'
Date: Thu, 12 May 2011 09:17:45 +0200	[thread overview]
Message-ID: <20110512071745.GP3191@elte.hu> (raw)
In-Reply-To: <4DCB3336.5060401@gmail.com>


* Asias He <asias.hejun@gmail.com> wrote:

> On 05/12/2011 02:01 AM, Pekka Enberg wrote:
> > This patch changes the '-c' command line option to specify the number of CPUs
> > because it's used more often than console switching.
> 
> I'd like to tune the command line option further.
> 
> 1)
> Change
>     -i, --image <image>   Disk image
> to
>     -d, --disk  <disk>	  Disk image

Agreed.

> 2)
> Change
>     -r, --initrd <initrd>
>                           Initial RAM disk image
> to
>     -i, --initrd <initrd>
>                           Initial RAM disk image

Agreed.

> 3)
> Change
>     -d, --kvm-dev <kvm-dev>
>                           KVM device file
>     -s, --single-step     Enable single stepping
>     -g, --ioport-debug    Enable ioport debugging
> to
>         --kvm-dev <kvm-dev>
>                           KVM device file
>         --single-step     Enable single stepping
>         --ioport-debug    Enable ioport debugging

Yeah, it would be nice to free up -d, -s, -g.

The debug options should probably be concentrated under a --debug option 
anyway, to allow things like:

 --debug single-step,ioport

Even if the debug options are kept they should be streamlined along the same 
pattern:

>         --debug-single-step     Enable single stepping
>         --debug-ioport          Enable ioport debugging

But having a --debug option that recognizes all the debug flags would be nicer.

It would also allow future enhancements to group debug features, like:

  --debug all                # turn on everything and the kitchen sink for early hangs
  --debug all,-single-step   # turn on everything except single-step debugging
  --debug nonverbose         # turn on all non-noisy debug options we have

Maybe even:

  --debug memcheck

... could run kvm under valgrind automatically - that way we can hide any 
secondary tool complexities from the user and turn those tools into simple 
debug options :-)

etc.

> So we can have
> 	-c --cpus
> 	-m --mem
> 	-d --disk
> 	-k --kernel
> 	-i --initrd
> which is more consistent and easy to remember.

Very nice plans!

The sooner we do this the fewer people will have to change their scripts and 
practices.

Thanks,

	Ingo

  reply	other threads:[~2011-05-12  7:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 18:01 [PATCH 1/2] kvm tools: Use '-c' for '--cpus', not '--console' Pekka Enberg
2011-05-11 18:01 ` [PATCH 2/2] kvm tools: Print out important command line options at startup Pekka Enberg
2011-05-12  1:09 ` [PATCH 1/2] kvm tools: Use '-c' for '--cpus', not '--console' Asias He
2011-05-12  7:17   ` Ingo Molnar [this message]
2011-05-12 13:20     ` Asias He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110512071745.GP3191@elte.hu \
    --to=mingo@elte.hu \
    --cc=asias.hejun@gmail.com \
    --cc=avi@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=penberg@kernel.org \
    --cc=prasadjoshi124@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox