1. 07 May, 2019 2 commits
    • Thomas Haller's avatar
      libnm: use macro and designated initializers for NMVariantAttributeSpec · 86dc50d4
      Thomas Haller authored
      I think initializing structs should (almost) be always done with designated
      initializers, because otherwise it's easy to get the order wrong. The
      problem is that otherwise the order of fields gets additional meaning
      not only for the memory layout, but also for the code that initialize
      the structs.
      Add a macro NM_VARIANT_ATTRIBUTE_SPEC_DEFINE() that replaces the other
      (duplicate) macros. This macro also gets it right to mark the struct as
    • Thomas Haller's avatar
      libnm: mark NMVariantAttributeSpec pointers as const · 4e3955e6
      Thomas Haller authored
      This actually allows the compiler/linker to mark the memory as read-only and any
      modification will cause a segmentation fault.
      I would also think that it allows the compiler to put the structure directly
      beside the outer constant array (in which this pointer is embedded). That is good
  2. 01 May, 2019 2 commits
    • Thomas Haller's avatar
      libnm: unify property-to-dbus handling of NMSetting · 0d1b8ee9
      Thomas Haller authored
      Merge the function pointer get_func() into to_dbus_fcn().
      Previously, get_func() as handled separately from to_dbus_fnc()
      (formerly synth_func()). The notion was that synth-func would syntetize
      properties that are D-Bus only. But that distinction does not seem
      very helpful to me.
      Instaed, we want to convert a property to D-Bus. Period. The
      implementation should be handled uniformly. Hence, now that is
      all done by property_to_dbus().
      Note that property_to_dbus() is also called as default implementation
      for compare-property. At least, for properties that are backed by a
      GObject property.
    • Thomas Haller's avatar
      libnm: pass connection to compare_property() function · b1344b6b
      Thomas Haller authored
      We have certain artificial properties that not only depend on one
      property alone or that depend on a property in another(!) setting.
      For that, we have synth_func.
      Other than that, synth_func and get_func are really fundamentally
      similar and should be merged. That is because the distinction whether a
      property value is "synthetized" or just based on a plain property is
      minor. It's better to have the general concept of "convert property to
      GVariant" in one form only.
      Note that compare_property() is by default implemented based
      on get_func. Hence, if get_func and synth_func get merged,
      compare_property() will also require access to the NMConnection.
      Also it makes some sense: some properties are artificial and actually
      stored in "another" setting of the connection. But still, the property
      descriptor for the property is in this setting. The example is the
      "bond.interface-name" which only exists on D-Bus. It's stored as
      I don't really like to say "exists on D-Bus only". It's still a valid
      property, despite in NMSetting it's stored somehow differently (or not
      at all). So, this is also just a regular property for which we have a
      property-info vtable.
      Does it make sense to compare such properties? Maybe. But the point is that
      compare_property() function needs sometimes access to the entire
      connection. So add the argument.
  3. 26 Mar, 2019 2 commits
  4. 04 Feb, 2019 1 commit
  5. 15 Jan, 2019 2 commits
    • Thomas Haller's avatar
      libnm-core: reorder code in settings · 19141ef7
      Thomas Haller authored
      Order the code in our common way. No other changes.
      - ensure to include the main header first (directly after
      - reorder function definitions: get_property(), set_property(),
        *_init(), *_new(), finalize(), *_class_init().
    • Thomas Haller's avatar
      libnm-core: cleanup NMSetting's class initialization · a3d6976e
      Thomas Haller authored
      Unify the coding style for class-init functions in libnm-core.
      Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and
  6. 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
  7. 12 Dec, 2018 1 commit
  8. 06 Oct, 2018 1 commit
  9. 30 Sep, 2018 1 commit
    • Rafael Fontenelle's avatar
      Fix typos · 34fd6289
      Rafael Fontenelle authored
      [thaller@redhat.com: fix generated clients/common/settings-docs.h.in file
         and fix wrong change in src/systemd/src/libsystemd/sd-event/sd-event.c]
  10. 17 Sep, 2018 1 commit
  11. 10 Aug, 2018 3 commits
    • Thomas Haller's avatar
      libnm: rework setting metadata for property handling · 37938043
      Thomas Haller authored
      NMSetting internally already tracked a list of all proper GObject properties
      and D-Bus-only properties.
      Rework the tracking of the list, so that:
      - instead of attaching the data to the GType of the setting via
        g_type_set_qdata(), it is tracked in a static array indexed by
        NMMetaSettingType. This allows to find the setting-data by simple
        pointer arithmetic, instead of taking a look and iterating (like
        g_type_set_qdata() does).
        Note, that this is still thread safe, because the static table entry is
        initialized in the class-init function with _nm_setting_class_commit().
        And it only accessed by following a NMSettingClass instance, thus
        the class constructor already ran (maybe not for all setting classes,
        but for the particular one that we look up).
        I think this makes initialization of the metadata simpler to
        Previously, in a first phase each class would attach the metadata
        to the GType as setting_property_overrides_quark(). Then during
        nm_setting_class_ensure_properties() it would merge them and
        set as setting_properties_quark(). Now, during the first phase,
        we only incrementally build a properties_override GArray, which
        we finally hand over during nm_setting_class_commit().
      - sort the property infos by name and do binary search.
      Also expose this meta data types as internal API in nm-setting-private.h.
      While not accessed yet, it can prove beneficial, to have direct (internal)
      access to these structures.
      Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
      naming scheme. We already have 40+ subclasses of NMSetting that are called
      NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
      new, distinct name.
    • 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.
    • Thomas Haller's avatar
      libnm/trivial: cleanup variable names in settings' class-init functions · 23adc373
      Thomas Haller authored
      - Don't use @parent_class name. This local variable (and @object_class) is
        the class instance up-cast to the pointer types of the parents. The point
        here is not that it is the direct parent. The point is, that it's the
        NMSettingClass type.
        Also, it can only be used inconsistently, in face of NMSettingIP4Config,
        who's parent type is NMSettingIPConfig. Clearly, inside
        nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
        name. Consistently rename @parent_class to @setting_class.
      - Also rename the pointer to the own class to @klass. "setting_class" is also the
        wrong name for that, because the right name would be something like
        However, "klass" is preferred over the latter, because we commonly create new
        GObject implementations by copying an existing one. Generic names like "klass"
        and "self" inside a type implementation make that simpler.
      - drop useless comments like
           /* virtual functions */
           /* Properties */
        It's better to logically and visually structure the code, and avoid trival
        remarks about that. They only end up being used inconsistently. If you
        even need a stronger visual separator, then an 80 char /****/ line
        should be preferred.
  12. 11 Jul, 2018 2 commits