summaryrefslogtreecommitdiff
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* docs: include the license boilerplate instead of full GPL textLubomir Rintel2019-09-104-5/+71
| | | | | | | | What's actually needed here is an explaination of how the license applies along with the explanation where to find the full text. Also, the libnm documentation was lacking the licensing information altogether. Fix fixes it too.
* build: use regexp in gtkdoc --ignore-decorators optionBeniamino Galvani2019-09-062-7/+2
| | | | | | | gtkdoc-scan supports regular expressions in the --ignore-decorators command-line option. Since it is easier to use a regexp than grepping macros from a source file, revert the ugly solution from commit 2d941dc95a1d ('build: fix errors when building with gtk-doc 1.32').
* build: fix errors when building with gtk-doc 1.32Beniamino Galvani2019-09-052-1/+7
| | | | | | | | | | | | | | | | | | gtkdoc-scan 1.32 performs stricter checks on structures definitions and so it complains on: /build/networkmanager/src/NetworkManager/libnm/./nm-vpn-plugin-old.h:0: warning: partial declaration (struct) : typedef struct { NM_DEPRECATED_IN_1_2 GObject parent; } NMVpnPluginOld NM_DEPRECATED_IN_1_2; because of the unrecognized token 'NM_DEPRECATED_IN_1_2'. Pass all allowed macros to gtkdoc-scan through the --ignore-decorators argument. https://gitlab.gnome.org/GNOME/gtk-doc/issues/98 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/238
* libnm-core: add ovs-dpdk settingLubomir Rintel2019-06-141-0/+1
|
* build/meson: fix location of introspection filesThomas Haller2019-04-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | With glib < 2.51.3, gdbus-codegen does not understand "--output-directory" [1]. Hence, the generated files are like "build/dbus-org.freedesktop.NetworkManager.Device.WifiP2P.xml" instead of "build/introspection/dbus-org.freedesktop.NetworkManager.Device.WifiP2P.xml" But gnome.gdbus_codegen() returns a path as if it would be inside "build/introspection". Hack around that, by patching the correct path otherwise. This is still ugly, because repeated "ninja -C build" calls will always try to rebuild this target (because the wrong file name is considered). See also [2]. [1] https://gitlab.gnome.org/GNOME/glib/commit/ee09bb704fe9ccb24d92dd86696a0e6bb8f0dc1a [2] https://github.com/mesonbuild/meson/blob/2e93ed58c30d63da8527ff16375ff9e0642e7533/mesonbuild/modules/gnome.py#L1170
* all: goodbye libnm-glibLubomir Rintel2019-04-1612-1392/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "all: goodbye libnm-glib"Lubomir Rintel2019-04-0312-0/+1392
| | | | | | We need this for a little little longer :( This reverts commit 1de8383ad9fdfc8f552117e5d109bdfa7005634b.
* all: goodbye libnm-glibLubomir Rintel2019-03-1912-1392/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* libnm,cli: add NMSettingWireGuardThomas Haller2019-02-221-0/+1
| | | | | | | | | | | | | | For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
* wifi-p2p: rename Wi-Fi P2PThomas Haller2019-02-012-8/+8
| | | | | After renaming the files, also rename all the content to follow the "Wi-Fi P2P" naming scheme.
* wifi-p2p: rename files for consistent Wi-Fi P2P namingThomas Haller2019-02-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | We named the types inconsistently: - "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h") - "p2p" ("libnm/nm-p2p-peer.h") - "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h") It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi" specific name. It's not just peer-to-peer, it's Wi-Fi P2P. Yes, there is an inconsistency now, because there is already "libnm/nm-access-point.h". It seems to me (from looking at the internet), that the name "Wi-Fi P2P" is more common than "P2P Wi-Fi" -- although both are used. There is also the name "Wi-Fi Direct". But it's not clear which name should be preferred here, so stick to "Wi-Fi P2P". In this first commit only rename the files. The following commit will rename the content.
* libnm: Add NMDeviceP2PWifiBenjamin Berg2019-01-271-0/+1
|
* libnm: Add class to handle P2P peersBenjamin Berg2019-01-271-0/+1
| | | | | This adds the introspection data and P2P peer handling to libnm. To be usable the P2P device handling is also needed.
* core/devices: Add P2P Wifi device and peer trackingBenjamin Berg2019-01-272-25/+33
| | | | This only adds the new device type and simple peer list handling.
* core: Add basic P2P Wi-Fi SettingsBenjamin Berg2019-01-271-0/+1
| | | | | The support is rather basic and only allows connecting to a specific peer. However, this is actually already enough for many usecases.
* build: meson: Add trailing commasIñigo Martínez2018-12-205-17/+17
| | | | | | | Add missing trailing commas that avoids getting noise when another file/parameter is added and eases reviewing changes[0]. [0] https://gitlab.gnome.org/GNOME/dconf/merge_requests/11#note_291585
* build: fix check-docs.sh for out-of-tree buildsThomas Haller2018-10-253-17/+1
| | | | Fixes: 7a59cd274485e4c0345c563d48e516967630d7f0
* build: meson: fix generation of api docsBeniamino Galvani2018-09-281-0/+17
| | | | | | | | | | We need to copy all introspection files to the same directory when building the documentation. Note that we only require Meson 0.44, but for the documentation at least 0.46 is needed because of a new functionality of gnome.gdbus_codegen(). In this way we can still build on Travis CI (without documentation).
* docs: include openvswitch(7) man page only when ovs is enabledBeniamino Galvani2018-09-192-2/+6
|
* initrd: add configuration generatorLubomir Rintel2018-09-182-0/+2
| | | | | | nm-initrd-generator scans the command line for options relevant to network configuration and creates configuration files for an early instance of NetworkManager run from the initial ramdisk during early boot.
* docs: misc. typos pt2luz.paz2018-09-172-3/+3
| | | | | | | | | | | | | | | | | | | | | Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
* docs/test: add check that gtk-doc contains patch to generate proper ↵Thomas Haller2018-09-141-0/+12
| | | | | | | | | | | | | documentation In libnm, we prefer opaque typedefs. gtk-doc needs to be patched to properly generate documentation. Add a check for that. Add a test. By default, this does not fail but just prints a warning. The test can be made failing by setting NMTST_CHECK_GTK_DOC=1. See-also: https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/2 (cherry picked from commit 02464c052e2f8a1e88b012e0a29f5f66fce310ad)
* libnm/crypto: add header "nm-crypto-impl.h" for crypto implementationThomas Haller2018-09-042-0/+2
| | | | | | There are two aspects: the public crypto API that is provided by "nm-crypto.h" header, and the internal header which crypto backends need to implement. Split them.
* libnm/crypto: rename libnm's crypto filesThomas Haller2018-09-042-2/+2
| | | | | "crypto.h" did not follow our common NM style naming. Rename the files.
* all: point git references to the GitLab instanceLubomir Rintel2018-08-271-1/+1
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/2
* all: add 'match' settingBeniamino Galvani2018-08-111-0/+1
| | | | | | | Add a new 'match' setting containing properties to match a connection to devices. At the moment only the interface-name property is present and, contrary to connection.interface-name, it allows the use of wildcards.
* libnm, cli, ifcfg-rh: add NMSettingEthtool settingThomas Haller2018-08-101-0/+1
| | | | | | | | | | | | | | | | | | | Note that in NetworkManager API (D-Bus, libnm, and nmcli), the features are called "feature-xyz". The "feature-" prefix is used, because NMSettingEthtool possibly will gain support for options that are not only -K|--offload|--features, for example -C|--coalesce. The "xzy" suffix is either how ethtool utility calls the feature ("tso", "rx"). Or, if ethtool utility specifies no alias for that feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation"). If possible, we prefer ethtool utility's naming. Also note, how the features "feature-sg", "feature-tso", and "feature-tx" actually refer to multiple underlying kernel features at once. This too follows what ethtool utility does. The functionality is not yet implemented server-side.
* libnm: introduce NMDeviceWireGuardJavier Arteaga2018-08-061-0/+1
|
* core: introduce NMDeviceWireGuardJavier Arteaga2018-08-062-0/+2
| | | | | For now, the device only exposes partial link status (not including peers). It cannot create new links.
* libnm-core: add SR-IOV settingBeniamino Galvani2018-07-111-0/+1
| | | | Add a setting containing SR-IOV parameters.
* docs: provide soft descriptions for NM{Simple,Remote}ConnectionLubomir Rintel2018-06-281-1/+1
| | | | ...and order them on more logical places in the libnm manual.
* docs: include missing documentation in libnm and D-Bus docsLubomir Rintel2018-06-284-7/+58
| | | | Check that we don't repeat the omission in future.
* docs: update copyright yearLubomir Rintel2018-06-284-0/+4
|
* docs: fix VPN chapter IDDan Williams2018-03-161-1/+1
|
* build: allow building with address sanitizer only for executablesBeniamino Galvani2018-02-151-2/+4
| | | | | | | | | | | | Shared libraries built with sanitizers are a bit inconvenient to use because they require that any application linking to them is run with libasan preloaded using LD_PRELOAD. This limitation makes the sanitizer support less useful because applications will refuse to start unless there is a special environment variable set. Let's turn the --enable-address-sanitizer configure flag into --with-address-sanitizer=yes|no|exec so that is possible to enable asan only for executables.
* all: replace non-leading tabs with spacesThomas Haller2018-02-073-18/+18
| | | | | | We commonly only allow tabs at the beginning of a line, not afterwards. The reason for this style is so that the code looks formated right with tabstop=4 and tabstop=8.
* version: drop NM_VERSION_MAX_ALLOWED defines for internal buildThomas Haller2018-01-233-3/+0
| | | | | | It already defaults to the right value. We only need to define NM_VERSION_MIN_REQUIRED, so that parts of our internal build can make use of deprecated API.
* version: combine NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLEThomas Haller2018-01-233-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't need to have two version defines "CUR" and "NEXT". The main purpose of these macros (if not their only), is to make NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros work. 1) At the precise commit of a release, "CUR" and "NEXT" must be identical, because whenever the user configures NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED, then they both compare against the current version, at which point "CUR" == "NEXT". 2) Every other commit aside the release, is a development version that leads up the the next coming release. But as far as versioning is concerned, such a development version should be treated like that future release. It's unstable API and it may or may not be close to later API of the release. But we shall treat it as that version. Hence, also in this case, we want to set both "NM_VERSION_CUR_STABLE" and again NEXT to the future version. This makes NM_VERSION_NEXT_STABLE redundant. Previously, the separation between current and next version would for example allow that NM_VERSION_CUR_STABLE is the previously release stable API, and NM_VERSION_NEXT_STABLE is the version of the next upcoming stable API. So, we could allow "examples" to make use of development API, but other(?) internal code still restrict to unstable API. But it's unclear which other code would want to avoid current development. Also, the points 1) and 2) were badly understood. Note that for our previousy releases, we usually didn't bump the macros at the stable release (and if we did, we didn't set them to be the same). While using two macros might be more powerful, it is hard to grok and easy to forget to bump the macros a the right time. One macro shall suffice. All this also means, that *immediately* after making a new release, we shall bump the version number in `configure.ac` and "NM_VERSION_CUR_STABLE".
* all: require glib 2.40lr/glib-2-40Lubomir Rintel2018-01-183-9/+0
| | | | | | RHEL 7.1 and Ubuntu 14.04 LTS both have this. https://bugzilla.gnome.org/show_bug.cgi?id=792323
* build/meson: fix build without introspectionThomas Haller2018-01-101-8/+10
| | | | nm_settings_docs is only defined with enable_introspection.
* meson: Use string variables extensivelyIñigo Martínez2018-01-104-4/+4
| | | | | | | 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.
* build: Add meson build files to distributable filesIñigo Martínez2018-01-104-4/+4
| | | | | | | | | | | | | 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
* libnm: drop libnm-util/nm-setting-template.[hc]Thomas Haller2018-01-082-2/+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: Workaround for gtkdoc dependenciesIñigo Martínez2018-01-021-1/+3
| | | | | | | | | | | | | | | | | gtkdoc uses some custom generated targets as content files. However, there are still two problem. The first is that gtkdoc does not support targets which are not strings. This is being fixed in the following issue: https://github.com/mesonbuild/meson/pull/2806 The second issue is that the gtkdoc function produces a target which is triggered at install time. This makes the dependencies generation to not be triggered. This patch uses a workaround for that second issue. https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00079.html
* build: Remove default install directoriesIñigo Martínez2018-01-024-19/+7
| | | | | | | | | | The install directories of those targets that match the default install directories have been removed because they are redundant. This also allows a simple meson build files and it is unnecessary to create some paths. https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00078.html
* build: Remove documentation generation workaroundsIñigo Martínez2017-12-181-3/+1
| | | | | | | | | Documentation was not working in meson due to problems with files generated in `libnm`. To avoid these problems, workarounds were used. This problems have been recently fixed so these workarounds are not necessary anymore. https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00061.html
* build: add initial support for meson build systemIñigo Martínez2017-12-135-0/+177
| | | | | | | | | | meson is a build system focused on speed an ease of use, which helps speeding up the software development. This patch adds meson support along autotools. [thaller@redhat.com: rebased patch and adjusted for iwd support] https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00022.html
* man: add OpenVSwitch overviewlr/ovsLubomir Rintel2017-10-302-0/+2
|
* docs/libnm: add some more documentationlr/api-docsLubomir Rintel2017-03-171-18/+124
|
* docs/api: restructureLubomir Rintel2017-03-171-29/+105
| | | | | This splits the manual into parts and groups the D-Bus interfaces into chapters by the object class. It looks considerably better.
View Lorry Controller Status