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
next prev parent 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