summaryrefslogtreecommitdiff
path: root/docs
AgeCommit message (Collapse)AuthorFilesLines
2018-09-28build: meson: fix generation of api docsBeniamino Galvani1-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).
2018-09-19docs: include openvswitch(7) man page only when ovs is enabledBeniamino Galvani2-2/+6
2018-09-18initrd: add configuration generatorLubomir Rintel2-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.
2018-09-17docs: misc. typos pt2luz.paz2-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
2018-09-14docs/test: add check that gtk-doc contains patch to generate proper ↵Thomas Haller1-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)
2018-09-04libnm/crypto: add header "nm-crypto-impl.h" for crypto implementationThomas Haller2-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.
2018-09-04libnm/crypto: rename libnm's crypto filesThomas Haller2-2/+2
"crypto.h" did not follow our common NM style naming. Rename the files.
2018-08-27all: point git references to the GitLab instanceLubomir Rintel1-1/+1
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/2
2018-08-11all: add 'match' settingBeniamino Galvani1-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.
2018-08-10libnm, cli, ifcfg-rh: add NMSettingEthtool settingThomas Haller1-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.
2018-08-06libnm: introduce NMDeviceWireGuardJavier Arteaga1-0/+1
2018-08-06core: introduce NMDeviceWireGuardJavier Arteaga2-0/+2
For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-07-11libnm-core: add SR-IOV settingBeniamino Galvani1-0/+1
Add a setting containing SR-IOV parameters.
2018-06-28docs: provide soft descriptions for NM{Simple,Remote}ConnectionLubomir Rintel1-1/+1
...and order them on more logical places in the libnm manual.
2018-06-28docs: include missing documentation in libnm and D-Bus docsLubomir Rintel4-7/+58
Check that we don't repeat the omission in future.
2018-06-28docs: update copyright yearLubomir Rintel4-0/+4
2018-03-16docs: fix VPN chapter IDDan Williams1-1/+1
2018-02-15build: allow building with address sanitizer only for executablesBeniamino Galvani1-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.
2018-02-07all: replace non-leading tabs with spacesThomas Haller3-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.
2018-01-23version: drop NM_VERSION_MAX_ALLOWED defines for internal buildThomas Haller3-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.
2018-01-23version: combine NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLEThomas Haller3-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".
2018-01-18all: require glib 2.40Lubomir Rintel3-9/+0
RHEL 7.1 and Ubuntu 14.04 LTS both have this. https://bugzilla.gnome.org/show_bug.cgi?id=792323
2018-01-10build/meson: fix build without introspectionThomas Haller1-8/+10
nm_settings_docs is only defined with enable_introspection.
2018-01-10meson: Use string variables extensivelyIñigo Martínez4-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.
2018-01-10build: Add meson build files to distributable filesIñigo Martínez4-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
2018-01-08libnm: drop libnm-util/nm-setting-template.[hc]Thomas Haller2-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.
2018-01-02build: Workaround for gtkdoc dependenciesIñigo Martínez1-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
2018-01-02build: Remove default install directoriesIñigo Martínez4-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
2017-12-18build: Remove documentation generation workaroundsIñigo Martínez1-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
2017-12-13build: add initial support for meson build systemIñigo Martínez5-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
2017-10-30man: add OpenVSwitch overviewLubomir Rintel2-0/+2
2017-03-17docs/libnm: add some more documentationLubomir Rintel1-18/+124
2017-03-17docs/api: restructureLubomir Rintel1-29/+105
This splits the manual into parts and groups the D-Bus interfaces into chapters by the object class. It looks considerably better.
2017-03-17docs/api: move D-Bus reference after nm-settingsLubomir Rintel1-57/+57
2017-03-17docs/api: make the connection settings look betterLubomir Rintel2-22/+44
Turn the it into a chapter with refentries to better fit the structure of the table of contects. Also, include the properties in the index.
2017-03-17docs/api: add abstractLubomir Rintel1-0/+20
2017-03-17docs/api: add standard release informationLubomir Rintel1-1/+5
2017-03-17docs/api: reorder the manual pagesLubomir Rintel1-4/+4
I guess the daemon and its configuration first makes most sense.
2017-03-09include: use double-quotes to include our own headersThomas Haller1-26/+26
In practice, this should only matter when there are multiple header files with the same name. That is something we try to avoid already, by giving headers a distinct name. When building NetworkManager itself, we clearly want to use double-quotes for including our own headers. But we also want to do that in our public headers. For example: ./a.c #include <stdio.h> #include <nm-1.h> void main() { printf ("INCLUDED %s/nm-2.h\n", SYMB); } ./1/nm-1.h #include <nm-2.h> ./1/nm-2.h #define SYMB "1" ./2/nm-2.h #define SYMB "2" $ cc -I./2 -I./1 ./a.c $ ./a.out INCLUDED 2/nm-2.h Exceptions to this are - headers in "shared/nm-utils" that include <NetworkManager.h>. These headers are copied into projects and hence used like headers owned by those projects. - examples/C
2017-03-02docs: update yearsLubomir Rintel4-2/+18
2017-02-23docs: add missing links to dummy and macsec device/settingBeniamino Galvani3-0/+6
Fixes: b42f780e045c69e6b2c350dcd6de760c673a78e0 Fixes: d252a99fa25359e3795abcacfae08c76dc5386b8
2017-02-14build: combine handling of setting docs and man pagesThomas Haller1-1/+1
Building the man pages via xsltproc requires "docbook.xsl" which is part of docbook. Previously, we would build the man pages solely based on "--enable-introspection", which checks for the presence of xsltproc, but not docbook. This can lead to build failure when docbook is not available, but "--enable-introspection" is given. Instead of adding yet another configure option to fine-tune and say "--with-docbook --disable-gtk-doc", just simplify it. Now, documentation (both man pages and setting docs) will be generated with "--enable-gtk-doc" and "--enable-introspection". If the documentation is not about to be generated, pre-generated docs will be installed if they are available. That is commonly the case with a source tarball, but not with a git checkout. Finally, if documentation is nither generated nor pre-generated, no documentation will be installed *duh*. This removes the possibility to treat man pages separate from settings docs. Now you either generate both, install both pre-generated, or don't get any of them. https://bugzilla.gnome.org/show_bug.cgi?id=778551
2017-01-16core,libnm: introduce NMDeviceMacsecBeniamino Galvani2-0/+2
At the moment the device only exposes the current link status, but cannot create new links.
2016-12-15build: build documentation for o.fd.NM.DnsManagerLubomir Rintel2-0/+2
Fixes: 14105ece56b65fed64bade4013b105f7adaad27b
2016-12-12libnm: implement support for DNS manager propertiesBeniamino Galvani1-0/+1
2016-11-28build: fix gtk-doc/introspection handling for buildThomas Haller1-2/+0
- `make dist` requires --enable-gtk-doc --enable-introspection --with-libnm-glib - --enable-gtk-doc requires --enable-introspection - --with-nmcli requires either --enable-introspection or pregenerated settings-docs.c files from the dist tarball. It does not require --enable-gtk-doc. There is a bit of a problem in that --enable-introspection requires now xsltproc. However, gobject-introspection does itself not depend on xsltproc. So, more correct might be a special --enable-doc argument, that combines --enable-introspection --with-xsltproc. Anyway, that seems to make it more complicated then it already is so just implicitly (and surprisingly?) require xsltproc with --enable-introspection. https://bugzilla.gnome.org/show_bug.cgi?id=775003
2016-11-24build: rename intermediate doc xmlsThomas Haller1-1/+1
Allows to use pattern rules by making the related files having a common naming scheme. This commit only renames files.
2016-11-23all: rename the introspection data to use the interface paths in namesLubomir Rintel2-68/+68
This makes it easier to install the files with proper names. Also, it makes the makefile rules slightly simpler. Lastly, the documentation is now generated into docs/api, which makes it possible to get rid of the awkward relative file names in docbook.
2016-11-10libnm: use the o.fd.DBus.ObjectManager API for object managementLubomir Rintel1-1/+0
This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
2016-10-21build: merge "docs/Makefile.am" into toplevel MakefileThomas Haller1-7/+0
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-09 21:49:14 +0000