1. 12 Feb, 2019 1 commit
  2. 17 Sep, 2018 1 commit
  3. 10 Nov, 2016 1 commit
    • Lubomir Rintel's avatar
      libnm: use the o.fd.DBus.ObjectManager API for object management · 1f5b48a5
      Lubomir Rintel authored
      This speeds up the initial object tree load significantly. Also, it
      reduces the object management complexity by shifting the duties to
      GDBusObjectManager.
      
      The lifetime of all NMObjects is now managed by the NMClient via the
      object manager. The NMClient creates the NMObjects for GDBus objects,
      triggers the initialization and serves as an object registry (replaces
      the nm-cache).
      
      The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
      object creation, removal and property changes. It takes care of the
      property changes so that we don't have to and lets us always see a
      consistent object state.  Thus at the time we learn of a new object we
      already know its properties.
      
      The NMObject unfortunately can't be made synchronously initializable as
      the NMRemoteConnection's settings are not managed with standard
      o.fd.DBus Properties and ObjectManager APIs and thus are not known to
      the ObjectManager.  Thus most of the asynchronous object property
      changing code in nm-object.c is preserved. The objects notify the
      properties that reference them of their initialization in from their
      init_finish() methods, thus the asynchronously created objects are not
      allowed to fail creation (or the dependees would wait forever). Not a
      problem -- if a connection can't get its Settings, it's either invisible
      or being removed (presumably we'd learn of the removal from the object
      manager soon).
      
      The NMObjects can't be created by the object manager itself, since we
      can't determine the resulting object type in proxy_type() yet (we can't
      tell from the name and can't access the interface list). Therefore the
      GDBusObject is coupled with a NMObject later on.
      
      Lastly, now that all the objects are managed by the object manager, the
      NMRemoteSettings and NMManager go away when the daemon is stopped. The
      complexity of dealing with calls to NMClient that would require any of
      the resources that these objects manage (connection or device lists,
      etc.) had to be moved to NMClient. The bright side is that his allows
      for removal all of the daemon presence tracking from NMObject.
      1f5b48a5
  4. 24 Oct, 2016 2 commits
    • Thomas Haller's avatar
      libnm: coerce empty strings to NULL for D-Bus properties · 95ab69b7
      Thomas Haller authored
      On D-Bus level, string (s) or object paths (o) cannot be NULL.
      Thus, whenver server exposes such an object, it gets automatically
      coerced to "" or "/", respectively.
      
      On client side, libnm should coerce certain properties back, for which
      "" is just not a sensible value.
      
      For example, an empty NM_DEVICE_ETHERNET_HW_ADDRESS should be instead
      exposed as NULL.
      
      Technically, this is an API change. However, all users were well advised
      to expect both NULL and "" as possible return values and handle them
      accordingly.
      95ab69b7
    • Thomas Haller's avatar
      libnm: fix memleak in NMDeviceVxlan · 7eb054d0
      Thomas Haller authored
      7eb054d0
  5. 03 Oct, 2016 1 commit
  6. 19 Feb, 2016 1 commit
    • Thomas Haller's avatar
      all: cleanup includes and let "nm-default.h" include "config.h" · 8bace23b
      Thomas Haller authored
      - All internal source files (except "examples", which are not internal)
        should include "config.h" first. As also all internal source
        files should include "nm-default.h", let "config.h" be included
        by "nm-default.h" and include "nm-default.h" as first in every
        source file.
        We already wanted to include "nm-default.h" before other headers
        because it might contains some fixes (like "nm-glib.h" compatibility)
        that is required first.
      
      - After including "nm-default.h", we optinally allow for including the
        corresponding header file for the source file at hand. The idea
        is to ensure that each header file is self contained.
      
      - Don't include "config.h" or "nm-default.h" in any header file
        (except "nm-sd-adapt.h"). Public headers anyway must not include
        these headers, and internal headers are never included after
        "nm-default.h", as of the first previous point.
      
      - Include all internal headers with quotes instead of angle brackets.
        In practice it doesn't matter, because in our public headers we must
        include other headers with angle brackets. As we use our public
        headers also to compile our interal source files, effectively the
        result must be the same. Still do it for consistency.
      
      - Except for <config.h> itself. Include it with angle brackets as suggested by
        https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
      8bace23b
  7. 09 Dec, 2015 1 commit