Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope with 
relative path"):
> And also document that option in xl.cfg(5).
...
> -Select the virtual firmware that is exposed to the guest.
> +Select the virtual bios that is exposed to the guest.
>  By default, a guess is made based on the device model, but sometimes
>  it may be useful to request a different one, like UEFI.

hvmloader is surely not a `virtual bios' for two reasons: one is that
technically something like UEFI firmware is not a bios.  The other is
that hvmloader is responsible for doing some other stuff too, AIUI ?

> +=item B<firmware_override="STRING">
> +
> +Override the virtual firmware provided by Xen. The value can be an
> +absolute or relative path to a file.
> +
> +If the value is a relative path, searching is frist done in current
> +working directory then Xen firmware directory.
> +
> +If not set, the default hvmloader is used.

I think we want a bit more justification, and consideration, here, at
least.  This is changing libxl so that the cwd of the process at the
time libxl_domain_create is called is relevant.  AFAICT it mostly
isn't right now ?

I looked at xl.cfg(5) and the use of the cwd is not documented for any
of the other parameters.  There are a bunch of other libxl__abs_path
calls.

So err, I guess, I think I would like to see a wider consideration of
relative path semantics in libxl, and the corresponding docs.

> +        if (info->u.hvm.firmware && !stat(firmware, &stab))
> +            firmware_path = firmware;

Failure to check errno.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel