1. 18 Apr, 2019 2 commits
    • 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
    • Thomas Haller's avatar
      shared: split C-only helper "shared/nm-std-aux" utils out of "shared/nm-utils" · b434b9ec
      Thomas Haller authored
      "shared/nm-utils" contains general purpose utility functions that only
      depend on glib (and extend glib with some helper functions).
      
      We will also add code that does not use glib, hence it would be good
      if the part of "shared/nm-utils" that does not depend on glib, could be
      used by these future projects.
      
      Also, we use the term "utils" everywhere. While that covers the purpose
      and content well, having everything called "nm-something-utils" is not
      great. Instead, call this "nm-std-aux", inspired by "c-util/c-stdaux".
      b434b9ec
  2. 27 Mar, 2019 8 commits
  3. 12 Feb, 2019 2 commits
  4. 03 Dec, 2018 1 commit
    • Thomas Haller's avatar
      core: avoid calling platform code with invalid ifindex · d45eed44
      Thomas Haller authored
      Since commit 945c904f "platform: assert against valid ifindex and
      remove duplicate assertions", it is no longer allowed to call certain
      platform functions with invalid ifindex.
      
      These trigger now an assertion. Note that the assertion is merely a
      g_return_val_if_fail(), hence in non-debug mode, this does not lead to
      a crash.
      
      Fixes: 945c904f
      d45eed44
  5. 22 Nov, 2018 1 commit
  6. 27 Mar, 2018 1 commit
  7. 18 Oct, 2017 3 commits
    • Thomas Haller's avatar
      all: add helper functions for nm_hash_update*() · 2f56de74
      Thomas Haller authored
      By using a macro, we don't cast all the types to guint. Instead,
      we use their native types directly. Hence, we don't need
      nm_hash_update_uint64() nor nm_hash_update_ptr().
      Also, for types smaller then guint like char, we save hashing
      the all zero bytes.
      2f56de74
    • Thomas Haller's avatar
      all: use siphash24 for hashing · ee76b097
      Thomas Haller authored
      siphash24() is wildly used by projects nowadays.
      
      It's certainly slower then our djb hashing that we used before.
      But quite likely it's fast enough for us, given how wildly it is
      used. I think it would be hard to profile NetworkManager to show
      that the performance of hash tables is the issue, be it with
      djb or siphash24.
      
      Certainly with siphash24() it's much harder to exploit the hashing
      algorithm to cause worst case hash operations (provided that the
      seed is kept private). Does this better resistance against a denial
      of service matter for us? Probably not, but let's better be safe then
      sorry.
      
      Note that systemd's implementation uses a different seed for each hash
      table (at least, after the hash table grows to a certain size).
      We don't do that and use only one global seed.
      ee76b097
    • Thomas Haller's avatar
      all: refactor hashing by introducing NMHashState · 0e9e35e3
      Thomas Haller authored
      The privious NM_HASH_* macros directly operated on a guint value
      and were thus close to the actual implementation.
      
      Replace them by adding a NMHashState struct and accessors to
      update the hash state. This hides the implementation better
      and would allow us to carry more state. For example, we could
      switch to siphash24() transparently.
      
      For now, we still do a form basically djb2 hashing, albeit with
      differing start seed.
      
      Also add nm_hash_str() and nm_str_hash():
      
      - nm_hash_str() is our own string hashing implementation
      
      - nm_str_hash() is our own string implementation, but with a
        GHashFunc signature, suitable to pass it to g_hash_table_new().
        Also, it has this name in order to remind you of g_str_hash(),
        which it is replacing.
      0e9e35e3
  8. 13 Oct, 2017 1 commit
    • Thomas Haller's avatar
      core: introduce NM_HASH_INIT() to initialize hash seed · 4a279843
      Thomas Haller authored
      Introduce a NM_HASH_INIT() function. It makes the places
      where we initialize a hash with a certain seed visually clear.
      
      Also, move them from "shared/nm-utils/nm-shared-utils.h" to
      "shared/nm-utils/nm-macros-internal.h". We might want to
      have NM_HASH_INIT() non-inline (hence, define it in the
      source file).
      4a279843
  9. 05 Jul, 2017 1 commit
  10. 05 May, 2017 2 commits
  11. 24 Mar, 2017 2 commits
  12. 21 Nov, 2016 1 commit
    • Thomas Haller's avatar
      build: don't add subdirectories to include search path but require qualified include · 44ecb415
      Thomas Haller authored
      Keep the include paths clean and separate. We use directories to group source
      files together. That makes sense (I guess), but then we should use this
      grouping also when including files. Thus require to #include files with their
      path relative to "src/".
      
      Also, we build various artifacts from the "src/" tree. Instead of having
      individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
      unified. Previously, the CFLAGS for each artifact differ and are inconsistent
      in which paths they add to the search path. Fix the inconsistency by just
      don't add the paths at all.
      44ecb415
  13. 03 Oct, 2016 1 commit
  14. 27 Sep, 2016 1 commit
    • Thomas Haller's avatar
      build: don't add systemd path the include search path · e3a072f3
      Thomas Haller authored
      Our internal copy of systemd should not be in the search path.
      Instead, let users only
        #include "systemd/nm-sd.h"
      which then includes everything from systemd that we need.
      
      We want to avoid to accidentally include anything from our
      systemd-copy. Any user of that should only include "nm-sd.h",
      which then includes everything that is needed further.
      
      For example, "src/devices/wwan/nm-modem-manager.c" has
        #include <systemd/nm-daemon.h>
      which in turn includes
        #include "_sd-common.h"
      This works all correctly before, because #include "" will first
      look in the directory where sd-daemon.h is. However, our mixing of
      external systemd library and internal copy is rather dangerous.
      Try to avoid it further by keeping the include paths clean.
      e3a072f3
  15. 12 May, 2016 1 commit
  16. 17 Mar, 2016 12 commits