1. 28 Nov, 2019 1 commit
  2. 25 Nov, 2019 2 commits
    • Thomas Haller's avatar
      libnm: refactor caching of D-Bus objects in NMClient · ce0e898f
      Thomas Haller authored
      No longer use GDBusObjectMangaerClient and gdbus-codegen generated classes
      for the NMClient cache. Instead, use GDBusConnection directly and a
      custom implementation (NMLDBusObject) for caching D-Bus' ObjectManager
      data.
      
      CHANGES
      -------
      
      - This is a complete rework. I think the previous implementation was
      difficult to understand. There were unfixed bugs and nobody understood
      the code well enough to fix them. Maybe somebody out there understood the
      code, but I certainly did not. At least nobody provided patches to fix those
      issues. I do believe that this implementation is more straightforward and
      easier to understand. It removes a lot of layers of code. Whether this claim
      of simplicity is true, each reader must decide for himself/herself. Note
      that it is still fairly complex.
      
      - There was a lingering performance issue with large number of D-Bus
      objects. The patch tries hard that the implementation scales well. Of
      course, when we cache N objects that have N-to-M references to other,
      we still are fundamentally O(N*M) for runtime and memory consumption (with
      M being the number of references between objects). But each part should behave
      efficiently and well.
      
      - Play well with GMainContext. libnm code (NMClient) is generally not
      thread safe. However, it should work to use multiple instances in
      parallel, as long as each access to a NMClient is through the caller's
      GMainContext. This follows glib's style and effectively allows to use NMClient
      in a multi threaded scenario. This implies to stick to a main context
      upon construction and ensure that callbacks are only invoked when
      iterating that context. Also, NMClient itself shall never iterate the
      caller's context. This also means, libnm must never use g_idle_add() or
      g_timeout_add(), as those enqueue sources in the g_main_context_default()
      context.
      
      - Get ordering of messages right. All events are consistently enqueued
      in a GMainContext and processed strictly in order. For example,
      previously "nm-object.c" tried to combine signals and emit them on an
      idle handler. That is wrong, signals must be emitted in the right order
      and when they happen. Note that when using GInitable's synchronous initialization
      to initialize the NMClient instance, NMClient internally still operates fully
      asynchronously. In that case NMClient has an internal main context.
      
      - NMClient takes over most of the functionality. When using D-Bus'
      ObjectManager interface, one needs to handle basically the entire state
      of the D-Bus interface. That cannot be separated well into distinct
      parts, and even if you try, you just end up having closely related code
      in different source files. Spreading related code does not make it
      easier to understand, on the contrary. That means, NMClient is
      inherently complex as it contains most of the logic. I think that is
      not avoidable, but it's not as bad as it sounds.
      
      - NMClient processes D-Bus messages and state changes in separate steps.
      First NMClient unpacks the message (e.g. _dbus_handle_properties_changed()) and
      keeps track of the changed data. Then we update the GObject instances
      (_dbus_handle_obj_changed_dbus()) without emitting any signals yet. Finally,
      we emit all signals and notifications that were collected
      (_dbus_handle_changes_commit()). Note that for example during the initial
      GetManagedObjects() reply, NMClient receive a large amount of state at once.
      But we first apply all the changes to our GObject instances before
      emitting any signals. The result is that signals are always emitted in a moment
      when the cache is consistent. The unavoidable downside is that when you receive
      a property changed signal, possibly many other properties changed
      already and more signals are about to be emitted.
      
      - NMDeviceWifi no longer modifies the content of the cache from client side
      during poke_wireless_devices_with_rf_status(). The content of the cache
      should be determined by D-Bus alone and follow what NetworkManager
      service exposes. Local modifications should be avoided.
      
      - This aims to bring no API/ABI change, though it does of course bring
      various subtle changes in behavior. Those should be all for the better, but the
      goal is not to break any existing clients. This does change internal
      (albeit externally visible) API, like dropping NM_OBJECT_DBUS_OBJECT_MANAGER
      property and NMObject no longer implementing GInitableIface and GAsyncInitableIface.
      
      - Some uses of gdbus-codegen classes remain in NMVpnPluginOld, NMVpnServicePlugin
      and NMSecretAgentOld. These are independent of NMClient/NMObject and
      should be reworked separately.
      
      - While we no longer use generated classes from gdbus-codegen, we don't
      need more glue code than before. Also before we constructed NMPropertiesInfo and
      a had large amount of code to propagate properties from NMDBus* to NMObject.
      That got completely reworked, but did not fundamentally change. You still need
      about the same effort to create the NMLDBusMetaIface. Not using
      generated bindings did not make anything worse (which tells about the
      usefulness of generated code, at least in the way it was used).
      
      - NMLDBusMetaIface and other meta data is static and immutable. This
      avoids copying them around. Also, macros like NML_DBUS_META_PROPERTY_INIT_U()
      have compile time checks to ensure the property types matches. It's pretty hard
      to misuse them because it won't compile.
      
      - The meta data now explicitly encodes the expected D-Bus types and
      makes sure never to accept wrong data. That would only matter when the
      server (accidentally or intentionally) exposes unexpected types on
      D-Bus. I don't think that was previously ensured in all cases.
      For example, demarshal_generic() only cared about the GObject property
      type, it didn't know the expected D-Bus type.
      
      - Previously GDBusObjectManager would sometimes emit warnings (g_log()). Those
      probably indicated real bugs. In any case, it prevented us from running CI
      with G_DEBUG=fatal-warnings, because there would be just too many
      unrelated crashes. Now we log debug messages that can be enabled with
      "LIBNM_CLIENT_DEBUG=trace". Some of these messages can also be turned
      into g_warning()/g_critical() by setting LIBNM_CLIENT_DEBUG=warning,error.
      Together with G_DEBUG=fatal-warnings, this turns them into assertions.
      Note that such "assertion failures" might also happen because of a server
      bug (or change). Thus these are not common assertions that indicate a bug
      in libnm and are thus not armed unless explicitly requested. In our CI we
      should now always run with LIBNM_CLIENT_DEBUG=warning,error and
      G_DEBUG=fatal-warnings and to catch bugs. Note that currently
      NetworkManager has bugs in this regard, so enabling this will result in
      assertion failures. That should be fixed first.
      
      - Note that this changes the order in which we emit "notify:devices" and
      "device-added" signals. I think it makes the most sense to emit first
      "device-removed", then "notify:devices", and finally "device-added"
      signals.
      This changes behavior for commit 52ae28f6 ('libnm: queue
      added/removed signals and suppress uninitialized notifications'),
      but I don't think that users should actually rely on the order. Still,
      the new order makes the most sense to me.
      
      - In NetworkManager, profiles can be invisible to the user by setting
      "connection.permissions". Such profiles would be hidden by NMClient's
      nm_client_get_connections() and their "connection-added"/"connection-removed"
      signals.
      Note that NMActiveConnection's nm_active_connection_get_connection()
      and NMDevice's nm_device_get_available_connections() still exposes such
      hidden NMRemoteConnection instances. This behavior was preserved.
      
      NUMBERS
      -------
      
      I compared 3 versions of libnm.
      
        [1] 962297f9, current tip of nm-1-20 branch
        [2] 4fad8c7c, current master, immediate parent of this patch
        [3] this patch
      
      All tests were done on Fedora 31, x86_64, gcc 9.2.1-1.fc31.
      The libraries were build with
      
        $ ./contrib/fedora/rpm/build_clean.sh -g -w test -W debug
      
      Note that RPM build already stripped the library.
      
      ---
      
      N1) File size of libnm.so.0.1.0 in bytes. There currently seems to be a issue
        on Fedora 31 generating wrong ELF notes. Usually, libnm is smaller but
        in these tests it had large (and bogus) ELF notes. Anyway, the point
        is to show the relative sizes, so it doesn't matter).
      
        [1] 4075552 (102.7%)
        [2] 3969624 (100.0%)
        [3] 3705208 ( 93.3%)
      
      ---
      
      N2) `size /usr/lib64/libnm.so.0.1.0`:
      
                text             data              bss                dec               hex   filename
        [1]  1314569 (102.0%)   69980 ( 94.8%)   10632 ( 80.4%)   1395181 (101.4%)   1549ed   /usr/lib64/libnm.so.0.1.0
        [2]  1288410 (100.0%)   73796 (100.0%)   13224 (100.0%)   1375430 (100.0%)   14fcc6   /usr/lib64/libnm.so.0.1.0
        [3]  1229066 ( 95.4%)   65248 ( 88.4%)   13400 (101.3%)   1307714 ( 95.1%)   13f442   /usr/lib64/libnm.so.0.1.0
      
      ---
      
      N3) Performance test with test-client.py. With checkout of [2], run
      
      ```
      prepare_checkout() {
          rm -rf /tmp/nm-test && \
          git checkout -B test 4fad8c7c && \
          git clean -fdx && \
          ./autogen.sh --prefix=/tmp/nm-test && \
          make -j 5 install && \
          make -j 5 check-local-clients-tests-test-client
      }
      prepare_test() {
          NM_TEST_REGENERATE=1 NM_TEST_CLIENT_BUILDDIR="/data/src/NetworkManager" NM_TEST_CLIENT_NMCLI_PATH=/usr/bin/nmcli python3 ./clients/tests/test-client.py -v
      }
      do_test() {
        for i in {1..10}; do
            NM_TEST_CLIENT_BUILDDIR="/data/src/NetworkManager" NM_TEST_CLIENT_NMCLI_PATH=/usr/bin/nmcli python3 ./clients/tests/test-client.py -v || return -1
        done
        echo "done!"
      }
      prepare_checkout
      prepare_test
      time do_test
      ```
      
        [1]  real 2m14.497s (101.3%)     user 5m26.651s (100.3%)     sys  1m40.453s (101.4%)
        [2]  real 2m12.800s (100.0%)     user 5m25.619s (100.0%)     sys  1m39.065s (100.0%)
        [3]  real 1m54.915s ( 86.5%)     user 4m18.585s ( 79.4%)     sys  1m32.066s ( 92.9%)
      
      ---
      
      N4) Performance. Run NetworkManager from build [2] and setup a large number
      of profiles (551 profiles and 515 devices, mostly unrealized). This
      setup is already at the edge of what NetworkManager currently can
      handle. Of course, that is a different issue. Here we just check how
      long plain `nmcli` takes on the system.
      
      ```
      do_cleanup() {
          for UUID in $(nmcli -g NAME,UUID connection show | sed -n 's/^xx-c-.*:\([^:]\+\)$/\1/p'); do
              nmcli connection delete uuid "$UUID"
          done
          for DEVICE in $(nmcli -g DEVICE device status | grep '^xx-i-'); do
              nmcli device delete "$DEVICE"
          done
      }
      
      do_setup() {
          do_cleanup
          for i in {1..30}; do
              nmcli connection add type bond autoconnect no con-name xx-c-bond-$i ifname xx-i-bond-$i ipv4.method disabled ipv6.method ignore
              for j in $(seq $i 30); do
                  nmcli connection add type vlan autoconnect no con-name xx-c-vlan-$i-$j vlan.id $j ifname xx-i-vlan-$i-$j vlan.parent xx-i-bond-$i  ipv4.method disabled ipv6.method ignore
              done
          done
          systemctl restart NetworkManager.service
          sleep 5
      }
      
      do_test() {
          perf stat -r 50 -B nmcli 1>/dev/null
      }
      
      do_test
      ```
      
        [1]
      
         Performance counter stats for 'nmcli' (50 runs):
      
                    456.33 msec task-clock:u              #    1.093 CPUs utilized            ( +-  0.44% )
                         0      context-switches:u        #    0.000 K/sec
                         0      cpu-migrations:u          #    0.000 K/sec
                     5,900      page-faults:u             #    0.013 M/sec                    ( +-  0.02% )
             1,408,675,453      cycles:u                  #    3.087 GHz                      ( +-  0.48% )
             1,594,741,060      instructions:u            #    1.13  insn per cycle           ( +-  0.02% )
               368,744,018      branches:u                #  808.061 M/sec                    ( +-  0.02% )
                 4,566,058      branch-misses:u           #    1.24% of all branches          ( +-  0.76% )
      
                   0.41761 +- 0.00282 seconds time elapsed  ( +-  0.68% )
      
        [2]
      
         Performance counter stats for 'nmcli' (50 runs):
      
                    477.99 msec task-clock:u              #    1.088 CPUs utilized            ( +-  0.36% )
                         0      context-switches:u        #    0.000 K/sec
                         0      cpu-migrations:u          #    0.000 K/sec
                     5,948      page-faults:u             #    0.012 M/sec                    ( +-  0.03% )
             1,471,133,482      cycles:u                  #    3.078 GHz                      ( +-  0.36% )
             1,655,275,369      instructions:u            #    1.13  insn per cycle           ( +-  0.02% )
               382,595,152      branches:u                #  800.433 M/sec                    ( +-  0.02% )
                 4,746,070      branch-misses:u           #    1.24% of all branches          ( +-  0.49% )
      
                   0.43923 +- 0.00242 seconds time elapsed  ( +-  0.55% )
      
        [3]
      
         Performance counter stats for 'nmcli' (50 runs):
      
                    352.36 msec task-clock:u              #    1.027 CPUs utilized            ( +-  0.32% )
                         0      context-switches:u        #    0.000 K/sec
                         0      cpu-migrations:u          #    0.000 K/sec
                     4,790      page-faults:u             #    0.014 M/sec                    ( +-  0.26% )
             1,092,341,186      cycles:u                  #    3.100 GHz                      ( +-  0.26% )
             1,209,045,283      instructions:u            #    1.11  insn per cycle           ( +-  0.02% )
               281,708,462      branches:u                #  799.499 M/sec                    ( +-  0.01% )
                 3,101,031      branch-misses:u           #    1.10% of all branches          ( +-  0.61% )
      
                   0.34296 +- 0.00120 seconds time elapsed  ( +-  0.35% )
      
      ---
      
      N5) same setup as N4), but run `PAGER= /bin/time -v nmcli`:
      
        [1]
      
              Command being timed: "nmcli"
              User time (seconds): 0.42
              System time (seconds): 0.04
              Percent of CPU this job got: 107%
              Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.43
              Average shared text size (kbytes): 0
              Average unshared data size (kbytes): 0
              Average stack size (kbytes): 0
              Average total size (kbytes): 0
              Maximum resident set size (kbytes): 34456
              Average resident set size (kbytes): 0
              Major (requiring I/O) page faults: 0
              Minor (reclaiming a frame) page faults: 6128
              Voluntary context switches: 1298
              Involuntary context switches: 1106
              Swaps: 0
              File system inputs: 0
              File system outputs: 0
              Socket messages sent: 0
              Socket messages received: 0
              Signals delivered: 0
              Page size (bytes): 4096
              Exit status: 0
      
        [2]
              Command being timed: "nmcli"
              User time (seconds): 0.44
              System time (seconds): 0.04
              Percent of CPU this job got: 108%
              Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.44
              Average shared text size (kbytes): 0
              Average unshared data size (kbytes): 0
              Average stack size (kbytes): 0
              Average total size (kbytes): 0
              Maximum resident set size (kbytes): 34452
              Average resident set size (kbytes): 0
              Major (requiring I/O) page faults: 0
              Minor (reclaiming a frame) page faults: 6169
              Voluntary context switches: 1849
              Involuntary context switches: 142
              Swaps: 0
              File system inputs: 0
              File system outputs: 0
              Socket messages sent: 0
              Socket messages received: 0
              Signals delivered: 0
              Page size (bytes): 4096
              Exit status: 0
      
        [3]
      
              Command being timed: "nmcli"
              User time (seconds): 0.32
              System time (seconds): 0.02
              Percent of CPU this job got: 102%
              Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.34
              Average shared text size (kbytes): 0
              Average unshared data size (kbytes): 0
              Average stack size (kbytes): 0
              Average total size (kbytes): 0
              Maximum resident set size (kbytes): 29196
              Average resident set size (kbytes): 0
              Major (requiring I/O) page faults: 0
              Minor (reclaiming a frame) page faults: 5059
              Voluntary context switches: 919
              Involuntary context switches: 685
              Swaps: 0
              File system inputs: 0
              File system outputs: 0
              Socket messages sent: 0
              Socket messages received: 0
              Signals delivered: 0
              Page size (bytes): 4096
              Exit status: 0
      
      ---
      
      N6) same setup as N4), but run `nmcli monitor` and look at `ps aux` for
        the RSS size.
      
            USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
        [1] me     1492900 21.0  0.2 461348 33248 pts/10   Sl+  15:02   0:00 nmcli monitor
        [2] me     1490721  5.0  0.2 461496 33548 pts/10   Sl+  15:00   0:00 nmcli monitor
        [3] me     1495801 16.5  0.1 459476 28692 pts/10   Sl+  15:04   0:00 nmcli monitor
      ce0e898f
    • Rafael Fontenelle's avatar
  3. 11 Nov, 2019 1 commit
  4. 31 Oct, 2019 1 commit
  5. 30 Oct, 2019 2 commits
  6. 23 Oct, 2019 2 commits
  7. 23 Sep, 2019 1 commit
    • Thomas Haller's avatar
      bluetooth: refactor BlueZ handling and let NMBluezManager cache ObjectManager data · 4154d961
      Thomas Haller authored
      This is a complete refactoring of the bluetooth code.
      
      Now that BlueZ 4 support was dropped, the separation of NMBluezManager
      and NMBluez5Manager makes no sense. They should be merged.
      
      At that point, notice that BlueZ 5's D-Bus API is fully centered around
      D-Bus's ObjectManager interface. Using that interface, we basically only
      call GetManagedObjects() once and register to InterfacesAdded,
      InterfacesRemoved and PropertiesChanged signals. There is no need to
      fetch individual properties ever.
      
      Note how NMBluezDevice used to query the D-Bus properties itself by
      creating a GDBusProxy. This is redundant, because when using the ObjectManager
      interfaces, we have all information already.
      
      Instead, let NMBluezManager basically become the client-side cache of
      all of BlueZ's ObjectManager interface. NMBluezDevice was mostly concerned
      about caching the D-Bus interface's state, tracking suitable profiles
      (pan_connection), and moderate between bluez and NMDeviceBt.
      These tasks don't get simpler by moving them to a seprate file. Let them
      also be handled by NMBluezManager.
      
      I mean, just look how it was previously: NMBluez5Manager registers to
      ObjectManager interface and sees a device appearing. It creates a
      NMBluezDevice object and registers to its "initialized" and
      "notify:usable" signal. In the meantime, NMBluezDevice fetches the
      relevant information from D-Bus (although it was already present in the
      data provided by the ObjectManager) and eventually emits these usable
      and initialized signals.
      Then, NMBlue5Manager emits a "bdaddr-added" signal, for which NMBluezManager
      creates the NMDeviceBt instance. NMBluezManager, NMBluez5Manager and
      NMBluezDevice are strongly cooperating to the point that it is simpler
      to merge them.
      
      This is not mere refactoring. This patch aims to make everything
      asynchronously and always cancellable. Also, it aims to fix races
      and inconsistencies of the state.
      
      - Registering to a NAP server now waits for the response and delays
        activation of the NMDeviceBridge accordingly.
      
      - For NAP connections we now watch the bnep0 interface in platform, and tear
        down the device when it goes away. Bluez doesn't send us a notification
        on D-Bus in that case.
      
      - Rework establishing a DUN connection. It no longer uses blocking
        connect() and does not block until rfcomm device appears. It's
        all async now. It also watches the rfcomm file descriptor for
        POLLERR/POLLHUP to notice disconnect.
      
      - drop nm_device_factory_emit_component_added() and instead let
        NMDeviceBt directly register to the WWan factory's "added" signal.
      4154d961
  8. 03 Sep, 2019 2 commits
  9. 15 Aug, 2019 2 commits
  10. 12 Aug, 2019 1 commit
  11. 15 Jul, 2019 1 commit
  12. 10 Jul, 2019 1 commit
  13. 29 Jun, 2019 1 commit
  14. 20 Jun, 2019 1 commit
    • Thomas Haller's avatar
      settings: drop ibft settings plugin · 74641be8
      Thomas Haller authored
      The functionality of the ibft settings plugin is now handled by
      nm-initrd-generator. There is no need for it anymore, drop it.
      
      Note that ibft called iscsiadm, which requires CAP_SYS_ADMIN to work
      ([1]). We really want to drop this capability, so the current solution
      of a settings plugin (as it is implemented) is wrong. The solution
      instead is nm-initrd-generator.
      
      Also, on Fedora the ibft was disabled and probably on most other
      distributions as well. This was only used on RHEL.
      
      [1] https://bugzilla.redhat.com/show_bug.cgi?id=1371201#c7
      74641be8
  15. 11 Jun, 2019 1 commit
    • Thomas Haller's avatar
      all: drop emacs file variables from source files · c0e075c9
      Thomas Haller authored
      We no longer add these. If you use Emacs, configure it yourself.
      
      Also, due to our "smart-tab" usage the editor anyway does a subpar
      job handling our tabs. However, on the upside every user can choose
      whatever tab-width he/she prefers. If "smart-tabs" are used properly
      (like we do), every tab-width will work.
      
      No manual changes, just ran commands:
      
          F=($(git grep -l -e '-\*-'))
          sed '1 { /\/\* *-\*-  *[mM]ode.*\*\/$/d }'     -i "${F[@]}"
          sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"
      
      Check remaining lines with:
      
          git grep -e '-\*-'
      
      The ultimate purpose of this is to cleanup our files and eventually use
      SPDX license identifiers. For that, first get rid of the boilerplate lines.
      c0e075c9
  16. 28 May, 2019 2 commits
  17. 27 May, 2019 1 commit
  18. 23 May, 2019 2 commits
    • Thomas Haller's avatar
      libnm: rework team handling of JSON config · 13f6f3a4
      Thomas Haller authored
      Completely refactor the team/JSON handling in libnm's NMSettingTeam and
      NMSettingTeamPort.
      
      - team handling was added as rh#1398925. The goal is to have a more
        convenient way to set properties than constructing JSON. This requires
        libnm to implement the hard task of parsing JSON (and exposing well-understood
        properties) and generating JSON (based on these "artificial" properties).
        But not only libnm. In particular nmcli and the D-Bus API must make this
        "simpler" API accessible.
      
      - since NMSettingTeam and NMSettingTeamPort are conceptually the same,
        add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
        handle the similar code side-by-sdie.
        The setting classes now just delegate for everything to NMTeamSetting.
      
      - Previously, there was a very fuzzy understanding of the provided
        JSON config. Tighten that up, when setting a JSON config it
        regenerates/parses all other properties and tries to make the
        best of it. When modifying any abstraction property, the entire
        JSON config gets regenerated. In particular, don't try to merge
        existing JSON config with the new fields. If the user uses the
        abstraction API, then the entire JSON gets replaced.
      
        For example note that nm_setting_team_add_link_watcher() would not
        be reflected in the JSON config (a bug). That only accidentally worked
        because client would serializing the changed link watcher to
        GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
        which would renerate the JSON, and finally persist it to disk. But
        as far as libnm is concerned, nm_setting_team_add_link_watcher() would
        bring the settings instance in an inconsistent state where JSON and
        the link watcher property disagree. Setting any property must
        immediately update both the JSON and the abstraction API.
      
      - when constucting a team setting from D-Bus, we would previously parse
        both "config" and abstraction properties. That is wrong. Since our
        settings plugins only support JSON, all information must be present
        in the JSON config anyway. So, when "config" is present, only the JSON
        must be parsed. In the best case, the other information is redudant and
        contributes nothing. In the worse case, they information differs
        (which might happen if the client version differs from the server
        version). As the settings plugin only supports JSON, it's wrong to
        consider redundant, differing information from D-Bus.
      
      - we now only convert string to JSON or back when needed. Previously,
        setting a property resulted in parsing several JSON multiple times
        (per property). All operations should now scale well and be reasonably
        efficient.
      
      - also the property-changed signals are now handled correctly. Since
        NMTeamSetting knows the current state of all attributes, it can emit
        the exact property changed signals for what changed.
      
      - we no longer use libjansson to generate the JSON. JSON is supposed
        to be a machine readable exchange format, hence a major goal is
        to be easily handled by applications. While parsing JSON is not so
        trivial, writing a well-known set of values to JSON is.
        The advantage is that when you build libnm without libjansson support,
        then we still can convert the artificial properties to JSON.
      
      - Requiring libjansson in libnm is a burden, because most of the time
        it is not needed (as most users don't create team configurations). With
        this change we only require it to parse the team settings (no longer to
        write them). It should be reasonably simple to use a more minimalistic
        JSON parser that is sufficient for us, so that we can get rid of the
        libjansson dependency (for libnm). This also avoids the pain that we have
        due to the symbol collision of libjansson and libjson-glib.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1691619
      13f6f3a4
    • Thomas Haller's avatar
      ifcfg-rh: don't check for errors reading team settings in ifcfg-rh · d31622a6
      Thomas Haller authored
      We have nm_setting_verify() for a purpose.
      
      The checks that ifcfg-rh reader does are either
      
        - redundant (and thus unnecessary)
      
        - wrong (and thus we cannot read valid settings)
      
        - should belong to libnm's nm_setting_verify().
      
      NMSettingTeam/NMSettingTeamPort are already very libraral and don't do
      almost any strict validation. Previously, ifcfg reader would be even more
      liberal. If there is totally invalid data in the profile, reading the profile
      should fail.
      d31622a6
  19. 15 May, 2019 2 commits
  20. 04 May, 2019 1 commit
  21. 01 May, 2019 2 commits
  22. 25 Apr, 2019 1 commit
  23. 20 Apr, 2019 2 commits
  24. 18 Apr, 2019 2 commits
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · d984b2ce
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
      
      Reasons:
      
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
      
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
      
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      
      (cherry picked from commit 80db06f7)
      d984b2ce
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · 80db06f7
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
      
      Reasons:
      
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
      
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
      
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      80db06f7
  25. 17 Apr, 2019 2 commits
  26. 16 Apr, 2019 1 commit
    • Lubomir Rintel's avatar
      all: goodbye libnm-glib · 5801f89f
      Lubomir Rintel authored
      This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
      The it has been replaced with libnm since NetworkManager 1.0, disabled
      by default since 1.12 and no up-to-date distributions ship it for years
      now.
      
      Removing the libraries allows us to:
      
      * Remove the horrible hacks that were in place to deal with accidental use
        of both the new and old library in a single process.
      * Relief the translators of maintenance burden of similar yet different
        strings.
      * Get rid of known bad code without chances of ever getting fixed
        (libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
      * Generally lower the footprint of the releases and our workspace
      
      If there are some really really legacy users; they can just build
      libnm-glib and friends from the NetworkManager-1.16 distribution. The
      D-Bus API is stable and old libnm-glib will keep working forever.
      
      https://github.com/NetworkManager/NetworkManager/pull/308
      5801f89f
  27. 15 Apr, 2019 2 commits