[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] daemon: Fix driver registration ordering



On Fri, Aug 15, 2014 at 01:17:37PM +0200, Michal Privoznik wrote:
There are some stateless drivers which implement subdrivers
(typically vbox and its own network and storage subdrivers). However,
as of ba5f3c7c8ecc10 the vbox driver lives in the daemon, not the
client library. This means, in order for vbox (or any stateless domain
driver) to use its subdrivers, it must register before the general
drivers. Later, when the virConnectOpen function goes through the
subdrivers, stateless drivers are searched first. If the connection
request is aiming at stateless driver, it will be opened. Otherwise
the generic subdriver is opened.

The other change done in this commit is moving interface module load a
bit earlier to match the ordering in case libvirt is built without
driver modules.

Reported-by: Taowei Luo <uaedante gmail com>
Signed-off-by: Michal Privoznik <mprivozn redhat com>
---
daemon/libvirtd.c | 31 ++++++++++++++++++-------------
1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index a1f64ad..69baef6 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -365,10 +365,15 @@ static void daemonInitialize(void)
{
    /*
     * Note that the order is important: the first ones have a higher
-     * priority when calling virStateInitialize. We must register
-     * the network, storage and nodedev drivers before any domain
-     * drivers, since their resources must be auto-started before
-     * any domains can be auto-started.
+     * priority when calling virStateInitialize. We must register the
+     * network, storage and nodedev drivers before any stateless

s/stateless/stateful/  or just say before domain drivers that
implement their own subdrivers.

+     * domain drivers, since their resources must be auto-started
+     * before any domains can be auto-started. Moreover, some
+     * stateless drivers implement their own subdrivers (e.g. the vbox
+     * driver has its own network and storage subdriers) which need to
+     * have higher priority. Otherwise, when connecting the such

s/the such/such/

+     * driver generic subdriver may be opened instead of the one

s/driver/driver's/ or just "Otherwise generic subdriver may be..."

ACK with that wording cleaned up.  Don't worry about keeping it
simple, no need to explain string theory in there ;)

Martin

Attachment: signature.asc
Description: Digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]