On Mon, Mar 10, 2014 at 02:28:20PM +0100, Pino Toscano wrote:
Add the possibility to choose which architecture use to build the
wanted
image (--arch). Since this implies that running commands on the guest is
usually not possible when the architecture is different than the host
one, another new option (--allow-foreign-arch-ops) allows to run
commands nevertheless.
[..]
+let filter_arch = function
+ | "amd64" | "x86_64" | "x64" -> "x86_64"
+ | "powerpc" | "ppc" -> "ppc"
+ | "armhfp" | "armhf" -> "armhf"
I don't think "armhf" is a thing. AFAIK all ARM hard float architectures
would be ARM v7 (or ARM v8, but that's separate).
For reference, RPM's architectures are:
$ rpm --eval %{arm}
armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7hnl
(Of which no one cares about anything < armv7, and by the end of next
year no one will care about anything < armv8).
diff --git a/builder/cmdline.ml b/builder/cmdline.ml
index 6e8bfd8..0dd0ad2 100644
--- a/builder/cmdline.ml
+++ b/builder/cmdline.ml
@@ -44,6 +44,9 @@ let parse_cmdline () =
let print_cache_mode () = mode := `Print_cache in
let delete_cache_mode () = mode := `Delete_cache in
+ let arch = ref "" in
+ let allow_foreign_arch_ops = ref false in
Can't we detect allow_foreign_arch_ops automatically?
For normal uses of libguestfs, the only case that matters is a 32 bit
requested guest architecture on a compatible 64 bit host (eg. ppc on
ppc64 host). So a simple mapping table of host architecture ->
compatible guest architectures, and drop the option.
diff --git a/builder/uname-c.c b/builder/uname-c.c
I would have just done:
List.hd (external_command "uname -m")
but now you've written the FFI code, that's fine :-)
The rest of the patch looks OK to me.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v