1. 11 11月, 2019 7 次提交
    • D
      python: avoid bare 'except:' clause · 2ba699cb
      Daniel P. Berrangé 提交于
      Exception catching statements should always match on a class name, the
      most specific one possible. Rather than analyse the code to look at what
      the most specific one is, this just uses the base Exception class.
      
      docs/apibuild.py:255:9: E722 do not use bare 'except'
              except:
              ^
      docs/apibuild.py:279:9: E722 do not use bare 'except'
              except:
              ^
      ...more...
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2ba699cb
    • D
      python: avoid variable named 'l' · cfdd871f
      Daniel P. Berrangé 提交于
      Python code style recommends avoiding a variable named 'l' as it is
      visually similar to '1'.
      
      docs/apibuild.py:482:13: E741 ambiguous variable name 'l'
                  l = len(line)
                  ^
      docs/apibuild.py:503:21: E741 ambiguous variable name 'l'
                          l = len(line)
                          ^
      ...more...
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      cfdd871f
    • D
      python: mark regex strings with 'r' prefix · d5c5d8af
      Daniel P. Berrangé 提交于
      When writing regexes special regex matches like "\d" can get
      misinterpreted as normal string escape sequences:
      
      docs/apibuild.py:1359:51: W605 invalid escape sequence '\d'
                              value = value + re.sub("^(\d+)U$", "\\1", token[1])
                                                        ^
      docs/apibuild.py:2134:31: W605 invalid escape sequence '\('
                      m = re.match("\(?1<<(\d+)\)?", info[0])
                                    ^
      docs/apibuild.py:2134:38: W605 invalid escape sequence '\d'
                      m = re.match("\(?1<<(\d+)\)?", info[0])
                                           ^
      docs/apibuild.py:2134:42: W605 invalid escape sequence '\)'
                      m = re.match("\(?1<<(\d+)\)?", info[0])
                                               ^
      
      To avoid this probem all regexes should use the r"...." syntax for their
      strings, which disables normal string escape sequences.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d5c5d8af
    • D
      python: fix use of undeclared variables in python scripts · 524b377e
      Daniel P. Berrangé 提交于
      docs/apibuild.py:2436:65: F821 undefined name 'first_letter'
                              chunks.append(["chunk%s" % (chunk - 1), first_letter, letter])
                                                                      ^
      src/hyperv/hyperv_wmi_generator.py:415:57: F821 undefined name 'number'
              report_error("line %d: invalid block header" % (number))
                                                              ^
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      524b377e
    • D
      build: change flake8 to use blacklist instead of whitelist · 3a5fea60
      Daniel P. Berrangé 提交于
      The current flake8 check only looks at one item (semicolons at end of
      line). This means that our code quality will continue to get worse,
      violating an increasing number of checks.
      
      Switching to a whitelist means that we freeze the badness at its
      current level & can incrementally fix things up.
      
      We are excluding the following...
      
      Indentation:
      
        E114 indentation is not a multiple of four (comment)
        E115 expected an indented block (comment)
        E116 unexpected indentation (comment)
        E121 continuation line under-indented for hanging indent
        E125 continuation line with same indent as next logical line
        E126 continuation line over-indented for hanging indent
        E127 continuation line over-indented for visual indent
        E128 continuation line under-indented for visual indent
        E129 visually indented line with same indent as next logical line
        E131 continuation line unaligned for hanging indent
      
      Whitespace:
      
        E211 whitespace before ‘(‘
        E221 multiple spaces before operator
        E222 multiple spaces after operator
        E225 missing whitespace around operator
        E226 missing whitespace around arithmetic operator
        E231 missing whitespace after ‘,’, ‘;’, or ‘:’
        E261 at least two spaces before inline comment
      
      Blank lines
      
        E301 expected 1 blank line, found 0
        E302 expected 2 blank lines, found 0
        E303 too many blank lines (3)
        E305 expected 2 blank lines after end of function or class
      
      Line length
      
        E501 line too long (82 > 79 characters)
      
      Statements
      
        E722 do not use bare except, specify exception instead
        E741 do not use variables named ‘l’, ‘O’, or ‘I’
      
      Errors:
      
        F821 undefined name 'name'
      
      Warnings:
      
        W504 line break after binary operator
        W605 invalid escape sequence ‘x’
      
      Later commits will enable most of these exclusions.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      3a5fea60
    • D
      55cbe0fb
    • P
      spec: fix rpm build with VPATH · c4192960
      Pavel Hrdina 提交于
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      c4192960
  2. 10 11月, 2019 1 次提交
  3. 09 11月, 2019 22 次提交
  4. 08 11月, 2019 7 次提交
    • M
      qemu: Check for job being set when getting iothread stats · 3d46d684
      Michal Privoznik 提交于
      The qemuDomainGetStatsIOThread() accesses the monitor by calling
      qemuDomainGetIOThreadsMon(). And it's also marked as "need
      monitor" in qemuDomainGetStatsWorkers[]. However, it's not
      checking if acquiring job was successful.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com>
      3d46d684
    • M
      qemu: Warn on possibly incorrect usage of EnterMonitor* · 1faf7405
      Michal Privoznik 提交于
      The qemuDomainObjEnterMonitor() should not be called without a
      job set. Catch this error and produce a warning message if such
      call occurred.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJonathon Jongsma <jjongsma@redhat.com>
      1faf7405
    • W
      util: Set SIGPIPE to a no-op handler in virFork · ebd00429
      Wang Yechao 提交于
      Libvirtd has set SIGPIPE to ignored, and virFork resets all signal
      handlers to the defaults. But child process may write logs to
      stderr/stdout, that may generate SIGPIPE if journald has stopped.
      
      So set SIGPIPE to a dummy no-op handler before unmask signals in
      virFork(), and the handler will get reset to SIG_DFL when execve()
      runs. Now we can delete sigaction() call entirely in virExec().
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Signed-off-by: NWang Yechao <wang.yechao255@zte.com.cn>
      ebd00429
    • L
      util: set bridge device MAC address explicitly during virNetDevBridgeCreate · 13ec8270
      Laine Stump 提交于
      When libvirt first implemented a stable and configurable MAC address
      for the bridges created for libvirt virtual networks (commit
      5754dbd5, in libvirt v0.8.8) most distro stable releases didn't
      support explicitly setting the MAC address of a bridge; the bridge
      just always assumed the lowest numbered MAC of all attached
      interfaces. Because of this, we stabilized the bridge MAC address by
      creating a "dummy" tap interface with a MAC address guaranteed to be
      lower than any of the guest tap devices' MACs (which all started with
      0xFE, so it's not difficult to do) and attached it to the bridge -
      this was the inception of the "virbr0-nic" device that has confused so
      many people over the years.
      
      Even though the linux kernel had recently gained support for
      explicitly setting a bridge MAC, we deemed it unnecessary to set the
      MAC that way, because the other (indirect) method worked everywhere.
      
      But recently there have been reports that the bridge MAC address was
      not following the setting in the network config, and mismatched the
      MAC of the dummy tap device (which was still correct). It turns out
      that this is due to a change in systemd-242 that persists whatever MAC
      address is set for a bridge when it's initially started. According to
      the systemd NEWS file entry for version 242
      (https://github.com/systemd/systemd/blob/master/NEWS):
      
        "if a bridge interface is created without any slaves, and gains
         a slave later, then now the bridge does not inherit slave's MAC."
      
      This change was the result of:
      
        https://github.com/systemd/systemd/issues/3374
      
      (apparently if there is no MAC saved for a bridge by the name of a
      bridge being created, the random MAC generated during creation is
      saved, and then that same MAC is used to explicitly set the MAC each
      time it is created). Once a bridge has an explicitly set MAC, the "use
      the lowest numbered MAC of attached devices" rule is ignored, so our
      dummy tap device is like the goggles - it does nothing! (well, almost).
      
      We could whine about changes in default behavior, etc. etc., but
      because the change was in response to actual user problems, that seems
      likely a fruitless task. Fortunately, time has marched on, and even
      distro releases that are old enough that they are no longer supported
      by upstream libvirt (e.g. RHEL6) have support for explicitly setting a
      bridge device MAC address, either during creation or with a separate
      ioctl after creation, so we can now do that.
      
      To enable explicitly setting the mac during bridge creation, we add a
      mac arg to virNetDevBridgeCreate().  In the case of platforms where
      the bridge is created with a netlink RTM_NEWLINK message, we just add
      that mac to the message. For platforms that still use an ioctl (either
      SIOCBRADDBR or SIOCIFCREATE2), we make a separate call to
      virNetDevSetMAC() after creating the bridge.
      
      (NB: I was unable to test the calling of virNetDevSetMAC() from the
      SIOCIFCREATE2 (BSD) version of virNetDevBridgeCreate(); even though I
      managed to get a FreeBSD system setup and libvirt built there, when I
      tried to start the default network the SIOCIFCREATE2 ioctl itself
      failed, so it never even got to the virNetDevSetMAC(). That leaves the
      FreeBSD implementation untested.)
      
      This makes the dummy tap pointless for purposes of setting the MAC
      address, but it is still useful for IPv6 DAD initialization (which
      apparently requires at least one interface to be attached to the
      bridge and online), as well as for setting an initial MTU for the
      bridge, so it hasn't been removed.
      
      (NB: we can safely *always* call virNetDevBridgeCreate() with
      &def->mac from the network driver because, in spite of the existence
      of a "mac_specified" bool in the config suggesting that it may not
      always be present, in reality a mac address will always be added to
      any network that doesn't have one - this is guaranteed in all cases by
      commit a47ae7c0)
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1760851Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      13ec8270
    • L
      util: allow sending mac addr to virNetNewLink without ifindex · b596d6c1
      Laine Stump 提交于
      Although until now, any use of the extra_args argument (a pointer to a
      struct containing extra attributes to add the the RTM_NEWLINK message)
      would always have the ifindex and mac set, so the code could assume it
      was safe to add both to the message if extra_args != NULL. There is
      now a use for setting a MAC address in the RTM_NEWLINK without setting
      the ifindex, so we should check each of these separately.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      b596d6c1
    • A
      cpu_map: Ship arm_features.xml · 0de541bf
      Andrea Bolognani 提交于
      The file was introduced in be03587a, but it was not added
      to $(cpumap_DATA) at the time and so it didn't show up in the
      distribution archive.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      0de541bf
    • L
      qemu: avoid double reservation of PCI address for interface type='hostdev' · 47a7b8a9
      Laine Stump 提交于
      Commit 01ca4010 (libvirt v5.1.0) moved address reservation for
      hotplugged interface devices up to an earlier point in
      qemuDomainAttachNetDevice(), because that function calls
      qemuDomainSupportsNicdev() (in the case of
      VIR_DOMAIN_NET_TYPE_VHOSTUSER), and qemuDomainSupportsNicdev() needs
      to know the address type (for ARM machinetypes) and returns incorrect
      results when the address type is "none".
      
      This bugfix unfortunately caused a regression, because it also made PCI
      address reservation happen before we noticed that the device was a
      *hostdev* interface. Those interfaces are hotplugged by just calling
      out to qemuDomainAttachHostdevDevice() - that function would then also
      attempt to reserve the *same PCI address* that had just been reserved
      in qemuDomainAttachNetDevice().
      
      The solution is to move the bit of code that short-circuits out to
      virDomainHostdevAttach() up *even earlier* so that no PCI address has
      been allocated by the time it's called.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1744523Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      47a7b8a9
  5. 07 11月, 2019 3 次提交