You need to sign in or sign up before continuing.
  1. 15 9月, 2017 1 次提交
  2. 12 9月, 2017 1 次提交
  3. 28 8月, 2017 1 次提交
  4. 27 8月, 2017 1 次提交
  5. 18 8月, 2017 1 次提交
  6. 17 8月, 2017 11 次提交
  7. 15 8月, 2017 3 次提交
    • J
      util: Introduce and use virObjectRWUnlock · 045d712c
      John Ferlan 提交于
      Rather than overload virObjectUnlock as commit id '77f4593b' has
      done, create a separate virObjectRWUnlock API that will force the
      consumers to make the proper decision regarding unlocking the
      RWLock's. Similar to the RWLockRead and RWLockWrite, use the
      virObjectGetRWLockableObj helper. This restores the virObjectUnlock
      code to using the virObjectGetLockableObj.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      045d712c
    • J
      util: Introduce and use virObjectRWLockWrite · 908b3364
      John Ferlan 提交于
      Instead of making virObjectLock be the entry point for two
      different types of locks, let's create a virObjectRWLockWrite API
      which will only handle the virObjectRWLockableClass objects.
      
      Use the new virObjectRWLockWrite for the virdomainobjlist code
      in order to handle the Add, Remove, Rename, and Load operations
      that need to be very synchronous.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      908b3364
    • J
      util: Rename virObjectLockRead to virObjectRWLockRead · 99a72b3e
      John Ferlan 提交于
      Since the class it represents is based on virObjectRWLockableClass
      and in order to make sure we differentiate just in case anyone somehow
      believes they could use virObjectLockRead for a virObjectLockableClass,
      let's rename the API to use the RW in the name. Besides the RW locks
      refer to pthread_rwlock_{init|rdlock|wrlock|unlock|destroy} while the
      other locks refer to pthread_mutex_{init|lock|unlock|destroy}.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      99a72b3e
  8. 14 8月, 2017 2 次提交
  9. 12 8月, 2017 1 次提交
    • L
      util: new function virNetDevGetPhysPortID() · 48f33bb5
      Laine Stump 提交于
      On Linux each network device *can* (but not necessarily *does*) have
      an attribute called phys_port_id which can be read from the file of
      that name in the netdev's sysfs directory. The examples I've seen have
      been a many-digit hexadecimal number (as an ASCII string).
      
      This value can be useful when a single PCI device is associated with
      multiple netdevs (e.g a dual port Mellanox SR-IOV NIC - this card has
      a single PCI Physical Function (PF), and that PF has two netdevs
      associated with it (the "net" subdirectory of the PF in sysfs has two
      links rather than the usual single link to a netdev directory). Each
      of the PF netdevs has a different phys_port_id. The Virtual Functions
      (VF) are similar - the PF (a PCI device) has "n" VFs (also each of
      these is a PCI device), each VF has two netdevs, and each of the VF
      netdevs points back to the VF PCI device (with the "device" entry in
      its sysfs directory) as well as having a phys_port_id matching the PF
      netdev it is associated with.
      
      virNetDevGetPhysPortID() simply attempts to read the phys_port_id for
      the given netdev and return it to the caller. If this particular
      netdev driver doesn't support phys_port_id, it returns NULL (*not* a
      NULL-terminated string, but a NULL pointer) but still counts it as a
      success.
      48f33bb5
  10. 08 8月, 2017 1 次提交
    • J
      introduce virConfReadString · e9f32227
      Ján Tomko 提交于
      Rewrite virConfReadMem to take a null-terminated string.
      All the callers were calling strlen on it anyway.
      e9f32227
  11. 03 8月, 2017 1 次提交
  12. 02 8月, 2017 1 次提交
  13. 27 7月, 2017 1 次提交
  14. 26 7月, 2017 1 次提交
    • P
      util: introduce virFileCache · ac3eb2ab
      Pavel Hrdina 提交于
      The new virFileCache will nicely handle the caching logic for any data
      that we would like to cache.  For each type of data we will just need
      to implement few handlers that will take care of creating, validating,
      loading and saving the cached data.
      
      The cached data must be an instance of virObject.
      
      Currently we cache QEMU capabilities which will start using
      virFileCache.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      ac3eb2ab
  15. 25 7月, 2017 3 次提交
  16. 24 7月, 2017 3 次提交
    • M
      virobject: Introduce virObjectRWLockable · 77f4593b
      Michal Privoznik 提交于
      Up until now we only had virObjectLockable which uses mutexes for
      mutually excluding each other in critical section. Well, this is
      not enough. Future work will require RW locks so we might as well
      have virObjectRWLockable which is introduced here.
      
      Moreover, polymorphism is introduced to our code for the first
      time. Yay! More specifically, virObjectLock will grab a write
      lock, virObjectLockRead will grab a read lock then (what a
      surprise right?). This has great advantage that an object can be
      made derived from virObjectRWLockable in a single line and still
      continue functioning properly (mutexes can be viewed as grabbing
      write locks only). Then just those critical sections that can
      grab a read lock need fixing. Therefore the resulting change is
      going to be way smaller.
      
      In order to avoid writer starvation, the object initializes RW
      lock that prefers writers.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      77f4593b
    • M
      virthread: Introduce virRWLockInitPreferWriter · 328bd244
      Michal Privoznik 提交于
      We already have virRWLockInit. But this uses pthread defaults
      which prefer reader to initialize the RW lock. This may lead to
      writer starvation. Therefore we need to have the counterpart that
      prefers writers. Now, according to the
      pthread_rwlockattr_setkind_np() man page setting
      PTHREAD_RWLOCK_PREFER_WRITER_NP attribute is no-op. Therefore we
      need to use PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
      attribute. So much for good enum value names.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      328bd244
    • P
      qemu: command: Rename and move qemuNetworkDriveGetPort · e8b69016
      Peter Krempa 提交于
      Move it to virstring.c and improve it to parse and validate ports. New
      name is virStringParsePort.
      e8b69016
  17. 21 7月, 2017 2 次提交
  18. 20 7月, 2017 2 次提交
  19. 17 7月, 2017 3 次提交
    • J
      nodedev: Convert virNodeDeviceObj to use virObjectLockable · dae23ec3
      John Ferlan 提交于
      Now that we have a bit more control, let's convert our object into
      a lockable object and let that magic handle the create and lock/unlock.
      
      This also involves creating a virNodeDeviceEndAPI in order to handle
      the object cleanup for API's that use the Add or Find API's in order
      to get a locked/reffed object. The EndAPI will unlock and unref the
      object returning NULL to indicate to the caller to not use the obj.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      dae23ec3
    • J
      nodedev: Introduce virNodeDeviceObjListFindSCSIHostByWWNs · 1c7bc64e
      John Ferlan 提交于
      In an overall effort to privatize access to virNodeDeviceObj and
      virNodeDeviceObjList into the virnodedeviceobj module, move the
      object list parsing from node_device_driver and replace with a
      call to a virnodedeviceobj helper. This follows other similar
      APIs/helpers which peruse the object list looking for some specific
      data in order to get/return an @device (virNodeDevice) object to
      the caller.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      1c7bc64e
    • J
      nodedev: Introduce virNodeDeviceGetSCSIHostCaps · 12fa16eb
      John Ferlan 提交于
      We're about to move the call to nodeDeviceSysfsGetSCSIHostCaps from
      node_device_driver into virnodedeviceobj, so move the guts of the code
      from the driver specific node_device_linux_sysfs into its own API
      since virnodedeviceobj cannot callback into the driver.
      
      Nothing in the code deals with sysfs anyway, as that's hidden by the
      various virSCSIHost* and virVHBA* utility function calls.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      12fa16eb