[libvirt] [PATCH 4/6] bhyve: enumerate UEFI firmwares

[Roman Bogorodskiy]

  Daniel P. Berrange wrote:

> On Sun, Feb 12, 2017 at 07:12:32PM +0400, Roman Bogorodskiy wrote:
> > From: Fabian Freyer <fabian.freyer at physik.tu-berlin.de>
> > 
> > Signed-off-by: Roman Bogorodskiy <bogorodskiy at gmail.com>
> > ---
> >  src/bhyve/bhyve_capabilities.c | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
> > index 13b4835a8..9dec66b11 100644
> > --- a/src/bhyve/bhyve_capabilities.c
> > +++ b/src/bhyve/bhyve_capabilities.c
> > @@ -22,6 +22,9 @@
> >   */
> >  #include <config.h>
> >  #include <sys/utsname.h>
> > +#include <dirent.h>
> > +#include <stdio.h>
> > +#include <sys/types.h>
> >  
> >  #include "viralloc.h"
> >  #include "virfile.h"
> > @@ -114,11 +117,35 @@ virBhyveDomainCapsBuild(const char *emulatorbin,
> >                          virDomainVirtType virttype)
> >  {
> >      virDomainCapsPtr caps = NULL;
> > +    DIR *dir;
> > +    struct dirent *entry;
> > +    const char *firmware_dir = "/usr/local/share/uefi-firmware";
> 
> Is this path really something that's ok to hard code like this ?  I'm not
> familiar with *BSD filesystem layout conventions, but on Lnux, /usr/local
> would not be a typical directory for system provided firmware - /usr/share
> would be expected. This feels like something that ought to be overridable
> by the user perhaps in a /etc/libvirt/bhyve.conf file, similar to how
> QEMU allows configurable firmware locations

Yeah, things are a little different on FreeBSD compared to Linux, and
almost all user-installed stuff goes into /usr/local, including the
software installed via ports/packages [1].

Specifically, this very path points to the firmware installed via the
port:

 https://www.freshports.org/sysutils/uefi-edk2-bhyve/

So it will work as expected for most users (I goes only few change the
installation prefix).

But you're right, it's not very good to hardcode it like that. Using
some ${prefix}-based substitution will not work as well because libvirt
prefix and uefi firmware paths are generally unrelated.

The only thing I'm worried about is introducing of a config file just
for the sake of a single option, though probably it has to happen sooner
or later...

1: https://man.freebsd.org/hier(7)



Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170309/5087a80e/attachment-0001.sig>