1. 03 Apr, 2019 1 commit
  2. 04 Feb, 2019 3 commits
  3. 22 Jan, 2019 2 commits
    • Thomas Haller's avatar
      libnm: always call clear_secrets() function for all properties · 08a0f682
      Thomas Haller authored
      And merge it with the version that uses no flags.
      Previously, clear_secrets(_with_flags()) was only implemented
      by NMSettingVpn. All other settings would only consider GObject-based
      As we will add secrets that have no GObject property, call the virtual
      function always, so that the setting can hook into this (for WireGuard
    • Thomas Haller's avatar
      libnm: support nm_setting_duplicate() for non-GObject base properties · 3a915a02
      Thomas Haller authored
      Add a hook so that we can overwrite the property info.
      Yes, this is an API/ABI change for NMSettingClass, which is in a
      header file. But this is not API that we want to support. Users must
      not use this. Alternatively, I could hook the callback into
      NMSettInfoSetting, but either works.
  4. 11 Jan, 2019 1 commit
    • Thomas Haller's avatar
      libnm: rework compare_property() implementation for NMSetting · 885c872d
      Thomas Haller authored
      NMSetting's compare_property() has and had two callers:
      nm_setting_compare() and nm_setting_diff().
      compare_property() accepts a NMSettingCompareFlags argument, but
      at the same time, both callers have another complex (and
      inconsistent!) set of pre-checks for shortcuting the call of
      compare_property(): should_compare_prop().
      Merge should_compare_prop() into compare_property(). This way,
      nm_setting_compare() and nm_setting_diff() has less additional
      code, and are simpler to follow. Especially nm_setting_compare()
      is now trivial. And nm_setting_diff() is still complicated, but
      not related to the question how the property compares or whether
      it should be compared at all.
      If you want to know whether it should be compared, all you need to do
      now is follow NMSettingClass.compare_property().
      This changes function pointer NMSettingClass.compare_property(),
      which is public API. However, no user can actually use this (and shall
      not!), because _nm_setting_class_commit_full() etc. is private API. A
      user outside of libnm-core cannot create his/her own subclasses of
      NMSetting, and never could in the past. So, this API/ABI change doesn't
  5. 10 Jan, 2019 1 commit
  6. 07 Jan, 2019 1 commit
    • Thomas Haller's avatar
      libnm: cleanup secret-flags setter and getter · 4a5514dc
      Thomas Haller authored
      There are 3 kinds of secret flag implementations:
      1) regular properties have a GObject property and a corresponding
        "-flags" property.
      2) NMSettingVpn handles this entirely differently
      3) NMSettingWirelessSecurity's WEP keys, where the secret keys
         share a flags property that does not follow the same naming
         scheme as 1).
      The getter and setter had a boolean "verifiy_secret", only to
      handle 3). Drop that parameter. Don't let NMSettingWirelessSecurity
      call the parent's implementation for WEP keys. Just let it handle
      it directly.
  7. 17 Sep, 2018 1 commit
  8. 10 Aug, 2018 2 commits
    • Thomas Haller's avatar
      libnm: add generic-data for implementing NMSetting · 4e0f1b16
      Thomas Haller authored
      Add a new way how NMSetting subclasses can be implemented.
      Currently, most NMSetting implementations realize all their properties
      via GObject properties. That has some downsides:
       - the biggest one, is the large effort to add new properties.
         Most of them are implemented on a one-by-one basis and they come
         with additional API (like native getter functions).
         It makes it cumbersome to add more properties.
       - for certain properties, it's hard to encode them entirely in
         a GObject property. That results in unusable API like
         NM_SETTING_USER_DATA. These complex valued properties only
         exist, because we currently always need GObject properties
         to even implement simple functionality. For example,
         nm_setting_duplicate() is entirely implemented via
         nm_setting_enumerate_values(), which can only iterate
         GObject properies. There is no reason why this is necessary.
         Note also how nmcli badly handles bond options and VPN
         data. That is only a shortcoming of nmcli and wouldn't
         need to be that way. But it happend, because we didn't
         keep an open mind that settings might be more than just
         accessing GObject properties.
       - a major point of NMSetting is to convert to/from a GVariant
         from the D-Bus API. As NMSetting needs to squeeze all values
         into the static GObject structure, there is no place to
         encode invalid or unknown properties. Optimally,
         _nm_setting_new_from_dbus() does not loose any information
         and a subsequent _nm_setting_to_dbus() can restore the original
         variant. That is interesting, because we want that an older
         libnm client can talk to a newer NetworkManager version. The
         client needs to handle unknown properties gracefully to stay
         forward compatible. However, it also should not just drop the
         properties on the floor.
         Note however, optimally we want that nm_setting_verify() still
         can reject settings that have such unknown/invalid values. So,
         it should be possible to create an NMSetting instance without
         error or loosing information. But verify() should be usable to
         identify such settings as invalid.
      They also have a few upsides.
       - libnm is heavily oriented around GObject. So, we generate
         our nm-settings manual based on the gtk-doc. Note however,
         how we fail to generate a useful manual for bond.options.
         Also note, that there is no reason we couldn't generate
         great documentation, even if the properties are not GObject
       - GObject properties do give some functionality like meta-data,
         data binding and notification. However, the meta-data is not
         sufficient on its own. Note how keyfile and nmcli need extensive
         descriptor tables on top of GObject properties, to make this
         useful. Note how GObject notifications for NMSetting instances
         are usually not useful, aside for data binding like nmtui does.
      Also note how NMSettingBond already follows a different paradigm
      than using GObject properties. Nowdays, NMSettingBond is considered
      a mistake (related bug rh#1032808). Many ideas of NMSettingBond
      are flawed, like exposing an inferiour API that reduces everything
      to a string hash. Also, it only implemented the options hash inside
      NMSettingBond. That means, if we would consider this a good style,
      we would have to duplicate this approach in each new setting
      Add a new style to track data for NMSetting subclasses. It keeps
      an internal hash table with all GVariant properies. Also, the
      functionality is hooked into NMSetting base class, so all future
      subclasses that follow this way, can benefit from this. This approach
      has a few similiarties with NMSettingBond, but avoids its flaws.
      With this, we also no longer need GObject properties (if we would
      also implement generating useful documentation based on non-gkt-doc).
      They may be added as accessors if they are useful, but there is no
      need for them.
      Also, handling the properties as a hash of variants invites for a
      more generic approach when handling them. While we still could add
      accessors that operate on a one-by-one bases, this leads to a more
      generic usage where we apply common functionality to a set of properties.
      Also, this is for the moment entirely internal and an implementation
      detail. It's entirely up to the NMSetting subclass to make use of this
      new style. Also, there are little hooks for the subclass available.
      If they turn out to be necessary, they might be added. However, for
      the moment, the functionality is restricted to what is useful and
    • Thomas Haller's avatar
      libnm: use NMMetaSettingInfo for tracking setting priority · 9c47e2ce
      Thomas Haller authored
      Previously, each (non abstract) NMSetting class had to register
      its name and priority via _nm_register_setting().
      Note, that libnm-core.la already links against "nm-meta-setting.c",
      which also redundantly keeps track of the settings name and gtype
      as well.
      Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta
      The goal is to get rid of private data structures that track
      meta data about NMSetting classes. In this case, "registered_settings"
      hash. Instead, we should have one place where all this meta data
      is tracked. This was, it is also accessible as internal API,
      which can be useful (for keyfile).
      Note that NMSettingClass has some overlap with NMMetaSettingInfo.
      One difference is, that NMMetaSettingInfo is const, while NMSettingClass
      is only initialized during the class_init() method. Appart from that,
      it's mostly a matter of taste, whether we attach meta data to
      NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed
      by NMMetaSettingType.
      Note, that previously, _nm_register_setting() was private API. That
      means, no user could subclass a functioning NMSetting instance. The same
      is still true: NMMetaSettingInfo is internal API and users cannot access
      it to create their own NMSetting subclasses. But that is almost desired.
      libnm is not designed, to be extensible via subclassing, nor is it
      clear why that would be a useful thing to do. One day, we should remove
      the NMSetting and NMSettingClass definitions from public headers. Their
      only use is subclassing the types, which however does not work.
      While libnm-core was linking already against nm-meta-setting.c,
      nm_meta_setting_infos was unreferenced. So, this change increases
      the binary size of libnm and NetworkManager (1032 bytes). Note however
      that roughly the same information was previously allocated at runtime.
  9. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      A simple style guide is instead: don't use these typedefs.
      No manual actions, I only ran the bash script:
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
  10. 30 Apr, 2018 1 commit
  11. 09 Mar, 2017 1 commit
    • Thomas Haller's avatar
      include: use double-quotes to include our own headers · 831286df
      Thomas Haller authored
      In practice, this should only matter when there are multiple
      header files with the same name. That is something we try
      to avoid already, by giving headers a distinct name.
      When building NetworkManager itself, we clearly want to use
      double-quotes for including our own headers.
      But we also want to do that in our public headers. For example:
          #include <stdio.h>
          #include <nm-1.h>
          void main() {
              printf ("INCLUDED %s/nm-2.h\n", SYMB);
          #include <nm-2.h>
          #define SYMB "1"
          #define SYMB "2"
      $ cc -I./2 -I./1 ./a.c
      $ ./a.out
      INCLUDED 2/nm-2.h
      Exceptions to this are
        - headers in "shared/nm-utils" that include <NetworkManager.h>. These
          headers are copied into projects and hence used like headers owned by
          those projects.
        - examples/C
  12. 20 Nov, 2015 1 commit
  13. 18 Nov, 2015 1 commit
  14. 18 Sep, 2015 1 commit
  15. 19 Nov, 2014 3 commits
  16. 28 Oct, 2014 2 commits
    • Dan Winship's avatar
      libnm-core: make nm_setting_verify() take an NMConnection · 9e5c7d91
      Dan Winship authored
      nm_setting_verify() took a GSList of other NMSettings, but really it
      would just be simpler all around to pass the NMConnection instead...
      This means that several formerly NMSetting-branded functions that
      operated on lists-of-settings now get replaced with
      NMConnection-branded functions instead.
    • Dan Winship's avatar
      libnm-core: add nm-core-types.h, remove cross-includes · b1087908
      Dan Winship authored
      Add nm-core-types.h, typedefing all of the GObject types in
      libnm-core; this is needed so that nm-setting.h can reference
      NMConnection in addition to nm-connection.h referencing NMSetting.
      Removing the cross-includes from the various headers causes lots of
      fallout elsewhere. (In particular, nm-utils.h used to include
      nm-connection.h, which included every setting header, so any file that
      included nm-utils.h automatically got most of the rest of libnm-core
      without needing to pay attention to specifics.) Fix this up by
      including nm-core-internal.h from those files that are now missing
  17. 22 Oct, 2014 2 commits
    • Dan Winship's avatar
      libnm-core: merge NMSetting*Error into NMConnectionError · 2d8e7bd2
      Dan Winship authored
      Each setting type was defining its own error type, but most of them
      had exactly the same three errors ("unknown", "missing property", and
      "invalid property"), and none of the other values was of much use
      programmatically anyway.
      So, this commit merges NMSettingError, NMSettingAdslError, etc, all
      into NMConnectionError. (The reason for merging into NMConnectionError
      rather than NMSettingError is that we also already have
      "NMSettingsError", for errors related to the settings service, so
      "NMConnectionError" is a less-confusable name for settings/connection
      errors than "NMSettingError".)
      Also, make sure that all of the affected error messages are localized,
      and (where appropriate) prefix them with the relevant property name.
      Renamed error codes:
      Remapped error codes:
      Dropped error codes (were previously defined but unused):
    • Dan Winship's avatar
      libnm-core: drop nm_setting_lookup_type_by_quark() · a7b1ee77
      Dan Winship authored
      nm_setting_lookup_type_by_quark() was only ever used in places that
      were still mistakenly assuming the old style of nm_connection_verify()
      errors, where the error message would contain only a property name and
      no further explanation. Fix those places to assume that the error will
      contain a real error message, and include both the setting name and
      the property name.
      Given that, there's no longer any need for
      nm_setting_lookup_type_by_quark(), so drop it.
  18. 12 Oct, 2014 2 commits
  19. 03 Oct, 2014 1 commit
    • Dan Winship's avatar
      libnm: make use of GParamSpecFlags and GParamSpecEnum · fcfb4b40
      Dan Winship authored
      Make enum- and flags-valued properties use GParamSpecEnum and
      GParamSpecFlags, for better introspectability/bindability.
      This requires no changes outside libnm-core/libnm since the expected
      data size is still the same with g_object_get()/g_object_set(), and
      GLib will internally convert between int/uint and enum/flags GValues
      when using g_object_get_property()/g_object_set_property().
  20. 18 Sep, 2014 1 commit
    • Dan Winship's avatar
      libnm-core: change connection hash tables to variants in API · acf86f68
      Dan Winship authored
      In preparation for porting to GDBus, make nm_connection_to_dbus(),
      etc, represent connections as GVariants of type 'a{sa{sv}}' rather
      than as GHashTables-of-GHashTables-of-GValues.
      This means we're constantly converting back and forth internally, but
      this is just a stepping stone on the way to the full GDBus port, and
      all of that code will go away again later.
  21. 04 Sep, 2014 3 commits
    • Dan Winship's avatar
      libnm-core: drop nm_{setting,connection}_get_virtual_iface_name() · 7314256b
      Dan Winship authored
      Since we enforce the fact that bond, bridge, team, and vlan
      interface-name properties match NMSettingConnection:interface-name,
      nm_connection_get_virtual_iface_name() can be replaced with
      nm_connection_get_interface_name() basically everywhere.
      The one place this doesn't work is with InfiniBand partitions (where
      get_virtual_iface_name() was actually computing the name), but for the
      most part we only need to care about the interface names of InfiniBand
      partitions in places where we also already need to do some other
      InfiniBand-specific handling as well, so we can use an
      InfiniBand-specific method
      (nm_setting_infiniband_get_virtual_interface_name()) to get it.
      (Also, while updating nm_device_get_virtual_device_description(), fix
      it to handle InfiniBand partitions too.)
    • Dan Winship's avatar
      libnm-core: rename NMConnection to/from_hash methods · 773d3f0a
      Dan Winship authored
      Rename nm_connection_to_hash() to nm_connection_to_dbus(), and
      nm_connection_new_from_hash() to nm_connection_new_from_dbus(). In
      addition to clarifying that this is specifically the D-Bus
      serialization format, these names will also work better in the
      GDBus-based future where the serialization format is GVariant, not
      Also, move NMSettingHashFlags to nm-connection.h, and rename it
    • Dan Winship's avatar
      libnm-core: make the NMSetting hash methods private · c9653a9e
      Dan Winship authored
      Make nm_setting_to_hash() and nm_setting_new_from_hash() private, and
      remove the public nm_setting_update_secrets() wrapper around the
      existing private _nm_setting_update_secrets().
      These functions should really only be called from the corresponding
      NMConnection-level methods, and in particular, with certain
      compatibility properties in the future, we will need to consider the
      entire connection all at once when setting properties, so it won't
      make sense to serialize/deserialize a single setting in isolation.
  22. 22 Aug, 2014 1 commit
  23. 16 Aug, 2014 2 commits
    • Dan Winship's avatar
      libnm-core: move some fake NMConnection methods over to NMSetting · 32c26a85
      Dan Winship authored
      nm_connection_lookup_setting_type() and
      nm_connection_lookup_setting_type_by_quark() have nothing to do with
      NMConnection. So move them to NMSetting (and rename them to
      nm_setting_lookup_type() and nm_setting_lookup_type_by_quark()).
    • Dan Winship's avatar
      all: fix up multiple-include-guard defines · c81fb49a
      Dan Winship authored
      Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
      libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
      guard, which meant that nm-test-utils.h could not tell which of them
      was being included (and so, eg, if you tried to include
      nm-ip4-config.h in a libnm test, it would fail to compile because
      nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
      Fix this by changing the include guards in the non-API-stable parts of
      the tree:
        - libnm-glib/nm-ip4-config.h remains   NM_IP4_CONFIG_H
        - libnm/nm-ip4-config.h now uses     __NM_IP4_CONFIG_H__
        - src/nm-ip4-config.h now uses       __NETWORKMANAGER_IP4_CONFIG_H__
      And likewise for all other headers.
      The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
      src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
      __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
      consistent with the general scheme, do still mostly make sense in
  24. 01 Aug, 2014 4 commits
    • Dan Winship's avatar
      libnm: add NetworkManager.h, disallow including individual headers · d0b05b34
      Dan Winship authored
      Add NetworkManager.h, which includes all of the other NM header, and
      require all external users of libnm to use that rather than the
      individual headers.
      (An exception is made for nm-dbus-interface.h,
      nm-vpn-dbus-interface.h, and nm-version.h, which can be included
    • Dan Winship's avatar
      libnm: fix up class struct reserved slots · 2fc55941
      Dan Winship authored
      Add reserved slots to those classes that were missing them (or had run
      out), and sync up the number of slots across classes:
        - 8 slots for "important" classes, abstract base classes, and
          classes we expect we might need to add new virtual methods or
          signals to later.
        - 4 for everything else
      Also, rearrange the class elements in a few places into standard order
      (signals first, then methods).
    • Dan Winship's avatar
      libnm: remove all deprecated functions and types · 054c12ea
      Dan Winship authored
      Remove deprecated functions and enum types.
      For now, deprecated properties are still around, because removing them
      would cause warnings when talking to older implementations.
    • Dan Winship's avatar
      libnm: add libnm/libnm-core (part 1) · d595f784
      Dan Winship authored
      This commit begins creating the new "libnm", which will replace
      libnm-util and libnm-glib.
      The main reason for the libnm-util/libnm-glib split is that the daemon
      needs to link to libnm-util (to get NMSettings, NMConnection, etc),
      but can't link to libnm-glib (because it uses many of the same type
      names as the NetworkManager daemon. eg, NMDevice). So the daemon links
      to only libnm-util, but basically all clients link to both.
      With libnm, there will be only a single client-visible library, and
      NetworkManager will internally link against a private "libnm-core"
      containing the parts that used to be in libnm-util.
      (The "libnm-core" parts still need to be in their own directory so
      that the daemon can see those header files without also seeing the
      ones in libnm/ that conflict with its own headers.)
      [This commit just copies the source code from libnm-util/ to
      libnm-core/, and libnm-glib/ to libnm/:
        mkdir -p libnm-core/tests/
        mkdir -p libnm/tests/
        cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/
        rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch]
        cp libnm-util/tests/*.[ch] libnm-core/tests/
        cp libnm-glib/*.[ch] libnm/
        rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch]
        cp libnm-glib/tests/*.[ch] libnm/tests/
  25. 15 Jul, 2014 1 commit