1. 07 Dec, 2015 34 commits
  2. 05 Dec, 2015 6 commits
    • Jiří Klimeš's avatar
      clients: accept service without org.freedesktop.NetworkManager prefix · f28d311d
      Jiří Klimeš authored
      in nm_vpn_get_plugin_by_service()
    • Jiří Klimeš's avatar
    • Thomas Haller's avatar
      tests/valgrind: rename name of logfile for valgrind run · ce238a70
      Thomas Haller authored
      Change the name of the file where to store the results
      of the valgrind run.
      Previously the file had a prefix "valgrind-", which is inconvinient.
      Instead, have the file using the same name as the test executable,
      with a ".valgrind-log" suffix.
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      device: cleanup handling master/slave relationships in NMDevice · f45f702a
      Thomas Haller authored
      I found the handling of the master-device very confusing because it was
      unclear who sets priv->master, and when it should be set.
      - Setting priv->master (in a slave) always goes together with adding
        the master to priv->slaves (in the master). Previously, this was
        done at separate places, so it was not clear if master and slave
        always agree on their relationship -- in fact, they did not.
      - There are now three basic functions which do the enslaving/releasing:
          (1) nm_device_master_add_slave()
          (2) nm_device_master_enslave_slave()
          (3) nm_device_master_release_one_slave()
        Step 3/release basically undoes the 1/add and 2/enslave steps.
      - completing the enslaving/releasing is now done by
          (1) nm_device_slave_notify_enslave()
          (2) nm_device_slave_notify_release()
        These functions also emit signals like NM_DEVICE_MASTER.
      - Derived classes no longer emit NM_DEVICE_SLAVES notification. Instead
        the notification is emited together with NM_DEVICE_MASTER, whenever a
        slaves changes state. Also, NM_DEVICE_SLAVES list now only exposes
        slaves that are actually @is_enslaved.
    • Thomas Haller's avatar
      device: implement slave property in parent device class · 9a8d9a0d
      Thomas Haller authored
      Instead of reimplementing the slave property in bond, bridge
      and team, just add the property to the parent class. It's not
      that the parent class would be agnostic to the master/slave
      implementation, all the slaves are known to the every device
      type implementation.
      Also, the derived class doesn't know the correct time when
      to invoke the notify-changed for the slaves property.
      E.g. it should be only invoked after nm_device_slave_notify_enslave()
      when other components also consider the slave as enslaved.
      Later this will be fixed so that the SLAVES property correspond
      to what other master/slave related properties say.