Commit Graph

6 Commits

Author SHA1 Message Date
Andrea Bolognani
90b17aef1a perl: Don't hardcode interpreter path
This is particularly useful on operating systems that don't ship
Perl as part of the base system (eg. FreeBSD) while still working
just as well as it did before on Linux.

In one case (src/rpc/genprotocol.pl) the interpreter path was
missing altogether.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-09-19 16:04:53 +02:00
Daniel P. Berrange
55ea7be7d9 Removing probing of secondary drivers
For stateless, client side drivers, it is never correct to
probe for secondary drivers. It is only ever appropriate to
use the secondary driver that is associated with the
hypervisor in question. As a result the ESX & HyperV drivers
have both been forced to do hacks where they register no-op
drivers for the ones they don't implement.

For stateful, server side drivers, we always just want to
use the same built-in shared driver. The exception is
virtualbox which is really a stateless driver and so wants
to use its own server side secondary drivers. To deal with
this virtualbox has to be built as 3 separate loadable
modules to allow registration to work in the right order.

This can all be simplified by introducing a new struct
recording the precise set of secondary drivers each
hypervisor driver wants

struct _virConnectDriver {
    virHypervisorDriverPtr hypervisorDriver;
    virInterfaceDriverPtr interfaceDriver;
    virNetworkDriverPtr networkDriver;
    virNodeDeviceDriverPtr nodeDeviceDriver;
    virNWFilterDriverPtr nwfilterDriver;
    virSecretDriverPtr secretDriver;
    virStorageDriverPtr storageDriver;
};

Instead of registering the hypervisor driver, we now
just register a virConnectDriver instead. This allows
us to remove all probing of secondary drivers. Once we
have chosen the primary driver, we immediately know the
correct secondary drivers to use.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-01-27 12:02:04 +00:00
Daniel P. Berrange
4e6b73d239 Skip virNWFilterTechDriver when validating API naming
The virNWFilterTechDriver struct is an internal only driver
API with no public API equivalent. It should be skipped by
the 'check-driverimpls' test case

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-09 17:09:59 +01:00
Daniel P. Berrange
142e6e2784 Fix naming of some node device APIs
In renaming driver API implementations to match the
public API naming scheme, a few cases in the node
device driver were missed.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-08 10:47:47 +01:00
Daniel P. Berrange
ead630319d Separate virGetHostname() API contract from driver APIs
Currently the virGetHostname() API has a bogus virConnectPtr
parameter. This is because virtualization drivers directly
reference this API in their virDriverPtr tables, tieing its
API design to the public virConnectGetHostname API design.

This also causes problems for access control checks since
these must only be done for invocations from the public
API, not internal invocation.

Remove the bogus virConnectPtr parameter, and make each
hypervisor driver provide a dedicated function for the
driver API impl. This will allow access control checks
to be easily inserted later.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-08 10:47:47 +01:00
Daniel P. Berrange
90430791ae Make driver method names consistent with public APIs
Ensure that all drivers implementing public APIs use a
naming convention for their implementation that matches
the public API name.

eg for the public API   virDomainCreate make sure QEMU
uses qemuDomainCreate and not qemuDomainStart

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-24 11:00:18 +01:00