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[@]}"
- 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
Point in case:
# ip link add link dummy0 name dummy0.vlan type vlan id 4095
RTNETLINK answers: Numerical result out of range
This potentially causes existing (invalid) connections to disappear
as they now fail verification.
Instead of adjusting the range of the GObject property
NM_SETTING_VLAN_ID, reject it during vlan. This is a bit more
forgiving to an older client that isn't aware of this new restriction,
so he can first set the value without raising a critical warning.
We changed the default value of MSettingVlan:flags from 0 to
1 (NM_VLAN_FLAG_REORDER_HEADERS). That means, that old libnm
clients will not serialize 0 (their default).
This change broke the D-Bus API. The D-Bus API allows to omit a value
when meaning the default value. That means, we cannot change the
default value (in the D-Bus API!) without breaking previous assumptions.
A newer libnm version should treat a missing flags argument as the
old default value and thus preserve the original default value (in the
D-Bus API).
This has the downside that for the future we will continue to treat a missing
value as the old default value (0), and in order to get the new default
value (1), the client must explicitly set the flags.
We also must restore the original default value in libnm-glib.
libnm-glib does not support _nm_setting_class_override_property()
and thus it must keep thinking that the default value for the GObject
property continues to be 0. Otherwise, it would not serialize a 1, which
a new libnm would now interpret as 0.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
Fixes: 687b651598
The kernel defaults REORDER_HDR to 1 when creating a new VLAN, but
NetworkManager's VLAN flags property defaulted to 0. Thus REORDER_HDR was not
set for NM-created VLANs with default values.
We want to match the kernel default, so we change the default value for the
vlan.flags property. However, we do not want to change the flags for existing
connections if the property is missing in connection files. Thus we have to
update plugins for that. We also make sure that vlan.flags is always written
by 'keyfile' when the value is default. That way new connections have flags
property explicitly written and it will be loaded as expected.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
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.
Error: RESOURCE_LEAK (CWE-772): [#def10]
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: alloc_fn: Storage is returned from allocation function "priority_map_new_from_str".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: alloc_fn: Storage is returned from allocation function "g_malloc0".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: var_assign: Assigning: "p" = "g_malloc0(8UL)".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:164:2: return_alloc: Returning allocated memory "p".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: var_assign: Assigning: "item" = storage returned from "priority_map_new_from_str(map, str)".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:226: leaked_storage: Variable "item" going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772): [#def11]
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: alloc_fn: Storage is returned from allocation function "crypto_make_des_aes_key".
NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: alloc_fn: Storage is returned from allocation function "g_malloc0".
NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: var_assign: Assigning: "key" = "g_malloc0(digest_len + 1U)".
NetworkManager-0.9.11.0/libnm-core/crypto.c:407:2: noescape: Resource "key" is not freed or pointed-to in function "crypto_md5_hash".
NetworkManager-0.9.11.0/libnm-core/crypto.c:769:24: noescape: "crypto_md5_hash(char const *, gssize, char const *, gssize, char *, gsize)" does not free or save its pointer parameter "buffer".
NetworkManager-0.9.11.0/libnm-core/crypto.c:415:2: return_alloc: Returning allocated memory "key".
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: var_assign: Assigning: "key" = storage returned from "crypto_make_des_aes_key("DES-EDE3-CBC", &salt[0], salt_len, in_password, &key_len, NULL)".
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2057: leaked_storage: Variable "key" going out of scope leaks the storage it points to.
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.)
- Remove list of authors from files that had them; these serve no
purpose except to quickly get out of date (and were only used in
libnm-util and not libnm-glib anyway).
- Just say "Copyright", not "(C) Copyright" or "Copyright (C)"
- Put copyright statement after the license, not before
- Remove "NetworkManager - Network link manager" from the few files
that contained it, and "libnm_glib -- Access network status &
information from glib applications" from the many files that
contained it.
- Remove vim modeline from nm-device-olpc-mesh.[ch], add emacs modeline
to files that were missing it.
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).
Fix misused gtk-doc annotations and incorrectly-identified properties.
In particular, the upcoming introspection-based generate-settings-spec
expands macro and enum values, so if you use '%' where you should have
used '#', it will fail to find an expansion, and error out.
- 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.
The public property is called NM_SETTING_VLAN_INTERFACE_NAME,
so also the internal field and the PROP_* enum should carry
the same name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
We want to free the element data, then remove the element from the
list. Instead the code freed the element data, then treated the
element data pointer as a GSList link, which is completely wrong.
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)
Do slightly more validation if NMSettingVlan properties, and make sure
that at least one method of specifying a parent is used.
Remove the check that id is in range, since gobject will not allow you
to set the property to a value outside its declared range anyway.
Add documentation so the API spec generator can do something
for the VLAN setting. Also enforce validation of the ingress
and egress priority maps; 802.1D priorities are limited to
values from 0 - 7 and Linux SKB values are 32 bits.
Also, the 'slave' property is a duplicate of the 'master'
property added to NMSettingConnection in the bonding work
so we can get rid of it and use 'master' instead.
