1. 01 Feb, 2019 6 commits
    • Thomas Haller's avatar
      wifi-p2p: rename Wi-Fi P2P · 09090f26
      Thomas Haller authored
      After renaming the files, also rename all the content
      to follow the "Wi-Fi P2P" naming scheme.
      09090f26
    • Thomas Haller's avatar
      wifi-p2p: rename files for consistent Wi-Fi P2P naming · 0420fa1f
      Thomas Haller authored
      We named the types inconsistently:
      
        - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h")
      
        - "p2p" ("libnm/nm-p2p-peer.h")
      
        - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h")
      
      It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi"
      specific name. It's not just peer-to-peer, it's Wi-Fi P2P.
      Yes, there is an inconsistency now, because there is already
      "libnm/nm-access-point.h".
      
      It seems to me (from looking at the internet), that the name "Wi-Fi P2P"
      is more common than "P2P Wi-Fi" -- although both are used. There is also
      the name "Wi-Fi Direct". But it's not clear which name should be
      preferred here, so stick to "Wi-Fi P2P".
      
      In this first commit only rename the files. The following commit will
      rename the content.
      0420fa1f
    • Thomas Haller's avatar
      libnm/device-p2p-wifi: drop API that still needs consideration · 6e45cd90
      Thomas Haller authored
      Having synchronous API is wrong, or at least questionable.
      Granted, libnm isn't currently very good about the exact order
      of things to happen. However synchronous API by design delays events
      while waiting for the response and hence messes up the ordering.
      
      Maybe synchronous API should not be added to libnm.
      
      Or at least, if we have synchronous API, we certainly need an asynchrnous
      variant as well (which is still missing).
      
      As synchronous API is not preferred, it should also be named
      nm_some_thing_sync(), accompanied by nm_some_thing() and
      nm_some_thing_finish(). The name for the synchronous method should be the
      odd one and we shouldn't have an nm_some_thing_async(). Yes, libnm is not
      consistend about that.
      
      I am going to drop this API for the moment.
      6e45cd90
    • Thomas Haller's avatar
      libnm/device-p2p-wifi: drop unused code · 4f8852b2
      Thomas Haller authored
      If this is going to be implemented, revert the patch.
      4f8852b2
    • Thomas Haller's avatar
      libnm: various cleanup of NMP2PPeer and NMDeviceP2PWifi · c6c41eb1
      Thomas Haller authored
      - fix leaking hw_address in finalize().
      
      - reorder code.
      
      - avoid double tabs in GObject property definitions.
      
      - hide struct definitions from header.
      
      - don't use signal slots in class structure.
      
      - use NM_GOBJECT_PROPERTIES_DEFINE_BASE().
      
      - add missing NM_AVAILABLE_IN_1_16 annotations.
      c6c41eb1
    • Thomas Haller's avatar
      libnm/device-p2p-wifi: cleanup peers handling · 41b2d8c6
      Thomas Haller authored
      Don't reallocate peers-array nor set it to %NULL. Instead,
      just emit the signal for the peers and take them out one-by-one.
      
      I am slightly surprised, that the peers array does not need to hold
      a reference on the NMP2PPeer instances. But that seems intentional.
      I think, the libnm code here should be significantly reworked, but
      that is for another time.
      
      Also, delay clearing the pointers until finalize() method. For
      the most part, it shouldn't make a difference. Still avoid having
      the instance in a badly defined state during dispose() (which
      theoretically could be called multiple times).
      41b2d8c6
  2. 27 Jan, 2019 5 commits
  3. 24 Jan, 2019 1 commit
  4. 21 Jan, 2019 1 commit
  5. 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
      correspond.
      
      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)
      fbb038af
  6. 02 Jan, 2019 1 commit
    • Thomas Haller's avatar
      libnm: use "libnm-systemd-shared.a" in "libnm-core.la" (and "libnm.so") · c4512f83
      Thomas Haller authored
      It's not yet used, but it will be. We will need nm_sd_utils_unbase64mem()
      to strictly validate WireGuard settings, which contain keys in base64 encoding.
      
      Note that we also need a stub implementation for logging. This will do
      nothing for all logging from "libnm-systemd-shared.a". This makes
      sense because "libnm.so" as a library should not log directly. Also,
      "libnm.so" will only use a small portion of "libnm-systemd-shared.a" which
      doesn't log anything. Thus this code is unused and dropped by the linker
      with "--gc-sections".
      c4512f83
  7. 20 Dec, 2018 1 commit
  8. 12 Dec, 2018 1 commit
  9. 29 Nov, 2018 1 commit
  10. 21 Nov, 2018 2 commits
  11. 19 Nov, 2018 2 commits
    • Thomas Haller's avatar
      all: rename "bind" option for AddAndActivateConnection2 to "bind-activation" · 7420ae83
      Thomas Haller authored
      "bind" specifically binds the lifetime of the activation (NMActiveConnection).
      In combination with "persist=volatile", the lifetime of the NMSettingsConnection
      is indirectly bound to the NMActiveConnection. But still these concepts make sense
      independently.
      In the future, it may make sense to also bind the lifetime of the NMSettingsConnection
      to the D-Bus client. Hence, rename the option to allow for the distinction.
      
      Also, belatedly fix libnm comment about "bind" only working with
      "persist" "volatile".
      
      Fixes: eb883e34
      7420ae83
    • Thomas Haller's avatar
      libnm: drop "_async" suffix from nm_client_add_and_activate_connection_options() · 26eaca89
      Thomas Haller authored
      Synchronous D-Bus calls seems harmful to me, such API should not be
      added to libnm. As such, all API is by default and preferably "_async".
      
      Don't add an "_async" suffix. While we are not consistent in libnm about
      this, I think for new code we should.
      26eaca89
  12. 18 Nov, 2018 1 commit
  13. 17 Nov, 2018 1 commit
  14. 12 Nov, 2018 1 commit
  15. 25 Oct, 2018 3 commits
  16. 22 Oct, 2018 3 commits
  17. 19 Oct, 2018 1 commit
  18. 24 Sep, 2018 1 commit
  19. 21 Sep, 2018 1 commit
  20. 17 Sep, 2018 1 commit
  21. 14 Sep, 2018 4 commits
    • Thomas Haller's avatar
      autoptr: add missing autoptr cleanup functions · 070e4e39
      Thomas Haller authored
      (cherry picked from commit c1b647d5)
      070e4e39
    • Thomas Haller's avatar
      c1b647d5
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · fe866fbe
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      
      We have API
      
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      flexible.
      
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      
      (cherry picked from commit a10156f5)
      fe866fbe
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · a10156f5
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      
      We have API
      
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      flexible.
      
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      a10156f5
  22. 06 Sep, 2018 1 commit