1. 27 Mar, 2018 7 commits
    • Thomas Haller's avatar
      config: cleanup fields in NMGlobalDnsConfig · cd48bc74
      Thomas Haller authored
      - consistently set options, searches, domains fields to %NULL,
        if there are no values.
      
      - in nm_global_dns_config_update_checksum(), ensure that we uniquely
        hash values. E.g. a config with "searches[a], options=[b]" should
        hash differently from "searches=[ab], options=[]".
      
      - in nm_global_dns_config_to_dbus(), reuse the sorted domain list.
        We already have it, and it guarantees a consistent ordering of
        fields.
      
      - in global_dns_domain_from_dbus(), fix memleaks if D-Bus strdict
        contains duplicate entries.
      cd48bc74
    • Thomas Haller's avatar
      config/trivial: rename dns_config local variable · 0f1dc3bc
      Thomas Haller authored
      The variable serves a similar purpose, but is called "dns",
      "conf", and "dns_config". Choose one name: "dns_config".
      0f1dc3bc
    • Thomas Haller's avatar
      938d9a82
    • Thomas Haller's avatar
      wifi: rework tracking of wifi-aps to use CList · d7b1a911
      Thomas Haller authored
      - no longer track APs in a hash table with their exported path
        as key. The exported path is already tracked by NMDBusManager's
        lookup index, so we can reuse that for fast lookup by path. Otherwise,
        track the APs in a CList per device.
      
      - as we now track APs in a CList, their order is well defined.
        We no longer need to sort APs and obsoletes nm_wifi_aps_get_sorted()
        and simplifies nm_wifi_aps_find_first_compatible().
      d7b1a911
    • Thomas Haller's avatar
      core: rework lookup for exported objects by path to use index · 9fafd26f
      Thomas Haller authored
      We already track an index of exported objects in NMDBusManager.
      Actually, that index was unused previously. We either could drop
      it, or use it. Let's use it.
      9fafd26f
    • Thomas Haller's avatar
      manager: convert hwaddr to binary once in find_device_by_permanent_hw_addr() · 199f2df5
      Thomas Haller authored
      For comparing MAC addresses, they anyway have to be normalized
      to binary. Convert it once outside the loop and pass the binary
      form to nm_utils_hwaddr_matches(). Otherwise, we need to re-convert
      it every time.
      199f2df5
    • Thomas Haller's avatar
      core: track devices in manager via embedded CList · 4a705e1a
      Thomas Haller authored
      Instead of using a GSList for tracking the devices, use a CList.
      I think a CList is in most cases the more suitable data structure
      then GSList:
      
       - you can find out in O(1) whether the object is linked. That
         is nice, for example to assert in NMDevice's destructor that
         the object was unlinked, and we will use that later in
         nm_manager_get_device_by_path().
       - you can unlink the element in O(1) and you can unlink the
         element without having access to the link's head
       - Contrary to GSList, this does not require an extra slice
         allocation for the link node. It quite possibliy consumes
         slightly less memory because the CList structure is embedded
         in a struct that we already allocate. Even if slice allocation
         would be perfect to only consume 2*sizeof(gpointer) for the link
         note, it would at most be as-good as CList. Quite possibly,
         there is an overhead though.
       - CList possibly has better memory locality, because the link
         structure and the data are close to each other.
      
      Something which could be seen as disavantage, is that with CList
      one device can only be tracked in one NMManager instance at a time.
      But that is fine. There exists only one NMManager instance for now,
      and even if we would ever introduce multiple managers, we probably
      would not associate one NMDevice instance with multiple managers.
      
      The advantages are arguably not huge, but CList is IMHO clearly the
      more suited data structure. No need to stick to a suboptimal data
      structure for the job. Refactor it.
      4a705e1a
  2. 26 Mar, 2018 9 commits
  3. 22 Mar, 2018 3 commits
  4. 21 Mar, 2018 1 commit
  5. 20 Mar, 2018 20 commits