- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Previously, NMSettingInfiniband:verify() silently modifies the
setting for invalid MTU. verify() should not do that.
For libnm-core we can change behavior and implement normalization
of MTU. This changes behavior for NMSettingInfiniband:verify() so
that MTU gets no longer fixed by verify() alone. Instead verify()
fails with a verification error.
Due the possibility to normalize the MTU, NM still can receive
invalid settings and fix it.
For libnm-core we don't change behavior, merely add a code comment.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some type-specific NMSetting implementations (bond, bridge, team, vlan)
have their own 'interface-name' property. This property will be
deprecated in favour of 'interface-name' in NMSettingConnection.
Change verify() and normalize() to check that the redundant
values match and repair/normalize the properties.
Force the virtual interface name of the type-specific setting to be
equal to NMSettingConnection:interface_name. This way, the depreacted
field stays valid and backward compatible.
NMSettingInfiniband is special, because it does not have a backing
property for the interface name, although it implements
get_virtual_iface_name(). To account for this, some special handling
is needed in order not to change the behaviour of get_virtual_iface_name().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Remove all the GParamSpec docs, since everything now uses the gtk-doc
docs instead, so there's no point in having two copies of each (which
are often out of sync anyway).
Since we're touching so many lines anyway, also fix up the indentation
of the remaining property-installing lines, and add
G_PARAM_STATIC_STRINGS to each paramspec (so the nick strings don't
get strduped). Also, be consistent about starting a new line between
"g_object_class_install_property" and its opening parenthesis.
Fix up various issues with the docs for the NMSetting properties, and
pull in text from the GParamSpec docs where the GParamSpec docs were
better (or contained information that is necessary in the context of
nm-settings.5).
Also, consistently wrap all of the doc comments to the same width (80
columns).
- refactor register_settings to allow lookup by GType and
add the settings name to SettingInfo.
- setting NM_SETTING_NAME is deprecated and should not be set anymore.
Indeed it has always be a bug, to reset the name to a different value.
The only valid place to set the name was in the _init() function of
the derived class itself.
This is now no longer needed/possible. Instead the name get's
detected based on the registered setting types. This makes use of
the registered metadata that is available anyway since every
usable setting has to register itself.
Signed-off-by: Thomas Haller <thaller@redhat.com>
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
For settings corresponding to devices that have a :carrier property
(ie bond, bridge, infiniband, vlan, and wired), add a :carrier-detect
property specifying how that affects the connection:
yes: The connection can only be activated when the device
has carrier, and will be deactivated if the device loses
carrier (for more than 4 seconds).
no: The connection ignores carrier on the device; it can be
activated when there is no carrier, and stays activated
when carrier is lost.
on-activate: The connection can only be activated when the
device has carrier, but it will not be deactivated if the
device loses carrier.
https://bugzilla.gnome.org/show_bug.cgi?id=688284
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
It is currently not possible to create a connection where the
connection-type-specific NMSetting has all default values. This hasn't
been a problem in the past because each type had at least one property
that either had no default value or had a default value that didn't
pass verify(). But NMSettingInfiniband didn't have that property, so
it's impossible to create an InfiniBand connection unless you change
the value of at least InfiniBand-specific setting.
Work around this for now by making the default value of
NMSettingInfiniband:transport-mode be NULL, so it needs to be
overridden.
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
