1. 12 Feb, 2019 1 commit
  2. 21 Jan, 2019 1 commit
  3. 14 Jan, 2019 1 commit
    • Thomas Haller's avatar
      all: return output dictionary from "AddAndActivate2" · fbb038af
      Thomas Haller authored
      Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API.
      "AddAndActivate2" replaces "AddAndActivate" with more options.
      It also has a dictionary argument to be forward compatible so that we
      hopefully won't need an "AddAndActivate3". However, it lacked a similar
      output dictionary. Add it for future extensibility. I think this is
      really to workaround a shortcoming of D-Bus, which does provide strong
      typing and type information about its API, but does not allow to extend
      an existing API in a backward compatible manner. So we either resort to
      Method(), Method2(), Method3() variants, or a catch-all variant with a
      generic "a{sv}" input/output argument.
      In libnm, rename "nm_client_add_and_activate_connection_options()" to
      "nm_client_add_and_activate_connection2()". I think libnm API should have
      an obvious correspondence with D-Bus API. Or stated differently, if
      "AddAndActivateOptions" would be a better name, then the D-Bus API should
      be renamed. We should prefer one name over the other, but regardless
      of which is preferred, the naming for D-Bus and libnm API should
      In this case, I do think that AddAndActivate2() is a better name than
      AddAndActivateOptions(). Hence I rename the libnm API.
      Also, unless necessary, let libnm still call "AddAndActivate" instead of
      "AddAndActivate2". Our backward compatibility works the way that libnm
      requires a server version at least as new as itself. As such, libnm
      theoretically could assume that server version is new enough to support
      "AddAndActivate2" and could always use the more powerful variant.
      However, we don't need to break compatibility intentionally and for
      little gain. Here, it's easy to let libnm also handle old server API, by
      continuing to use "AddAndActivate" for nm_client_add_and_activate_connection().
      Note that during package update, we don't restart the currently running
      NetworkManager instance. In such a scenario, it can easily happen that
      nmcli/libnm is newer than the server version. Let's try a bit harder
      to not break that.
      Changes as discussed in [1].
      [1] !37 (comment 79876)
  4. 17 Nov, 2018 1 commit
  5. 25 Oct, 2018 1 commit
  6. 10 May, 2018 1 commit
    • Lubomir Rintel's avatar
      all: use the elvis operator wherever possible · e69d3869
      Lubomir Rintel authored
        expression a, b;
        -a ? a : b
        +a ?: b
      Applied with:
        spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
      With some manual adjustments on spots that Cocci didn't catch for
      reasons unknown.
      Thanks to the marvelous effort of the GNU compiler developer we can now
      spare a couple of bits that could be used for more important things,
      like this commit message. Standards commitees yet have to catch up.
  7. 18 Apr, 2018 1 commit
  8. 04 Apr, 2018 4 commits
    • Thomas Haller's avatar
      libnm: rework checkpoint API · 735dc41b
      Thomas Haller authored
      The libnm API fir checkpoints was only introduced with 1.11. It
      is not yet stable, so there is still time to adjust it. Note that
      this changes API/ABI of the development branch.
      - we only add async variants of the checkpoint functions. I believe
        that synchronous D-Bus methods are fundamentally flawed, because
        they mess up the ordering of events.
        Rename the async functions by removing the "_async" suffix. This
        matches glib style, for which the async form is also not specially
      - for function that refere to a particular checkpoint (rollback and
        destroy), accept the D-Bus path as string, instead of an NMCheckpoint
        instance. This form is more flexible, because it allows to use
        the function without having a NMCheckpoint instance at hand. On the
        other hand, if one has a NMCheckpoint instance, he can trivially
        obtain the path to make the call.
    • Thomas Haller's avatar
      checkpoint: allow resetting the rollback timeout via D-Bus · f6730322
      Thomas Haller authored
      This allows to adjust the timeout of an existing checkpoint.
      The main usecase of checkpoints, is to have a fail-safe when
      configuring the network remotely. By allowing to reset the timeout,
      the user can perform a series of actions, and keep bumping the
      timeout. That way, the entire series is still guarded by the same
      checkpoint, but the user can start with short timeout, and
      re-adjust the timeout as he goes along.
      The libnm API only implements the async form (at least for now).
      Sync methods are fundamentally wrong with D-Bus, and it's probably
      not needed. Also, follow glib convenction, where the async form
      doesn't have the _async name suffix. Also, accept a D-Bus path
      as argument, not a NMCheckpoint instance. The libnm API should
      not be more restricted than the underlying D-Bus API. It would
      be cumbersome to require the user to lookup the NMCheckpoint
      instance first, especially since libnm doesn't provide an efficient
      or convenient lookup-by-path method. On the other hand, retrieving
      the path from a NMCheckpoint instance is always possible.
    • Thomas Haller's avatar
      libnm: fix crash creating checkpoint during find_checkpoint_info() · 6f85d3e0
      Thomas Haller authored
      Now that the D-Bus signals in server are reordered, creating
      a checkpoint in libnm crashes:
        $ examples/python/gi/checkpoint.py create 4
          #0  0x00007ffff6d011ee in __strcmp_sse2_unaligned () at /lib64/libc.so.6
          #1  0x00007fffeb611c90 in find_checkpoint_info (manager=manager@entry=0x5555559e5110 [NMManager], path=0x7fffdc0092f0 "/org/freedesktop/NetworkManager/Checkpoint/6")
              at libnm/nm-manager.c:153
          #2  0x00007fffeb611d8f in checkpoint_added (manager=0x5555559e5110 [NMManager], checkpoint=checkpoint@entry=0x555555a122d0 [NMCheckpoint]) at libnm/nm-manager.c:1194
          #3  0x00007fffef7db929 in g_cclosure_marshal_VOID__OBJECTv (closure=0x5555559e4b30, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x5555559e2fc0) at gmarshal.c:2102
          #4  0x00007fffef7d8976 in _g_closure_invoke_va (closure=0x5555559e4b30, return_value=0x0, instance=0x5555559e5110, args=0x7fffffffc1c8, n_params=1, param_types=0x5555559e2fc0)
              at gclosure.c:867
          #5  0x00007fffef7f3ff4 in g_signal_emit_valist (instance=instance@entry=0x5555559e5110, signal_id=signal_id@entry=97, detail=0, var_args=var_args@entry=0x7fffffffc1c8) at gsignal.c:3300
          #6  0x00007fffef7f4b48 in g_signal_emit_by_name (instance=instance@entry=0x5555559e5110, detailed_signal=detailed_signal@entry=0x7fffffffc310 "checkpoint-added") at gsignal.c:3487
          #7  0x00007fffeb6156d1 in deferred_notify_cb (data=0x5555559e5110) at libnm/nm-object.c:219
          #8  0x00007fffeb615ae7 in object_property_maybe_complete (self=0x5555559e5110 [NMManager]) at libnm/nm-object.c:555
          #9  0x00007fffeb615e5d in object_created (obj=<optimized out>, path=<optimized out>, user_data=<optimized out>) at libnm/nm-object.c:576
          #10 0x00007fffeb61648b in handle_object_array_property (pi=<optimized out>, value=0x7fffdc075070, property_name=0x7fffeb67f117 "checkpoints", self=0x5555559e5110 [NMManager])
              at libnm/nm-object.c:671
          #11 0x00007fffeb61648b in handle_property_changed (self=self@entry=0x5555559e5110 [NMManager], dbus_name=<optimized out>, value=<optimized out>) at libnm/nm-object.c:740
          #12 0x00007fffeb6166e9 in properties_changed (proxy=<optimized out>, changed_properties=<optimized out>, invalidated_properties=<optimized out>, user_data=0x5555559e5110)
              at libnm/nm-object.c:772
      That is, because NetworkManager now first emits signals that the checkpoint
      object was created, before answering the D-Bus request. That makes more
      sense, but leads to this crash.
      The ugliness of how libnm handles object visibility is considerable.
      libnm hides objects until they are fully initialized. So, when
      the async create-checkpoint operation returns, the object might not
      yet be ready to be exposed. We need to delay the result. It would be
      better if the API would simply return the created path.
    • Thomas Haller's avatar
  9. 08 Mar, 2018 1 commit
    • Benjamin Berg's avatar
      Add calls to g_simple_async_result_set_check_cancellable · 26c215e2
      Benjamin Berg authored
      If an operation is cancelled through the GCancellable, then the idiom is
      that the operation is always cancelled, even if it has finished
      successfully. To ensure this is the case, add calls to
      g_simple_async_result_set_check_cancellable everywhere.
      Without this, e.g. gnome-control-center will crash when switching away
      from the power panel quickly, as the NMClient creation finishes
      asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to
      ensure it doesn't access the now invalid user_data parameter.
  10. 28 Nov, 2017 1 commit
    • Thomas Haller's avatar
      c-list: re-import latest version of c-list.h from upstream · b6efac9e
      Thomas Haller authored
      Most notably, it renames
        c_list_unlink_init() -> c_list_unlink()
        c_list_unlink() -> c_list_unlink_stale()
        $ sed -e 's/\<c_list_unlink\>/c_list_unlink_old/g' \
              -e 's/\<c_list_unlink_init\>/c_list_unlink/g' \
              -e 's/\<c_list_unlink_old\>/c_list_unlink_stale/g' \
              $(git grep -l c_list_unlink -- ':(exclude)shared/nm-utils/c-list.h') \
  11. 16 Nov, 2017 3 commits
    • Thomas Haller's avatar
      all: use nm_str_hash() instead of g_str_hash() · a6be2f4a
      Thomas Haller authored
      We also do this for libnm and libnm-core, where it causes visible changes
      in behavior. But if somebody would rely on the hashing implementation
      for hash tables, it would be seriously flawed.
    • Thomas Haller's avatar
      all: use nm_direct_hash() instead of g_direct_hash() · 93adadbd
      Thomas Haller authored
      We also do this for libnm, where it causes visible changes
      in behavior. But if somebody would rely on the hashing implementation
      for hash tables, it would be seriously flawed.
    • Thomas Haller's avatar
      all: don't use g_direct_equal() for hash table equality function · b58481b3
      Thomas Haller authored
      GHashTable optimizes a NULL equality function to use direct pointer
      comparison. That saves the overhead of calling g_direct_equal().
      This is also documented behavior for g_hash_table_new().
      While at it, also don't pass g_direct_hash() but use the default
      of %NULL. The behavior is the same, but consistently don't use
  12. 09 Nov, 2017 1 commit
  13. 03 Oct, 2017 1 commit
    • Beniamino Galvani's avatar
      libnm: update property in the manager after connectivity check · b799de28
      Beniamino Galvani authored
      Currently, after a client performs a connectivity check it cannot
      access the up-to-date value of the manager.connectivity property right
      away, but it must wait that the queued PropertiesChanged signal is
      processed, which is cumbersome.
      Arguably, clients already receive the new connectivity value as the
      result of the connectivity check call, so they don't have to read it
      from the object; however it would be better if the right value of the
      object property was available immediately as well.
  14. 22 Sep, 2017 1 commit
  15. 17 Aug, 2017 1 commit
  16. 11 May, 2017 1 commit
  17. 13 Mar, 2017 1 commit
  18. 28 Feb, 2017 1 commit
  19. 23 Nov, 2016 1 commit
  20. 14 Nov, 2016 1 commit
  21. 11 Nov, 2016 2 commits
  22. 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
      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.
  23. 24 Oct, 2016 1 commit
    • 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
  24. 14 Oct, 2016 1 commit
  25. 03 Oct, 2016 1 commit
  26. 17 Aug, 2016 2 commits
  27. 01 Jun, 2016 3 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      manager: add Reload() D-Bus command · 1d0e0eef
      Thomas Haller authored
      Add new Reload D-Bus command to reload NetworkManager configuration.
      For now, this is like sending SIGHUP to the process. There are several
      advantages here:
        - it is guarded via PolicyKit authentication while signals
          can only be sent by root.
        - the user can wait for the reload to be complete instead of sending
          an asynchronous signal. For now, we operation completes after
          nm_config_reload() returns, but later we could delay the response
          further until specific parts are fully reloaded.
        - SIGHUP reloads everything including re-reading configuration from
          disk while SIGUSR1 reloads just certain parts such as writing out DNS
          configuration anew.
          Now, the Reload command has a flags argument which is more granular
          in selecting parts which are to be reloaded. For example, via
          signals the user can:
            1) send SIGUSR1: this writes out the DNS configuration to
               resolv.conf and possibly reloads other parts without
               re-reading configuration and without restarting the DNS plugin.
            2) send SIGHUP: this reloads configuration from disk,
               writes out resolv.conf and restarts the DNS plugin.
          There is no way, to only restart the DNS plugin without also reloading
          everything else.
    • Thomas Haller's avatar
  28. 04 Mar, 2016 1 commit
  29. 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
  30. 12 Feb, 2016 1 commit
    • Thomas Haller's avatar
      build: cleanup default includes · 2c2d9d2e
      Thomas Haller authored
      - "gsystem-local-alloc.h" and <gio/gio.h> are already included via
        "nm-default.h". No need to include them separately.
      - include "nm-macros-internal.h" via "nm-default.h" and drop all
        explict includes.
      - in the modified files, ensure that we always include "config.h"
        and "nm-default.h" first. As second, include the header file
        for the current source file (if applicable). Then follow external
        includes and finally internal nm includes.
      - include nm headers inside source code files with quotes
      - internal header files don't need to include default headers.
        They can savely assume that "nm-default.h" is already included
        and with it glib, nm-glib.h, nm-macros-internal.h, etc.
  31. 04 Dec, 2015 1 commit