Merge the function pointer get_func() into to_dbus_fcn().
Previously, get_func() as handled separately from to_dbus_fnc()
(formerly synth_func()). The notion was that synth-func would syntetize
properties that are D-Bus only. But that distinction does not seem
very helpful to me.
Instaed, we want to convert a property to D-Bus. Period. The
implementation should be handled uniformly. Hence, now that is
all done by property_to_dbus().
Note that property_to_dbus() is also called as default implementation
for compare-property. At least, for properties that are backed by a
GObject property.
The naming was not very clear. How does get_func(), synth_func()
and to_dbus() relate? What does synth_func() do anyway?
Answers:
- get_func() and synth_func() do very similar. They should be merged
in a next step.
synth_func() has the notion of "synthetize" a property for
D-Bus. As such, these properties are a bit unusual in that they
don't have a backing GObject property in the setting. But it'd
rather treat such properties like other properties. The step
in that direction will be to merge the to-dbus functions.
- to_dbus() converts a GValue of the GObject property go GVariant.
It's a simplified form of get_func()/synth_func() and a better name
is gprop_to_dbus_fcn().
The same for gprop_from_dbus_fcn().
For now, just rename.
We have certain artificial properties that not only depend on one
property alone or that depend on a property in another(!) setting.
For that, we have synth_func.
Other than that, synth_func and get_func are really fundamentally
similar and should be merged. That is because the distinction whether a
property value is "synthetized" or just based on a plain property is
minor. It's better to have the general concept of "convert property to
GVariant" in one form only.
Note that compare_property() is by default implemented based
on get_func. Hence, if get_func and synth_func get merged,
compare_property() will also require access to the NMConnection.
Also it makes some sense: some properties are artificial and actually
stored in "another" setting of the connection. But still, the property
descriptor for the property is in this setting. The example is the
"bond.interface-name" which only exists on D-Bus. It's stored as
"connection.interface-name".
I don't really like to say "exists on D-Bus only". It's still a valid
property, despite in NMSetting it's stored somehow differently (or not
at all). So, this is also just a regular property for which we have a
property-info vtable.
Does it make sense to compare such properties? Maybe. But the point is that
compare_property() function needs sometimes access to the entire
connection. So add the argument.
Always properly set NMSettInfoProperty.dbus_type, instead of leaving it
unspecified for GObject property based properties, and detect it each
time anew with variant_type_for_gtype().
Instead, autodetect and remember the dbus-type during _properties_override_add_struct().
For types that need special handling (GBytes, enums and flags) set a to_dbus() function.
This allows us to handle properties uniformly by either calling the to_dbus() function
or g_dbus_gvalue_to_gvariant().
- use cleanup attribute in get_property_for_dbus() and return early.
- use NM_FLAGS_HAS() macro in _nm_setting_to_dbus().
- in nm_setting_get_dbus_property_type() use g_return*() asserts
instead of crash or hard asserts.
- return early from variant_type_for_gtype().
This is a provide packages that install dispatcher scripts should depend
on. It will make it easier to keep track of them and possibly split out
the dispatcher into an optional package if not needed.
The monitors have been in place since the dispatcher has been introduced.
They need the daemon to do extra work know where the files are supposed to
be. It seems to me the complexity is not worth it.
Let's remove them now, making it easier to modify the dispatcher to look
for scripts in other places.
The dispatcher looks there for scripts now. This actually doesn't break
the RPM build, since it doesn't mind extra empty directories in
buildroot. Good.
While the keys of s390-options are from a well-behaving set of names
(that is enforced by nm_connection_verify()), the values are arbitrary
strings.
Our settings plugin must be able to express all values of a connection,
hence we need to support escapes.
- the previous implementation of nm_setting_wired_get_s390_option()
returned the elements in an arbitrary order (because it just iterated
idx times over the unsorted hash table).
- the API for "s390-options" suggests both accessing by index and by
name. Storing the options in a hash-table is not optimal for lookup
by index. It also requires us to sort the elements over and over
again.
Use instead a sorted array. Note that add/remove of course requires to
move the elements (and has thus O(n)).
- "s390-options" are very seldomly set. We shouldn't pay the price in every
NMSettingWired to allocate a GHashTable and deal with it.
- don't assert in nm_setting_wired_add_s390_option() and
nm_setting_wired_remove_s390_option() that the key is valid.
ifcfg-rh reader understandably does not want to implement additional
logic to pre-validate the key, so any invalid keys would trigger an
assertion failure. We have verify() for this purpose.
Currently, nm_setting_wired_get_s390_option() returns the key
in an undefined order. Hence, the keyfile writer and the test
need to awkwardly sort the keys first. That will be solved better
in the next commit, when nm_setting_wired_get_s390_option() returns
the items sorted by key.
The only remaining GValue transform function was from GHashTable (of (str,str) type)
to string. Drop that too, and implement the conversion in _get_fcn_gobject_impl().
Note that there are few GObject properties of type GHashTable and most
of them implement their own logic. This only applies to
"802-3-ethernet.s390-options".
Also, always sort the keys. Otherwise, the output is not stable.
The g_value_register_transform_func() for handling GBytes was not actually used.
All properties of type G_TYPE_BYTES have their explit handler how to convert bytes
to string. That is good, because the implementation there was very bad (it did not
honor pretty/parsable get-type).
Also, merge _get_fcn_gobject_bytes() into _get_fcn_gobject_impl(). We
already have a generic handler that handles properties solely based on
the GObject type: _get_fcn_gobject_impl(). Just let it also handle
bytes. It's better to have fewer handlers, if they don't need special
context.
It's ugly to modify the global behavior of glib to convert between
types. Instead, _get_fcn_gobject_impl() is perfectly capable to implement
converting a strv array to string.
"ipv4.dns-options" and "ipv6.dns-options" are special, in that they can
be either unset/default or an empty list of options. That means, nmcli
must treat these two options differently.
For the (terse) getter, it returns "" for default and " " for empty.
The setter must likewise support and distingish between these two cases.
Cleanup the handling of such options. This only applies to properties of
type "multilist". Hence, add multilist.clear_emptyunset_fcn() handler
that indicates that the property is of that kind.
Try:
nmcli connection modify "$PROFILE" ipv4.dns-options ''
nmcli connection modify "$PROFILE" ipv4.dns-options ' '
and compare the output:
nmcli connection show "$PROFILE" | sed -n '/ipv4.dns-options/ s/.*/<\0>/p'
nmcli -t connection show "$PROFILE" | sed -n '/ipv4.dns-options/ s/.*/<\0>/p'
nmcli -o connection show "$PROFILE" | sed -n '/ipv4.dns-options/ s/.*/<\0>/p'
The link-watcher properties are not expected to contain any special values
that require escaping. Hence, change the tokenizing from plain splitting
at ',' to escaped-tokens style is likely to not affect any existing
setups.
Still, all our properties should be handled the same way (including a
tokenizing which allows escaping to represent every possible value).
The vlanid and missed-max values have non-zero default values.
That is what nm_utils_team_link_watcher_from_string() honors.
Note that nm_utils_team_link_watcher_to_string() must omit printing
the value only if it's the default value too.
Otherwise, these values are not preserved during a to string conversion
and back.
Maybe a better fix would be to always print the values, regardless of
the default value. But arguably, that is quite ugly because in most
cases we don't want to cluter the string output with values that are
left at the default.
These tests cannot (easily) be under "shared/nm-libnm-core-aux/tests"
because libnm/libnm-core requires code under shared while
"nm-libnm-core-aux" requires libnm/libnm-core. With autotools that is
not problem, but with meson we include sub directories in a particular
order and there is no way to foward declare stuff (AFAIK). To avoid
the circular dependency, add the tests to "clients/common/tests", which
is always built last.
to/from string functions are useful. We should be able to reuse them.
Move them to their own location.
Also, it moves independent code out of "clients/common/nm-meta-setting-desc.c"
which is already one of the largest source files we have.
Also, it makes the code unit-testable, which is obviously required
as the code has bugs.
If a user disables networking, we consider that as an indication that
also software devices must be disconnected. OTOH, we don't want to
destroy them for external events as a system suspend.
When networking is disabled at NM startup we unmanage all devices
(including software ones) due to SLEEPING. After networking gets
enabled again we must clear the unmanaged-sleeping flag on software
devices.
When we do an in-tree-build with autotools and an out-of-tree build
with meson (all in the same source directory), then we have the
following files:
libnm-core/nm-core-enum-types.h
libnm/nm-enum-types.h
build/libnm-core/nm-core-enum-types.h
build/libnm/nm-enum-types.h
This caused "tools/check-docs.sh" for `ninja -C build test` to fail,
because the files are detected twice:
--- command ---
/data/src/NetworkManager/tools/check-docs.sh /data/src/NetworkManager /data/src/NetworkManager/build
--- stderr ---
8a9
> nm-core-enum-types
38a40
> nm-enum-types
*** Error: libnm classes not included in docs/libnm/libnm-docs.xml ***
-------
After 1.18.0 is released, merge it back into master so that
1.18.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.18.0 and 1.18-rc*.
Also bump the micro version to 1.19.1-dev to indicate that this is
after 1.18.0 is out.
We also generate a source tarball and artifact it.
Hence, we need proper gtk-doc links. This requires files in
/usr/share/gtk-doc/html for adding cross links. Install glib2-doc
package.
Note that in containers dnf is configured to not install documentation
files. We need to override that.
(cherry picked from commit a0f31e4038)
We also generate a source tarball and artifact it.
Hence, we need proper gtk-doc links. This requires files in
/usr/share/gtk-doc/html for adding cross links. Install glib2-doc
package.
Note that in containers dnf is configured to not install documentation
files. We need to override that.
