Have "len" before "elem_size". That is consistent with g_qsort_with_data()
and bsearch(), and is also what I would expect.
Note that the previous commit just renamed the function. If a user
of the new, changed API gets backported to an older branch, we will
get a compilation error and note that the arguments need to be adjusted.
The "nm_utils_" prefix is just too verbose. Drop it.
Also, Posix has a bsearch function. As this function
is similar, rename it.
Note that currently the arguments are provided in differnt
order from bsearch(). That will be partly addressed next.
That is the main reason for the rename. The next commit
will swap the arguments, so do a rename first to get a compilation
error when backporting a patch that uses the changed API.
Add option to set ofport_request when configuring ovs interface. When
connection with ofport_request configured is activated ovsdb will first
try to activated on the port set by ofport_request.
- name things related to `in_addr_t`, `struct in6_addr`, `NMIPAddr` as
`nm_ip4_addr_*()`, `nm_ip6_addr_*()`, `nm_ip_addr_*()`, respectively.
- we have a wrapper `nm_inet_ntop()` for `inet_ntop()`. This name
of our wrapper is chosen to be familiar with the libc underlying
function. With this, also name functions that are about string
representations of addresses `nm_inet_*()`, `nm_inet4_*()`,
`nm_inet6_*()`. For example, `nm_inet_parse_str()`,
`nm_inet_is_normalized()`.
<<<<
R() {
git grep -l "$1" | xargs sed -i "s/\<$1\>/$2/g"
}
R NM_CMP_DIRECT_IN4ADDR_SAME_PREFIX NM_CMP_DIRECT_IP4_ADDR_SAME_PREFIX
R NM_CMP_DIRECT_IN6ADDR_SAME_PREFIX NM_CMP_DIRECT_IP6_ADDR_SAME_PREFIX
R NM_UTILS_INET_ADDRSTRLEN NM_INET_ADDRSTRLEN
R _nm_utils_inet4_ntop nm_inet4_ntop
R _nm_utils_inet6_ntop nm_inet6_ntop
R _nm_utils_ip4_get_default_prefix nm_ip4_addr_get_default_prefix
R _nm_utils_ip4_get_default_prefix0 nm_ip4_addr_get_default_prefix0
R _nm_utils_ip4_netmask_to_prefix nm_ip4_addr_netmask_to_prefix
R _nm_utils_ip4_prefix_to_netmask nm_ip4_addr_netmask_from_prefix
R nm_utils_inet4_ntop_dup nm_inet4_ntop_dup
R nm_utils_inet6_ntop_dup nm_inet6_ntop_dup
R nm_utils_inet_ntop nm_inet_ntop
R nm_utils_inet_ntop_dup nm_inet_ntop_dup
R nm_utils_ip4_address_clear_host_address nm_ip4_addr_clear_host_address
R nm_utils_ip4_address_is_link_local nm_ip4_addr_is_link_local
R nm_utils_ip4_address_is_loopback nm_ip4_addr_is_loopback
R nm_utils_ip4_address_is_zeronet nm_ip4_addr_is_zeronet
R nm_utils_ip4_address_same_prefix nm_ip4_addr_same_prefix
R nm_utils_ip4_address_same_prefix_cmp nm_ip4_addr_same_prefix_cmp
R nm_utils_ip6_address_clear_host_address nm_ip6_addr_clear_host_address
R nm_utils_ip6_address_same_prefix nm_ip6_addr_same_prefix
R nm_utils_ip6_address_same_prefix_cmp nm_ip6_addr_same_prefix_cmp
R nm_utils_ip6_is_ula nm_ip6_addr_is_ula
R nm_utils_ip_address_same_prefix nm_ip_addr_same_prefix
R nm_utils_ip_address_same_prefix_cmp nm_ip_addr_same_prefix_cmp
R nm_utils_ip_is_site_local nm_ip_addr_is_site_local
R nm_utils_ipaddr_is_normalized nm_inet_is_normalized
R nm_utils_ipaddr_is_valid nm_inet_is_valid
R nm_utils_ipx_address_clear_host_address nm_ip_addr_clear_host_address
R nm_utils_parse_inaddr nm_inet_parse_str
R nm_utils_parse_inaddr_bin nm_inet_parse_bin
R nm_utils_parse_inaddr_bin_full nm_inet_parse_bin_full
R nm_utils_parse_inaddr_prefix nm_inet_parse_with_prefix_str
R nm_utils_parse_inaddr_prefix_bin nm_inet_parse_with_prefix_bin
R test_nm_utils_ip6_address_same_prefix test_nm_ip_addr_same_prefix
./contrib/scripts/nm-code-format.sh -F
Various synchronous methods (D-Bus calls) in libnm's NMClient API were
deprecated. The problem is that NMClient contains a cache of D-Bus
objects, and it gets updated by asynchronous events (D-Bus signals).
Those events get only processed when iterating the GMainContext, but
they are ordered.
When we perform a pseudo blocking D-Bus call with
g_dbus_connection_call_sync(), then GDBus creates a temporary
GMainContext, sends the request and iterates the internal context
blocking for the response. That is, this reply is not synchrounized with
the events that update the NMClient cache.
That is a problem for methods like nm_remote_connection_delete(),
because you call blocking delete, but afterwards the object is still in
the NMClient cache. That's why most blocking methods are deprecated.
While such blocking calls are therefore problematic, they can still be
very convenient to call from a simple script, a test tool or the python
REPL. See "examples/python/gi/nm-wg-set" which calls
nm_remote_connection_get_secrets(), and it would be (unnecessarily)
cumbersome to do the correct thing or using async API.
In particular, nm_remote_connection_get_secrets() doesn't retrieve an object
that is in the NMClient cache in the first place. Sure, the result is
out of order with the cache, but it's not obviously related and in most
cases it wouldn't matter to the user. So undeprecate this function again.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1345
It was documented to be an optional parameter. That is also in line
with g_dbus_connection_call(), which is essentially wrapped by nm_client_dbus_call().
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
The property wait-activation-delay will delay the activation of an
interface the specified amount of milliseconds. Please notice that it
could be delayed some milliseconds more due to other events in
NetworkManager.
This could be used in multiple scenarios where the user needs to define
an arbitrary delay e.g LACP bond configure where the LACP negotiation
takes a few seconds and traffic is not allowed, so they would like to
use nm-online and a setting configured with this new property to wait
some seconds. Therefore, when nm-online is finished, LACP bond should be
ready to receive traffic.
The delay will happen right before the device is ready to be activated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248https://bugzilla.redhat.com/show_bug.cgi?id=2008337
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
libnm-client-impl/nm-client.c:8398: warning: multi-line since docs found
libnm-client-impl/nm-device-macvlan.c:115: warning: multi-line since docs found
libnm-client-impl/nm-device-vxlan.c:540: warning: multi-line since docs found
libnm-client-impl/nm-device-vxlan.c:92: warning: multi-line since docs found
libnm-core-impl/nm-setting-ethtool.c:41: warning: multi-line since docs found
libnm-core-impl/nm-setting-ip-config.c:2475: warning: multi-line since docs found
libnm-core-impl/nm-setting-ip-config.c:2504: warning: multi-line since docs found
The typedefs in nm-types.h confuse gtkdoc-scan. It generates a
libnm-sections.txt file like this:
<SECTION>
<FILE>nm-types</FILE>
<TITLE>NMDeviceOvs</TITLE>
NMAccessPoint
NMActiveConnection
NMCheckpoint
NMClient
NMDevice
...
Note the wrongly picked title and, more importantly, the object types in
a bogus section. This in turn makes gtkdoc-mkdb fail to include the
property and signal documentation in appropriate sections.
Without nm-types.h, we need to mind the header dependencies. This means
that we need to order the headers that define types before the ones that
use them. Also, we need to break the depencency loops in few palces.
In glib_dep we specify
"-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40"
which is the dependency we use almost everywhere. With g-ir-scanner
this causes compiler warnings:
[xxx] Generating NM-1.0.gir with a custom command
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_object_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:252:13: warning: Not available before 2.70
252 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c: In function ‘dump_fundamental_type’:
/src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.c:370:13: warning: Not available before 2.70
370 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
g-ir-scanner: link: gcc -o /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0 /src/NetworkManager/build/tmp-introspectnas6f9u5/NM-1.0.o -L. -Wl,-rpath,. -Wl,--no-as-needed -L/src/NetworkManager/build/src/libnm-client-impl -Wl,-rpath,/src/NetworkManager/build/src/libnm-client-impl -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgmodule-2.0 -ludev -lgirepository-1.0 -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lglib-2.0
Work around that.
Meson's gnome.generate_gir() is not very flexibly in allowing to
pass extra `--cflags-begin {} --cflags-end` parameters.
Hack around by adding a pseudo dependency that resets
these defines.
See-also: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/331
See-also: 1234e5583a ('build/autotools: avoid compiler warning generating "NM-1.0.gir"')
libnm-core is also used by the daemon, thus currently dragging in
libnm-crypto there. But could we ever drop that dependency?
One use of the libnm-crypto is in functions like nm_utils_file_is_certificate()
in "nm-utils.h". These are part of the public API of libnm.
But this is not used by the daemon. Move it to "libnm-client-core"
to be closer to where it's actually used.
As we have unit tests in "libnm-core-impl/tests" that test this function,
those unit tests also would need to move to "libnm-client-impl".
Instead, add the actual implementation of these function to "libnm-crypto"
and test it there.
This patch moves forward declarations from public header "nm-utils.h" to
"nm-client.h". Arguably, "nm-client.h" is not a great name, but we don't
have a general purpose header in "libnm-client-public", so use this.
Note that libnm users can only include <NetworkManager.h> and including
individual files is not supported (and even prevented). Thus moving
the declarations won't break any users.
We expect to read NUL terminated strings. Upon NUL, we should do
something. Treat it as a line break.
Fixes: 8ae9cf4698 ('Revert "libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()"')
This partially reverts commit 4a9fcb0fc3, which replaced one-byte
reads with buffered ones in the VPN service plugin.
Unfortunately the buffering means that commands coming after the magic
"DONE" string were being pulled into the buffer. Secrets agents expect
a "QUIT" to come after the "DONE", and since with buffering "QUIT" was
in the buffer, this led to a twenty-second delay on every VPN
connection using a secrets manager.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1164
Fixes: 4a9fcb0fc3 ('libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()')
g_idle_add() uses G_PRIORITY_DEFAULT_IDLE priority. Most of the time we don't
care much about the priority.
But at the places that this patch changes, I think that using
G_PRIORITY_DEFAULT_IDLE (and following g_idle_add()) is more correct. The
reason for this is not very strong, except that it's probably the better
choice. And the old choice was made because I didn't realize that
g_idle_add() uses another default priority. Hence, the old choice was not
for good reasons either.
NMClient is strongly tied to the GMainContext with which it was created.
Several operations must only be called from within the context. There
was an assertion for that.
However, creating (and init_async()) should be allowed to call not
from within the GMainContext. So if the current context has no owner
(is not acquired), then it's also OK.
Fix the assertion for that.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
When cloud-init job (metadata service crawler) starts, it sends the
SIGTERM signal to nm-cloud-setup and force the nm-cloud-setup to
restart, however, because the error is not initialized as NULL in
`_init_start_cancelled_cb()` before it is set, nm-cloud-setup will hit
a dumped core.
TO fix it, initialize the error as NULL in `_init_start_cancelled_cb()`.
https://bugzilla.redhat.com/show_bug.cgi?id=2027674
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
Backtrace:
#0 g_logv (log_domain=0x7f833a872071 "GLib", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1413
#1 0x00007f833a81f043 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1451
#2 0x00007f833ab97230 in nm_utils_error_set_cancelled (is_disposing=<optimized out>, instance_name=<optimized out>, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2599
#3 nm_utils_error_set_cancelled (is_disposing=0, instance_name=0x0, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2590
#4 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7324
#5 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7307
#6 0x00007f833a93094a in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7ffff79cbb40, instance=0x5640ca267020, return_value=0x0, closure=0x5640ca29d430)
at ../gobject/gclosure.c:873
#7 g_signal_emit_valist (instance=0x5640ca267020, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffff79cbb40) at ../gobject/gsignal.c:3406
#8 0x00007f833a930a93 in g_signal_emit (instance=instance@entry=0x5640ca267020, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553
#9 0x00007f833a9a6475 in g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:513
#10 g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:487
#11 0x00005640ca1a8bd4 in sigterm_handler (user_data=0x5640ca267020) at src/nm-cloud-setup/main.c:599
#12 0x00007f833a819d4f in g_main_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:3337
#13 g_main_context_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:4055
#14 0x00007f833a86e608 in g_main_context_iterate.constprop.0 (context=0x5640ca268ef0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4131
#15 0x00007f833a819463 in g_main_loop_run (loop=0x5640ca24fdb0) at ../glib/gmain.c:4329
#16 0x00005640ca1a6d04 in nmc_client_new_waitsync (cancellable=0x5640ca267020, out_nmc=0x7ffff79cbfa0, error=0x7ffff79cbf98, first_property_name=0x5640ca1b11db "instance-flags",
first_property_name=0x5640ca1b11db "instance-flags") at src/libnm-client-aux-extern/nm-libnm-aux.c:129
#17 0x00005640ca1a3863 in main (argc=1, argv=<optimized out>) at src/nm-cloud-setup/main.c:639
gcc-12.0.1-0.8.fc36 is annoying with false positives.
It's related to g_error() and its `for(;;) ;`.
For example:
../src/libnm-glib-aux/nm-shared-utils.c: In function 'nm_utils_parse_inaddr_bin_full':
../src/libnm-glib-aux/nm-shared-utils.c:1145:26: error: dangling pointer to 'error' may be used [-Werror=dangling-pointer=]
1145 | error->message);
| ^~
/usr/include/glib-2.0/glib/gmessages.h:343:32: note: in definition of macro 'g_error'
343 | __VA_ARGS__); \
| ^~~~~~~~~~~
../src/libnm-glib-aux/nm-shared-utils.c:1133:31: note: 'error' declared here
1133 | gs_free_error GError *error = NULL;
| ^~~~~
/usr/include/glib-2.0/glib/gmessages.h:341:25: error: dangling pointer to 'addrbin' may be used [-Werror=dangling-pointer=]
341 | g_log (G_LOG_DOMAIN, \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
342 | G_LOG_LEVEL_ERROR, \
| ~~~~~~~~~~~~~~~~~~~~~~~
343 | __VA_ARGS__); \
| ~~~~~~~~~~~~
../src/libnm-glib-aux/nm-shared-utils.c:1141:13: note: in expansion of macro 'g_error'
1141 | g_error("unexpected assertion failure: could parse \"%s\" as %s, but not accepted by "
| ^~~~~~~
../src/libnm-glib-aux/nm-shared-utils.c:1112:14: note: 'addrbin' declared here
1112 | NMIPAddr addrbin;
| ^~~~~~~
I think the warning could potentially be useful and prevent real bugs.
So don't disable it altogether, but go through the effort to suppress it
at the places where it currently happens.
Note that NM_PRAGMA_WARNING_DISABLE_DANGLING_POINTER macro only expands
to suppressing the warning with __GNUC__ equal to 12. The purpose is to
only suppress the warning where we know we want to. Hopefully other gcc
versions don't have this problem.
I guess, we could also write a NM_COMPILER_WARNING() check in
"m4/compiler_options.m4", to disable the warning if we detect it. But
that seems too cumbersome.
Macros should (where possible and sensible) behave function-like.
That means for example, that they evaluate arguments only once, and
use parentheses around code that expands, so that unexpected uses
work correctly. The parentheses was missing.
Instead, just use the NM_FLAGS_ANY() macro which gets this right.
When NMClient gets destroyed, it unrefs all NMObject. We need to unbreak
cycles then, and the property getters must return NULL. In particular,
for "o" type properties (NMLDBusPropertyO), this was not done correctly.
For example, calling nm_device_get_active_connection() while/after
destroying the NMClient can give a dangling pointer and assertion
failure. This will also be covered by test_activate_virtual(). Probably
a similar issue can happen, when a D-Bus object gets removed (without
destroying NMClient altogether).
The fix is that nml_dbus_property_o_clear() needs to clear "nmobj". That
is correct, because the pointer is no longer valid and should not be there.
And the unit test shows that in fact a pointer is left there, and
clearing it fixes it.
That was different from an earlier attempt to fix this (in commit 62b2aa85e8
('Revert "libnm: fix dangling pointer in public API while destructing NMClient"')),
where clearing the pointer at a different place broke things. That
attempt was wrong, because nml_dbus_property_o_notify_changed() needs to be the
one that sets/clears nmobj field during a regular update. But the case
here is not a regular update, nml_dbus_property_o_clear() happens during
unregister/cleanup, and then we need to clear the pointer.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
https://bugzilla.redhat.com/show_bug.cgi?id=2039331https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/896
See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1064https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1075
This breaks test @nmcli_monitor. With this patch, `nmcli monitor` no
longer prints "There's no primary connection". Need to investigate why.
For now, revert the patch.
This reverts commit 2afecaf908.
While (and after) NMClient gets destroyed, nm_device_get_active_connection()
gives a dangling pointer. That can lead to a crash. This probably
affects all NMLDBusPropertyO type properties.
It's not clear how to fix that best. Usually, NMClient does updates in
two phases, first it processes the D-Bus events and tracks internal
data, then it emits all GObject signals and notifications.
When an object gets removed from the NMClient cache, then the second
phase is not fully processed, because the object is already removed
from the cache. Thus, the property was not properly cleared leaving
a dangling pointer.
A simple fix is to always clear the pointer during the first phase. Note that
effectively we do the same also for NMLDBusPropertyAO (by clearing the
"pr_ao->arr"), so at least this is consistent.
Somehow it seems that we should make sure that the "second" phase gets
full processed in this case too. But it's complicated, and it's not
clear how to do that. So this solution seems fine.
https://bugzilla.redhat.com/show_bug.cgi?id=2039331https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/896
When destroying NMClient, nm_device_get_active_connection() still
return dangling pointers. Add a unit test for that bug.
Obviously, the bug currently exists, so the relevant code is commented
out.
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
This patch is introducing a "ports" property to NMDevice. In addition it
is introducing nm_device_get_ports() and deprecating
nm_device_bond_get_slaves(), nm_device_bridge_get_slaves(),
nm_device_ovs_bridge_get_slaves(), nm_device_ovs_interface_get_slaves()
and nm_device_team_get_slaves().
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Currently a NML_DBUS_META_PROPERTY_INIT_FCN() property does not have
'extra' field available. In order to be able to call
'nml_dbus_property_ao_notify()' from the callback, the 'extra' field
must be available.
The patch is also dropping 'use_notify_update_prop' field as it only
existed to differentiate the union.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
