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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope 
with relative path"):
> 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.

Oh!  Yes, right, of course.

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

SGTM.

I wonder if we should be able to specify to libxl to "please don't use
relative paths" (or even "relative paths are relative to this
specified location").  libxl might be embedded in another program
whose cwd can't be adjusted and shouldn't be relied on.

Ian.

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