On 09/11/2013 08:13 AM, Giuseppe Scrivano wrote:
> Signed-off-by: Giuseppe Scrivano <gscrivan@xxxxxxxxxx>
> ---
> tools/virsh-host.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> tools/virsh.pod | 5 +++++
> 2 files changed, 59 insertions(+)
> +
> +static const vshCmdOptDef opts_cpu_models[] = {
> + {.name = "arch",
> + .type = VSH_OT_DATA,
> + .flags = VSH_OFLAG_REQ,
> + .help = N_("architecture")
> + },
Question: would it make sense to have --arch be optional, and to default
it to the arch learned by uname() if not present? I guess for local
systems, that's a convenience factor; for remote systems, it's not quite
the right thing (using virsh on a ppc box to manage a libvirtd on an
x86_64 box for example). Or maybe if --arch is optional, we call
GetCapabilities under the hood, and enumerate over ALL possible arches
scraped from the capabilities (of course, with slightly different output
layout to distinguish which model names correspond to which arches)?
That could be a followup patch, though.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list