Properties that are backed by a GObject property are fundamentally
different.
I think it's clearer to rework the check, to first check whether
we have a param_spec, and then implement different checks.
_nm_utils_init() is a __attribute__((constructor)) function,
that is, it runs during dlopen().
On the other head, g_module_open() itself calls dlopen().
It is prone to deadlock. Don't do it.
The check is only an aggressive assertion to crash the application
if it wrongly loads libnm and libnm-util/libnm-glib at the same time.
If that happens, all is lost already. We can just as well call the
assertion later. It's not supposed to fail anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=796804
Utilize _nm_setting_to_dbus() to serialize the setting. The main reason
is that this way we can also print the more complicated values
g_strdup_value_contents() can't grok, e.g. the GArrays and GHashTables.
Some effort was spent on tidying up the results in a manner it was done
previously, instead of reducing this to a plain g_variant_print(). It
looks good that way:
Before:
vpn
service-type : "org.freedesktop.NetworkManager.VPN.Novpn" (s)
user-name : NULL (sd)
persistent : FALSE (sd)
data : ((GHashTable*) 0xc61060) (s)
secrets : ((GHashTable*) 0xdda640) (s)
timeout : 0 (sd)
After:
vpn
service-type : 'org.freedesktop.NetworkManager.VPN.Novpn'
data : {'gateway': 'novpn.example.com', 'username': 'hello'}
secrets : {'password': 'world'}
Note that no effort was spent on printing the defaults. There are
multiple ways that could be achieved, but I'm not sure it would be all
that necessary given this is really just a quick'n'dirty debugging facilty.
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[@]}"
constructor functions are ugly, because code is running before
main() starts. Instead, as the registration code for NMSetting types
is insid the GType constructor, we just need to ensure at the
right place, that the GType was created.
The right place here is _register_settings_ensure_inited(), because
that is called before we need the registration information.
_nm_register_setting() and _nm_register_setting_impl() are called from within
the GType constructor for the NMSetting subtype. As such, at that point it
runs inside a g_once_init_enter() block. However, each implementation
for initializing the GType has a separate g_once_init_enter() variable, hence,
if two threads create GType instances for different NMSetting subclasses, there
is a race.
libnm is not thread safe. However, it should be at least thread safe
with respect to constructing the GType instances.
For NMSetting subtypes, we need the static dictionaries "registered_settings" and
"registered_settings_by_type" to keep track of existing NMSetting types.
Initialize these dictionaries inside NMSetting's type initialization code.
This is guaranteed to run before any use of NMSetting type, and is also
guarded by a mutex.
Also, drop the __attribute__((constructor)) function to initialize the
hash tables. They are not needed, and it's ugly to run code before
main().
We also do this for libnm and libnm-core, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
Normalizing can be complicated, as settings depend on each other and possibly
conflict.
That is, because verify() must exactly anticipate whether normalization will
succeed and how the result will look like. That is because we only want to
modify the connection, if we are sure that the result will verify.
Hence, verify() and normalize() are strongly related. The implementation
should not be spread out between NMSettingOvsInterface:verify(),
NMSettingOvsPatch:verify() and _normalize_ovs_interface_type().
Also, add some unit-tests.
Previously, nm_setting_diff() would return !(*results), that means,
if the caller passed in a hash table (empty or not), the return value
would always be FALSE, indicating a difference.
That is not documented, and makes no sense.
The return value, should solely indicate whether some difference was
found. The only convenience is, if nm_setting_diff() created a hash
table internally and no difference was found, it would destroy
it again, without returning it to the caller.
NMSettingGeneric has no properties at all. Hence, nm_connection_diff() would report that
a connection A with a generic setting and a connection B without a generic setting are
equal.
They are not. For empty settings, let nm_setting_diff() return also empty difference
hash.
Functions call each other, like
nm_connection_get_id()
nm_connection_get_setting_connection()
nm_connection_get_setting()
Along the way, each function asserts that the input argument
is of type NMConnection via
g_return_val_if_fail (NM_IS_CONNECTION (connection), NULL);
Avoid such duplicate assertions when we already verifyied the
input argument.
For example, in case of nm_connection_get_id(), don't check just call
nm_connection_get_setting_connection() right away. It already
asserts.
The downside is, that the assertion no longer fails in the function
that immediately called it. But these are assertions after all.
Using plain numbers make it cumbersome to grep for
setting types by priority.
The only downside is, that with the enum values it
is no longer obvious which value has higher or lower
priority.
Also, introduce NM_SETTING_PRIORITY_INVALID. This is what
_nm_setting_type_get_base_type_priority() returns. For the moment
it still has the same numerical value 0 as before. Later, that
shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
When the two base settings are present, use one of higher priority.
This will pick the "bridge" setting when both "bridge" and "bluetooth" are
present for a Bluetooth NAP connection.
We'll need two "base" settings for Bluetooth NAP connections: bridge to set up
the actual link and bluetooth to identify the HCI to register the network
server with.
Let's use two priorities for base setting, with "1" marking one of higher
priority and "2" of lower priority when both are present.
In some situations, we want strict checking of errors, for example when
NetworkManager receives a new connection from a client, the connection
must make sense as a whole (and since NetworkManager service is backward
compatible to the clients and not the other way around, there is no
excuse for sending invalid data to the server).
In other situations, we want a best-effort behavior. Like when
NetworkManager sends a connection to its clients, those clients
want to extract as many properties as they understand, but in order
to be forward compatible against newer server versions, invalid
or unknown properties must be accepted.
Previously, a mixture of both was done. Some issues caused a failure
to create a new NMSetting, other invalid parts were just silently
ignored or triggered a g_warning() in glib.
Now allow for both. When doing strict-validation, be more strict and
reject all unknown properties and catch when the user sets an invalid
argument. On the other hand, allow for a best-effort mode that
effectively cannot fail and will return a new NMSetting instance.
For now, add NMSettingParseFlags so that the caller can choose the
old behavior, strict parsing, or best effort.
This patch doesn't have any externally visible change except that
no more g_warnings will be emitted.
- 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
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
for verifying the secrets, because it is not done in plain nm_setting_verify().
For simple verification of free-form string secrets,
_nm_setting_verify_secret_string() helper is used.
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.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Before, get_property_for_dbus() would @ignore_defaults.
That is for example wrong for properties of type G_TYPE_STRV.
In this case, if one operand has the property at its default
(NULL) and the other has it to an empty string list, both would
compare equal.
This has the effect that different settings might compare equal.
It yields completely unpredictable results on Ubuntu 12.04 (the global variable
successfully comparing to NULL despite demonstrably not NULL). Possibly a
toolchain bug.
The sort order of nm_setting_enumerate_values() affects the
order in which keyfile writer serializes the properties.
Have a defined, stable sort order by sorting the properties
by name (with prefering id,uuid,type for NMSettingConnection).
In _nm_setting_new_from_dbus(), verify that the properties have the
right types, and return an error if not. (In particular, don't crash
if someone tries to assign a GBytes-valued property a non-'ay' value.)
libnm-util's nm_setting_new_from_hash() needed to call
g_type_class_ref(setting_type) to ensure that the class had been
initialized by the time we fetched its properties. But in libnm-core's
version, we create the setting object before fetching the list of
properties, so we know the class will already have been initialized by
that point.
Add nm_setting_get_dbus_property_type(), and use this to get the
correct type for properties in nm-seting-docs.xml, in situations where
the D-Bus and GObject property types don't match.
In the case of enum/flags-valued properties, give both the enum name
and the underlying D-Bus type.
