nm_device_get_device_type would report the device type as it was send on
DBus, while fetching the property would mean that only a known device
types is reported.
Make both results consistent by coercing in nm_device_get_device_type
rather than when setting the property.
(cherry picked from commit a6a185ba00)
The device type was set to the GType rather than a new value in the
NMDeviceType enum.
Add the corresponding enum entry, fix the device type and set the
routing priority to the same value as generic devices.
(cherry picked from commit 8d9365a973)
The @connection argument can be NULL; add the (allow-none) annotation
otherwise calling the API with a NULL argument through GObject
introspection fails with:
Argument 1 does not allow None as a value
Fixes: 278fd4fb0f
Use the same form everywhere: "TRANSLATORS" instead of "Translators".
The manual also seems to prefer the upper-case form [1].
$ sed 's/\<Translators\>: /TRANSLATORS: /g' $(git grep -l Translators) -i
[1] https://www.gnu.org/software/gettext/manual/gettext.html
If an operation is cancelled through the GCancellable, then the idiom is
that the operation is always cancelled, even if it has finished
successfully. To ensure this is the case, add calls to
g_simple_async_result_set_check_cancellable everywhere.
Without this, e.g. gnome-control-center will crash when switching away
from the power panel quickly, as the NMClient creation finishes
asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to
ensure it doesn't access the now invalid user_data parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=794088
It's very likely that the product said something that was filtered out
by the fixup, such as "PCI Ethernet" or "Wi-Fi Adapter". Use a generic
type name in place of it.
The product names are generally of rather poor quality. The product name
is no place to enumerate product capabilities, the bus it's attached on
and similar nonsense.
The hwdb generally contains the strings of rather poor quality,
especially when it comes to sensibly presenting them to the user and
they need various cleanups.
While the following patches add fixups, this one splits out vendor
fixups, because it turns out that a different set of fixups is needed
than for products.
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.
The new device type represents a PPP interface, and will implement the
activation of new-style PPPoE connections, i.e. the ones that don't
claim the parent device.
No need to create a separate NMUdevClient instance for all devices.
Instead, have one "struct udev" instance in NMClient and pass
it down during object construction.
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.
Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
Before switching to the ObjectManager, the D-Bus property was used to
decide the actual type of the device and the property set manually by
each subclass in its _init() function. Now we determine objects type
based on their D-Bus interface and therefore we can handle the
property like all others, ensuring that we return a known value in
get_property() to avoid warnings in GLib.
This fixes the missing initialization of the property which causes
regressions on clients as nm-applet.
Fixes: 1f5b48a59e
This speeds up the initial object tree load significantly. Also, it
reduces the object management complexity by shifting the duties to
GDBusObjectManager.
The lifetime of all NMObjects is now managed by the NMClient via the
object manager. The NMClient creates the NMObjects for GDBus objects,
triggers the initialization and serves as an object registry (replaces
the nm-cache).
The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
object creation, removal and property changes. It takes care of the
property changes so that we don't have to and lets us always see a
consistent object state. Thus at the time we learn of a new object we
already know its properties.
The NMObject unfortunately can't be made synchronously initializable as
the NMRemoteConnection's settings are not managed with standard
o.fd.DBus Properties and ObjectManager APIs and thus are not known to
the ObjectManager. Thus most of the asynchronous object property
changing code in nm-object.c is preserved. The objects notify the
properties that reference them of their initialization in from their
init_finish() methods, thus the asynchronously created objects are not
allowed to fail creation (or the dependees would wait forever). Not a
problem -- if a connection can't get its Settings, it's either invisible
or being removed (presumably we'd learn of the removal from the object
manager soon).
The NMObjects can't be created by the object manager itself, since we
can't determine the resulting object type in proxy_type() yet (we can't
tell from the name and can't access the interface list). Therefore the
GDBusObject is coupled with a NMObject later on.
Lastly, now that all the objects are managed by the object manager, the
NMRemoteSettings and NMManager go away when the daemon is stopped. The
complexity of dealing with calls to NMClient that would require any of
the resources that these objects manage (connection or device lists,
etc.) had to be moved to NMClient. The bright side is that his allows
for removal all of the daemon presence tracking from NMObject.
On D-Bus level, string (s) or object paths (o) cannot be NULL.
Thus, whenver server exposes such an object, it gets automatically
coerced to "" or "/", respectively.
On client side, libnm should coerce certain properties back, for which
"" is just not a sensible value.
For example, an empty NM_DEVICE_ETHERNET_HW_ADDRESS should be instead
exposed as NULL.
Technically, this is an API change. However, all users were well advised
to expect both NULL and "" as possible return values and handle them
accordingly.
Normalizing means that we fail on invalid connections.
Which can happen when the server is newer than the libnm
version. We just want to return whatever we can. The
caller should make sense of this.
This makes libnm more accepting and thus is not going to break
existing applications. Also, nm_device_get_applied_connection()
is new API since nm-1-1.
