Re: [Libguestfs] [PATCH] builder: complete architecture handling

Pino Toscano
Tue, 11 Mar 2014 14:42:04 -0000

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