1. 14 11月, 2016 3 次提交
    • E
      datatypes: Introduce some admin-related close callback handling helpers · 7cea74a3
      Erik Skultety 提交于
      Well, there were three different spots where closeCallback->freeCallback was
      called, not looking the same --> potential for bugs - and there indeed is a bug
      with refcounting of the @conn object. So this patch partially follows the path
      set by commit 24dbb69f by introducing some close callback helpers both to
      replace all the spots where we call clean the close callback data with a
      dedicated function and to be able to fix the refcounting bug causing a memleak.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      7cea74a3
    • E
      admin: Remove unnecessary @conn object locking · d46a1e5d
      Erik Skultety 提交于
      The only place we change the @conn object is actually virAdmConnectOpen
      routine, thus at the moment we don't really need to lock it, given the fact that
      what we're trying to do here is to change the closeCallback object which is a
      lockable object itself, so that should be enough to avoid races.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      d46a1e5d
    • E
      vsh: Drop conditional error reporting in vshErrorHandler · b98b3b74
      Erik Skultety 提交于
      First, since commit 834c5720 the error reporting within the vshErrorHandler
      doesn't work because there was a lot of renaming going on (dull mechanical
      renaming without much thinking about it, yep - shame on me) and so the original
      env variable VIRSH_DEBUG got renamed to VSH_DEBUG which we don't support nor
      document anywhere. Second, by specifying this env variable, the last libvirt
      error gets reported twice despite the fact we say the error reporting should be
      deferred until the command finishes, and last but not least the vintage code's
      logic is a bit 'odd', since the error would get reported iff the env variable
      is set, even if the value should be equal to our DEFAULT value in which case it
      doesn't make sense that we behave differently when an env variable is set to
      some value and when there's no env variable at all but we use the same value
      automatically as default.
      Signed-off-by: NErik Skultety <eskultet@redhat.com>
      b98b3b74
  2. 13 11月, 2016 1 次提交
  3. 12 11月, 2016 1 次提交
  4. 11 11月, 2016 27 次提交
  5. 10 11月, 2016 7 次提交
  6. 09 11月, 2016 1 次提交