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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote:
> 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 ?
> 

This section is for bios=. I think it is better to not use "firmware" to
describe bios in the context of Xen. It's easy to confuse this with
firmware_override.

> > +=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 ?
> 

Correct.

> 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.
> 

It isn't clear to me either, hence the RFC tag in this patch.

Currently libxl doesn't care about kernel= or initrd= and passes them
directly to libxc. Libxc then just opens the path so it effectively
supports relative paths.

But for firmware_override, libxl massages the path before passing to
libxc. Libxl forbids relative paths in current code.

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

Yes, I agree.

How about we decide that libxl will search for files in the following
order if the string is not an absolute path:

1. current working directory
2. Xen specific directory (case by case, if applicable)

And then we document, for each xl.cfg option, the search path. Also we
encourage people to use absolute path for consistent results.

Thoughts?

Wei.

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