On Tuesday 11 March 2014 10:09:45 Richard W.M. Jones wrote:
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).
In Debian do exists only the following two architectures:
- "armel", arm EABI with only soft-float support, for older arm's
- "armhf", EABI with hard-float support
see also:
https://wiki.debian.org/ArmHardFloatPort#Name_of_the_port
I remember having seen "armhfp" for Fedora, so I though about flattening
all together. Maybe it could be better to just ignore the complex arm
situation for now, and let the users input the exact architecture they
need.
> 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.
Sounds sensible, will do.
> 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 :-)
I'm starting to think that in the next stable series (say 1.27/1.28) we
could require ExtUnix, and get rid of the FFI codes we currently have
(setlocale, fsync, mkdtemp, statvfs, and now uname).
--
Pino Toscano