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

Re: [libvirt] [PATCH v3] nwfilter:




Eric Blake <eblake redhat com> wrote on 08/13/2010 05:16:39 PM:


>
> On 08/13/2010 03:11 PM, Stefan Berger wrote:
> >>> +        virNWFilterPoolLoadAllConfigs(conn,
> >>> + &driverState->pools,
> >>
> >> Indentation problem still looks like it is here.
> >
> > The indentation problem doesn't exist in my local patch. Could this be
> > another Thunderbird formatting issue?
>
> Sorry, not this time.  The fact that there are two leading + means that
> 'git diff' really did see two lines, and your second line is flush left
> instead of indented (and even still in the copy where you resent with a
> better subject line).


This is how the lines around this look like. The removal of the line that starts with &driverState->pools is also wrong and I did not re-format that one, either (using quilt). I am using Thunderbird 3.3.1.

-    nwfilterDriverLock(driverState);
-    virNWFilterPoolLoadAllConfigs(NULL,
- &driverState->pools,
-                                  driverState->configDir);
-    nwfilterDriverUnlock(driverState);
+    conn = virConnectOpen("qemu:///system");
+
+    if (conn) {
+        /* shut down all threads -- qemud for example will restart them */
+        virNWFilterLearnThreadsTerminate(true);
+
+        nwfilterDriverLock(driverState);
+        virNWFilterPoolLoadAllConfigs(conn,
+ &driverState->pools,
+                                      driverState->configDir);
+        nwfilterDriverUnlock(driverState);
+
+        virConnectClose(conn);
+    }



> The difference is whether you communicate with the libvirtd process
> running as root, or with just the session-specific qemu command.  If you
> are running unprivileged but attempt to connect to qemu:///system, this
> will cause an authentication attempt (you have to supply the root
> password); but if the user is only running a qemu:///session, this is
> not what they want.
>
> I'm not sure what makes the right thing to do here; hopefully danpb can
> shed some better insight into this.


Since this is an libvirtd-internal call I suppose qemu:///system should be alright... I'll wait to hear from Dan then.

   Stefan

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