1. 12 Feb, 2019 3 commits
  2. 13 Nov, 2018 2 commits
    • Thomas Haller's avatar
      dhcp: don't pass duid to client ip6_start() and stop() · 7d55b134
      Thomas Haller authored
      We don't do that for ip4_start() either. The duid/client-id
      is stored inside the NMDhcpClient instance, and the function can
      access it from there.
      
      Maybe, it is often preferable to have stateless objects and not
      relying on ip4_start() to obtain the client ID from the client's
      state. However, the purpose of the NMDhcpClient object is to
      hold state about DHCP. To simplify the complexity of objects that
      inherrently have state, we should be careful about mutating the state.
      It adds little additional complexity of only reading the state when
      needed anyway. In fact, it adds complexity, because previously
      it wasn't enough to check all callers of nm_dhcp_client_get_client_id()
      to see where the client-id is used. Instead, one would also need to
      follow the @duid argument several layers of the call stack.
      7d55b134
    • Thomas Haller's avatar
      dhcp: don't re-read DHCP client ID from configuration file for dhclient · 5411fb0c
      Thomas Haller authored
      Why would we do this? The configuration file we are reading back was
      written by NetworkManager in the first place.
      
      Maybe when assuming a connection after restart, this information could
      be interesting. It however is not actually relevant.
      
      Note how nm_dhcp_client_get_client_id() has only very few callers.
      
        - nm_device_spawn_iface_helper() in 'nm-device.c'. In this case,
          we either should use the client-id which we used when starting
          DHCP, or none at all.
      
        - ip4_start() in 'nm-dhcp-dhclient.c', but this is before starting
          DHCP client and before it was re-read from configuration file.
      
        - in "src/dhcp/nm-dhcp-systemd.c", but this has no effect for
          the dhclient plugin.
      5411fb0c
  3. 12 Sep, 2018 2 commits
  4. 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
          587
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          21114
      
      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' \
            "${FILES[@]}"
      e1c7a2b5
  5. 30 Apr, 2018 1 commit
  6. 20 Mar, 2018 1 commit
  7. 15 Feb, 2018 2 commits
    • Thomas Haller's avatar
      dhcp: refactor type of NMDhcpClient duid to be GBytes · 578c4af9
      Thomas Haller authored
      GBytes is immutable. It's better suited to contain the duid parameter
      then a GByteArray.
      578c4af9
    • Thomas Haller's avatar
      dhcp: cache info-only parameter in NMDhcpClient · 8ff962d9
      Thomas Haller authored
      Optimally, NMDhcpClient would be stateless and all paramters would
      be passed on as argument. Clearly that is not feasable, because there
      are so many paramters, and in many cases they need to be cached for the
      lifetime of the client instance.
      
      Instead of passing info_only paramter to ip6_start() and cache it
      both in NMDhcpClient and NMDhcpSystemd, keep it in NMDhcpClient at
      one place.
      
      In the next commit, we will initialize info-only only once during the
      constructor, so it is immutable and somewhat stateless.
      8ff962d9
  8. 07 Feb, 2018 1 commit
  9. 30 Oct, 2017 1 commit