[Libguestfs] [PATCH] builder: complete architecture handling

Pino Toscano ptoscano at redhat.com
Tue Mar 11 14:42:04 UTC 2014


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




More information about the Libguestfs mailing list