summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* travis: enable matrix build for gcc/clang and autotools/mesonth/build-meson-on-travisThomas Haller2018-01-101-34/+43
|
* travis: add meson builds to travis-ciThomas Haller2018-01-101-4/+40
|
* build/meson: unconditionally use linker version scriptsThomas Haller2018-01-1020-90/+64
| | | | | | | We also unconditionally use them with autotools. Also, the detection for have_version_script does not seem correct to me. At least, it didn't work with clang.
* build/meson: fix build without have_version_scriptThomas Haller2018-01-101-5/+3
| | | | | We always need to declare the linker_script_* variables, because they are used (unconditionally) as a dependency, even without have_version_script.
* build/meson: disable unit tests that are known to failThomas Haller2018-01-101-2/+3
| | | | | | | | I think it's because meson doesn't run the tests in their own D-Bus session, hence the use the system service. automake solves this running all tests via ./tools/run-nm-test.sh, which knows how to prepare a suitable environment for the tests.
* build/meson: fix build without introspectionThomas Haller2018-01-101-8/+10
| | | | nm_settings_docs is only defined with enable_introspection.
* build/meson: fix gir dependency with building without fake-typelibsThomas Haller2018-01-101-6/+5
|
* build/meson: fix build with -D session_tracking=no -D systemdsystemunitdir=noThomas Haller2018-01-101-1/+2
| | | | | The variable enable_consolekit is used below, outside the if. We always must set it.
* build/meson: rename config_plugin_ibft option to just ibftThomas Haller2018-01-103-9/+9
|
* build/meson: meson improvementsThomas Haller2018-01-1051-360/+244
|\ | | | | | | | | https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00039.html https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00046.html
| * meson: Use string variables extensivelyIñigo Martínez2018-01-1014-43/+54
| | | | | | | | | | | | | | The strings holding the names used for libraries have also been moved to different variables. This way they would be less error as these variables can be reused easily and any typing error would be quickly detected.
| * meson: Improve dependency systemIñigo Martínez2018-01-1045-320/+193
|/ | | | | | | | | | | | | | | | | | | | Some targets are missing dependencies on some generated sources in the meson port. These makes the build to fail due to missing source files on a highly parallelized build. These dependencies have been resolved by taking advantage of meson's internal dependencies which can be used to pass source files, include directories, libraries and compiler flags. One of such internal dependencies called `core_dep` was already in use. However, in order to avoid any confusion with another new internal dependency called `nm_core_dep`, which is used to include directories and source files from the `libnm-core` directory, the `core_dep` dependency has been renamed to `nm_dep`. These changes have allowed minimizing the build details which are inherited by using those dependencies. The parallelized build has also been improved.
* all: merge branch 'th/pr/53' (part 1)Thomas Haller2018-01-102-31/+42
|\ | | | | | | | | | | Partly merge pull request #52. https://github.com/NetworkManager/NetworkManager/pull/52
| * device: split per-directory factory functionPavel Šimerda2018-01-101-31/+38
| | | | | | | | | | | | | | | | | | In some cases we might want to load device plugins from multiple directories. A special case that I have in mind is to load plugins from build directory subdirectories in order to run NetworkManager from the build directory. [thaller@redhat.com: modify original patch]
| * build: print missing configured directoriesPavel Šimerda2018-01-101-0/+4
|/ | | | | | | Many of the configured directories default to being defined using existing directory configuration. As a result you usually don't see the actual directories that will be used. With the added directories you can at least assemble the information and thus see which directories will be used.
* build: Add meson build files to distributable filesIñigo Martínez2018-01-106-28/+143
| | | | | | | | | | | | | Although it is possible to generate distributable files on meson since version 0.41 by using the `ninja dist` command, autotools does different things that end up creating a different distributable file. meson build files have been added to autotools build files as distributable files, so the whole meson port would also be distributed. https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00047.html
* dhcp: fix check for client-id in _set_client_id()Thomas Haller2018-01-091-0/+1
| | | | Fixes: 686afe531ab3774cd818feda8361de74101971f5
* all: merge branch 'th/policy-and-mdns'Thomas Haller2018-01-0926-622/+979
|\ | | | | | | https://github.com/NetworkManager/NetworkManager/pull/44
| * policy: merge IPv4 and IPv6 versions of device_ip_config_changed()Thomas Haller2018-01-091-45/+27
| |
| * core: implement setting MDNS setting for systemdThomas Haller2018-01-098-4/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The connection.mdns setting is a per-connection setting, so one might expect that one activated device can only have one MDNS setting at a time. However, with certain VPN plugins (those that don't have their own IP interface, like libreswan), the VPN configuration is merged into the configuration of the device. So, in this case, there might be multiple settings for one device that must be merged. We already have a mechanism for that. It's NMIP4Config. Let NMIP4Config track this piece of information. Although, stricitly speaking this is not tied to IPv4, the alternative would be to introduce a new object to track such data, which would be a tremendous effort and more complicated then this. Luckily, NMDnsManager and NMDnsPlugin are already equipped to handle multiple NMIPConfig instances per device (IPv4 vs. IPv6, and Device vs. VPN). Also make "connection.mdns" configurable via global defaults in NetworkManager.conf.
| * core: rework tracking config in dns-manager to use ifindexThomas Haller2018-01-099-581/+391
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't track the per-device configuration in NMDnsManager by the ifname, but by the ifindex. We should consistently treat the ifindex as the ID of a link, like kernel does. At the few places where we actually need the ifname, resolve it by looking into the platform cache. That is not necessarily the same as the ifname that is currently tracked by NMDevice, because netdev interfaces can be renamed, and NMDevice updates it's link properties delayed. However, the platform cache has the most recent notion of the correct interface name for an ifindex, so if we ever hit a race here, we do it now more correctly. This also temporarily drops support for mdns. Will be re-added next, but differently.
| * core/trivial: rename local variable in merge_one_ip_config()Thomas Haller2018-01-091-15/+15
| | | | | | | | | | Next commit will unify naming of variables, do a trivial rename first to make the diff smaller.
| * dns: rework pending request-queue in NMDnsSystemdResolvedThomas Haller2018-01-091-26/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had two separate queues, one for "SetLinkDNS" and one for "SetLinkDomains". Merge them into one, and track the operation as part of the new RequestItem structure. A visible change to before is that we now would make all requests per-interface first. Prevously, we would first make all SetLinkDNS requests (for all interfaces) and then all SetLinkDomains requests. It feels more correct to order the requests this way, not by type. The reason to merge is, that we will next get another operation and in the current scheme we would need 3 GQueue instances. While at it, refactor the code to use CList. We now anyway would need a new struct to track the operation, requiring to allocate and free it. Previously, we would only track the GVariant argument as data of the GQueue.
| * dns: refactor update() in NMDnsSystemdResolved to use a hash tableThomas Haller2018-01-091-47/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a GHashTable instead of a GArray to construct the list of @interfaces. Also, use NMCListElem instead of GList. With this, the runtime is O(n*log(n)) instead of O(n^2). I belive, we should take care that all our code has a reasonable runtime complexity, even in common use-cases the number of elements is small. This is not about performace, because likely we expect few entries anyway, and the direct GArray implementation is likely faster in those cases. It's about using the data structure that best suits the access pattern. The log(n) part comes from sorting the keys. I also believe we should always aim for a stable behavior. When sending the D-Bus request to resolved, the order of elements should be in ~some~ defined order.
| * shared: add nm_cmp_int2ptr_p_with_data() helperThomas Haller2018-01-091-0/+19
| | | | | | | | | | | | | | | | | | A cmp() implementation, for sorting an array with pointers, where each pointer is an inteter according to GPOINTER_TO_INT(). That cames for example handy, if you have a GHashTable with keys GINT_TO_POINTER(). Then you get the list of keys via g_hash_table_get_keys_as_array() and want to sort them.
| * shared: add NMCListElemThomas Haller2018-01-092-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, we want to use CList to track a simple data item. But contrary to GList/GSList, we need to define a structure to hold the data pointer and the CList member. Add a generic NMCListElem type that can be used for such simple uses. Before you ask: why not use GList/GSList? Because even simple operations like g_list_append() is O(n), which kinda defeats the purpose of having a doubly linked list. This code is added to a new header file nm-c-list.h, the reason is that there is no other good place: - "nm-utils/c-list.h" is a clone of upstream, it should not deviate. - "nm-utils/c-list-util.h" contains our utils functions for c-list.h but should be plain C, independent of glib. - "nm-utils/nm-shared-utils.h" contains our glib related utilities, but it should not drag in "c-list.h". So, "nm-c-list.h" is a utility libray that extends "c-list.h" and requires glib.
| * core: add nm_ip_config_get_ifindex() helperThomas Haller2018-01-091-0/+6
| |
| * dns: merge IPv4 and IPv6 versions of add_ip_config() (part 2)Thomas Haller2018-01-091-167/+103
| |
| * dns: merge IPv4 and IPv6 versions of add_ip_config() (part 1)Thomas Haller2018-01-091-124/+117
| |
| * dns/trivial: move codeThomas Haller2018-01-091-45/+45
| |
| * libnm: rename MDns flag UNKNOWN to DEFAULTThomas Haller2018-01-097-26/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "UNKNOWN" is not a good name. If you don't set the property in the connection explicitly, it should be "DEFAULT". Also, make "DEFAULT" -1. For one, that ensures that the enum's underlying integer type is signed. Otherwise, it's cumbersome to test "if (mdns >= DEFAULT)" because in case of unsigned types, the compiler will warn about the check always being true. Also, it allows for "NO" to be zero. These are no strong reasons, but I tend to think this is better. Also, don't make the property of NMSettingConnection a CONSTRUCT property. Initialize the default manually in the init function. Also, order the numeric values so that DEFAULT < NO < RESOLVE < YES with YES being largest because it enables *the most*.
| * libnm: verify value for connection.mdnsThomas Haller2018-01-091-1/+12
| | | | | | | | | | | | Also, keep the internal variable of type int. The only way to set the field is via the GObject property setter. At that point, don't yet cast the integer type to enum.
| * dns: add mechanism for propagating mDNS setting.Ismo Puustinen2018-01-096-32/+306
| | | | | | | | | | | | | | | | | | | | | | | | Update nm-policy.c and nm-dns-manager.c so that the connection-specific settings get propagated to DNS manger. Currently the only such value is the mDNS status. Add update_mdns() function to DNS plugin interface. If a DNS plugin supports mDNS, it can set an interface with a given index to support mDNS resolving or also register the current hostname. The mDNS support is currently added only to systemd-resolved DNS plugin.
| * mdns: add new connection property.Ismo Puustinen2018-01-098-3/+109
| | | | | | | | | | Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
| * build: first build dns-manager and dns-plugin before the pluginsThomas Haller2018-01-091-4/+4
| | | | | | | | | | | | When doing changes that affect multiple source files, it's more convenient to build the parts that have less dependencies first. So, to fix the build failures from the core outward.
| * core: reorder code in "src/dns/nm-dns-manager.c"Thomas Haller2018-01-091-40/+44
|/ | | | | | | Just moving code around, no other changes. Follow a certain prefered order of declarations in source files.
* ifcfg: test for sysconfig network path also on mesonIñigo Martínez2018-01-092-18/+4
| | | | | | | | | | | In a recent commit 1402fa7487b29fc1ea39a6bf7659fee7f30bb0e0 a new way for testing Red Hat compatible distributions had been added. However, this new approach does not use a set of files, it uses a directory, so this test can be done by using the `test` command and makes the `check_distro.py` script unnecessary. https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00031.html
* platform-linux: reload qdiscs and tfilters after removing themLubomir Rintel2018-01-081-1/+4
| | | | | | | | Kernel (as of 4.14) merely ACKs our RTM_DELQDISC and RTM_DELTFILTER, not bothering to signal the full RTM_DEL* message unless the removal is external to NetworkManager. https://bugzilla.redhat.com/show_bug.cgi?id=1527197
* libnm: fix building libnm without WITH_FAKE_TYPELIBS and without girThomas Haller2018-01-081-2/+2
| | | | Fixes: 4d1f090aedf05c0e2955d431638e311d1e18a52f
* platform/tests: relax checking for signals in test-address-linuxFrancesco Giudici2018-01-081-1/+1
| | | | | | # Start of ipv6 tests ../tools/run-nm-test.sh: line 193: 32194 Trace/breakpoint trap (core dumped) "${NMTST_DBUS_RUN_SESSION[@]}" "$TEST" "$@" # NetworkManager-FATAL-ERROR: NMPlatformSignalAssert: ../src/platform/tests/test-address.c:153, test_ip6_address_general(): failure to accept signal [0,1] times: 'ip6-address-changed-changed' ifindex 11 (2 times received)
* libnm: drop libnm-util/nm-setting-template.[hc]Thomas Haller2018-01-084-175/+0
| | | | | | | | | | | | | | | These files are a template how to add a new nm-setting-* implementation. We are not going to add new files to the deprecated libnm-util library, hence a template for libnm-util is pointless. libnm-core doesn't have a corresponding template file. Personally, I don't think such a template are a great idea either, because - People are not aware that it exists. Hence, it's unused, badly maintained and quite possibly does not follow current best practice. - Just copy an actual settings implementation and start from there. That seems better to me than having a template.
* build/meson: don't include libnm when building src/systemdIñigo Martínez2018-01-081-1/+0
| | | | | | | | | "src/" must not include "libnm/". This also causes a build failure, because it would include "libnm/nm-types.h", instead of "src/nm-types.h". https://mail.gnome.org/archives/networkmanager-list/2018-January/msg00032.html [thaller@redhat.com: original patch modified and commit message changed]
* all: merge branch 'th/nm-compilation-type'Thomas Haller2018-01-0887-581/+659
|\ | | | | | | https://github.com/NetworkManager/NetworkManager/pull/51
| * clients: drop redundant #include "NetworkManager.h"Thomas Haller2018-01-0824-43/+0
| | | | | | | | This header is already included by "nm-default.h".
| * tests: use NMTST_EXPECT*() macrosThomas Haller2018-01-0812-304/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tests are commonly created via copy&paste. Hence, it's better to express a certain concept explicitly via a function or macro. This way, the implementation of the concept can be adjusted at one place, without requiring to change all the callers. Also, the macro is shorter, and brevity is better for tests so it's easier to understand what the test does. Without being bothered by noise from the redundant information. Also, the macro knows better which message to expect. For example, messages inside "src" are prepended by nm-logging.c with a level and a timestamp. The expect macro is aware of that and tests for it #define NMTST_EXPECT_NM_ERROR(msg) NMTST_EXPECT_NM (G_LOG_LEVEL_MESSAGE, "*<error> [*] "msg) This again allows the caller to ignore this prefix, but still assert more strictly.
| * tests: add NMTST_EXPECT*() macrosThomas Haller2018-01-082-0/+22
| | | | | | | | Will be used next...
| * build: refine the NETWORKMANAGER_COMPILATION defineThomas Haller2018-01-0849-231/+380
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that: - we compile some source files multiple times. Most notably those under "shared/". - we include a default header "shared/nm-default.h" in every source file. This header is supposed to setup a common environment by defining and including parts that are commonly used. As we always include the same header, the header must behave differently depending one whether the compilation is for libnm-core, NetworkManager or libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h> depending on whether we compile a library or an application. For that, the source files need the NETWORKMANAGER_COMPILATION #define to behave accordingly. Extend the define to be composed of flags. These flags are all named NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the build are available. E.g. when building libnm-core.la itself, then WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE is not available but the internal parts are still accessible. When building nmcli, only WITH_LIBNM_CORE (the public part) is available. This granularily controls the build.
| * config: adjust logging message for duplicate config prefixThomas Haller2018-01-082-13/+13
|/ | | | | | | | | | | The logging macros already prepend a "config: " prefix. Don't repeat that in the message, otherwise we get config: config: signal SIGHUP (no changes from disk) Now: config: signal: SIGHUP (no changes from disk)
* core: load jansson on demandLubomir Rintel2018-01-088-35/+248
| | | | Avoid using it if the symbols clash is detected.
* ip-tunnel: add support for tunnel flagsBeniamino Galvani2018-01-0516-22/+274
| | | | | | | | | | | | | | | | | | Implement support for IP tunnel flags. Currently only some IPv6 tunnel flags are supported. Example: # nmcli connection add type ip-tunnel mode ip6ip6 \ ip-tunnel.flags ip6-ign-encap-limit,ip6-use-orig-tclass \ ifname abc ip-tunnel.parent ens8 ipv4.method disabled \ ipv6.method manual ipv6.address ::8888 remote ::42 # ip -d l 61: abc@ens8: <NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue ... link/tunnel6 :: brd ::42 promiscuity 0 ip6tnl ip6ip6 remote ::42 local :: dev ens8 encaplimit none hoplimit 0 tclass inherit ... https://bugzilla.gnome.org/show_bug.cgi?id=791846
View Lorry Controller Status