summaryrefslogtreecommitdiff
path: root/libnm-core/nm-setting-private.h
Commit message (Collapse)AuthorAgeFilesLines
* libnm: unify property-to-dbus handling of NMSettingThomas Haller2019-05-011-1/+1
| | | | | | | | | | | | | | | | | 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.
* libnm: rename function pointers of NMSettInfoPropertyThomas Haller2019-05-011-6/+6
| | | | | | | | | | | | | | | | | | | | | | 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.
* libnm-core: add vlans property to bridge-port settingBeniamino Galvani2019-03-261-0/+4
|
* libnm: rework _nm_setting_aggregate() to delegate to setting classThomas Haller2019-02-041-3/+0
| | | | | | | | Instead of special-casing the aggregate implementation for NMSettingVpn, delegate to a virtual function. This will also work with other settings, that have properties/secrets that are not GObject based properties.
* libnm: add _nm_setting_emit_property_changed() functionThomas Haller2019-02-041-0/+2
| | | | Will be used next.
* libnm: merge _nm_setting_clear_secrets() and *_with_flags()Thomas Haller2019-01-221-4/+3
|
* libnm: rework compare_property() implementation for NMSettingThomas Haller2019-01-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | NMSetting's compare_property() has and had two callers: nm_setting_compare() and nm_setting_diff(). compare_property() accepts a NMSettingCompareFlags argument, but at the same time, both callers have another complex (and inconsistent!) set of pre-checks for shortcuting the call of compare_property(): should_compare_prop(). Merge should_compare_prop() into compare_property(). This way, nm_setting_compare() and nm_setting_diff() has less additional code, and are simpler to follow. Especially nm_setting_compare() is now trivial. And nm_setting_diff() is still complicated, but not related to the question how the property compares or whether it should be compared at all. If you want to know whether it should be compared, all you need to do now is follow NMSettingClass.compare_property(). This changes function pointer NMSettingClass.compare_property(), which is public API. However, no user can actually use this (and shall not!), because _nm_setting_class_commit_full() etc. is private API. A user outside of libnm-core cannot create his/her own subclasses of NMSetting, and never could in the past. So, this API/ABI change doesn't matter.
* libnm,core: add _nm_connection_aggregate() to replace ↵Thomas Haller2019-01-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nm_connection_for_each_setting_value() We should no longer use nm_connection_for_each_setting_value() and nm_setting_for_each_value(). It's fundamentally broken as it does not work with properties that are not backed by a GObject property and it cannot be fixed because it is public API. Add an internal function _nm_connection_aggregate() to replace it. Compare the implementation of the aggregation functionality inside libnm with the previous two checks for secret-flags that it replaces: - previous approach broke abstraction and require detailed knowledge of secret flags. Meaning, they must special case NMSettingVpn and GObject-property based secrets. If we implement a new way for implementing secrets (like we will need for WireGuard), then this the new way should only affect libnm-core, not require changes elsewhere. - it's very inefficient to itereate over all settings. It involves cloning and sorting the list of settings, and retrieve and clone all GObject properties. Only to look at secret properties alone. _nm_connection_aggregate() is supposed to be more flexible then just the two new aggregate types that perform a "find-any" search. The @arg argument and boolean return value can suffice to implement different aggregation types in the future. Also fixes the check of NMAgentManager for secret flags for VPNs (NM_CONNECTION_AGGREGATE_ANY_SYSTEM_SECRET_FLAGS). A secret for VPNs is a property that either has a secret or a secret-flag. The previous implementation would only look at present secrets and check their flags. It wouldn't check secret-flags that are NM_SETTING_SECRET_FLAG_NONE, but have no secret.
* libnm: cleanup secret-flags setter and getterThomas Haller2019-01-071-0/+5
| | | | | | | | | | | | | | | | | | There are 3 kinds of secret flag implementations: 1) regular properties have a GObject property and a corresponding "-flags" property. 2) NMSettingVpn handles this entirely differently 3) NMSettingWirelessSecurity's WEP keys, where the secret keys share a flags property that does not follow the same naming scheme as 1). The getter and setter had a boolean "verifiy_secret", only to handle 3). Drop that parameter. Don't let NMSettingWirelessSecurity call the parent's implementation for WEP keys. Just let it handle it directly.
* libnm: pass serialization flags to settings synth_func()Thomas Haller2019-01-071-2/+4
| | | | | | | | | | | | | | | | | | | | | We will need access to the serialization flags from within the synth_func(). That will be for WireGuard's peers. Peers are a list of complex, structured elements, and some fields (the peer's preshared-key) are secret and others are not. So when serializing the peers, we need to know whether to include secrets or not. Instead of letting _nm_setting_to_dbus() check the flags, pass them down. While at it, don't pass the property_name argument. Instead, pass the entire meta-data information we have. Most synth functions don't care about the property or the name either way. But we should not pre-filter information that we have at hand. Just pass it to the synth function. If the synth function would be public API, that would be a reason to be careful about what we pass. But it isn't and it only has one caller. So passing it along is fine. Also, do it now when adding the flags argument, as we touch all synth implementations anyway.
* libnm: add generic-data for implementing NMSettingThomas Haller2018-08-101-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new way how NMSetting subclasses can be implemented. Currently, most NMSetting implementations realize all their properties via GObject properties. That has some downsides: - the biggest one, is the large effort to add new properties. Most of them are implemented on a one-by-one basis and they come with additional API (like native getter functions). It makes it cumbersome to add more properties. - for certain properties, it's hard to encode them entirely in a GObject property. That results in unusable API like NM_SETTING_IP_CONFIG_ADDRESSES, NM_SETTING_BOND_OPTIONS, NM_SETTING_USER_DATA. These complex valued properties only exist, because we currently always need GObject properties to even implement simple functionality. For example, nm_setting_duplicate() is entirely implemented via nm_setting_enumerate_values(), which can only iterate GObject properies. There is no reason why this is necessary. Note also how nmcli badly handles bond options and VPN data. That is only a shortcoming of nmcli and wouldn't need to be that way. But it happend, because we didn't keep an open mind that settings might be more than just accessing GObject properties. - a major point of NMSetting is to convert to/from a GVariant from the D-Bus API. As NMSetting needs to squeeze all values into the static GObject structure, there is no place to encode invalid or unknown properties. Optimally, _nm_setting_new_from_dbus() does not loose any information and a subsequent _nm_setting_to_dbus() can restore the original variant. That is interesting, because we want that an older libnm client can talk to a newer NetworkManager version. The client needs to handle unknown properties gracefully to stay forward compatible. However, it also should not just drop the properties on the floor. Note however, optimally we want that nm_setting_verify() still can reject settings that have such unknown/invalid values. So, it should be possible to create an NMSetting instance without error or loosing information. But verify() should be usable to identify such settings as invalid. They also have a few upsides. - libnm is heavily oriented around GObject. So, we generate our nm-settings manual based on the gtk-doc. Note however, how we fail to generate a useful manual for bond.options. Also note, that there is no reason we couldn't generate great documentation, even if the properties are not GObject properties. - GObject properties do give some functionality like meta-data, data binding and notification. However, the meta-data is not sufficient on its own. Note how keyfile and nmcli need extensive descriptor tables on top of GObject properties, to make this useful. Note how GObject notifications for NMSetting instances are usually not useful, aside for data binding like nmtui does. Also note how NMSettingBond already follows a different paradigm than using GObject properties. Nowdays, NMSettingBond is considered a mistake (related bug rh#1032808). Many ideas of NMSettingBond are flawed, like exposing an inferiour API that reduces everything to a string hash. Also, it only implemented the options hash inside NMSettingBond. That means, if we would consider this a good style, we would have to duplicate this approach in each new setting implementation. Add a new style to track data for NMSetting subclasses. It keeps an internal hash table with all GVariant properies. Also, the functionality is hooked into NMSetting base class, so all future subclasses that follow this way, can benefit from this. This approach has a few similiarties with NMSettingBond, but avoids its flaws. With this, we also no longer need GObject properties (if we would also implement generating useful documentation based on non-gkt-doc). They may be added as accessors if they are useful, but there is no need for them. Also, handling the properties as a hash of variants invites for a more generic approach when handling them. While we still could add accessors that operate on a one-by-one bases, this leads to a more generic usage where we apply common functionality to a set of properties. Also, this is for the moment entirely internal and an implementation detail. It's entirely up to the NMSetting subclass to make use of this new style. Also, there are little hooks for the subclass available. If they turn out to be necessary, they might be added. However, for the moment, the functionality is restricted to what is useful and necessary.
* libnm: rework setting metadata for property handlingThomas Haller2018-08-101-38/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NMSetting internally already tracked a list of all proper GObject properties and D-Bus-only properties. Rework the tracking of the list, so that: - instead of attaching the data to the GType of the setting via g_type_set_qdata(), it is tracked in a static array indexed by NMMetaSettingType. This allows to find the setting-data by simple pointer arithmetic, instead of taking a look and iterating (like g_type_set_qdata() does). Note, that this is still thread safe, because the static table entry is initialized in the class-init function with _nm_setting_class_commit(). And it only accessed by following a NMSettingClass instance, thus the class constructor already ran (maybe not for all setting classes, but for the particular one that we look up). I think this makes initialization of the metadata simpler to understand. Previously, in a first phase each class would attach the metadata to the GType as setting_property_overrides_quark(). Then during nm_setting_class_ensure_properties() it would merge them and set as setting_properties_quark(). Now, during the first phase, we only incrementally build a properties_override GArray, which we finally hand over during nm_setting_class_commit(). - sort the property infos by name and do binary search. Also expose this meta data types as internal API in nm-setting-private.h. While not accessed yet, it can prove beneficial, to have direct (internal) access to these structures. Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct naming scheme. We already have 40+ subclasses of NMSetting that are called NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a new, distinct name.
* libnm: use NMMetaSettingInfo for tracking setting priorityThomas Haller2018-08-101-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
* all: don't use gchar/gshort/gint/glong but C typesThomas Haller2018-07-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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[@]}"
* libnm: avoid constructor function for registering NMSetting typesThomas Haller2018-07-011-5/+0
| | | | | | | | | | 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.
* all: remove consecutive empty linesBeniamino Galvani2018-04-301-1/+0
| | | | | | | Normalize coding style by removing consecutive empty lines from C sources and headers. https://github.com/NetworkManager/NetworkManager/pull/108
* all: require glib 2.40lr/glib-2-40Lubomir Rintel2018-01-181-1/+1
| | | | | | RHEL 7.1 and Ubuntu 14.04 LTS both have this. https://bugzilla.gnome.org/show_bug.cgi?id=792323
* build: refine the NETWORKMANAGER_COMPILATION defineThomas Haller2018-01-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Note that: - we compile some source files multiple times. Most notably those under "shared/". - we include a default header "shared/nm-default.h" in every source file. This header is supposed to setup a common environment by defining and including parts that are commonly used. As we always include the same header, the header must behave differently depending one whether the compilation is for libnm-core, NetworkManager or libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h> depending on whether we compile a library or an application. For that, the source files need the NETWORKMANAGER_COMPILATION #define to behave accordingly. Extend the define to be composed of flags. These flags are all named NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the build are available. E.g. when building libnm-core.la itself, then WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE is not available but the internal parts are still accessible. When building nmcli, only WITH_LIBNM_CORE (the public part) is available. This granularily controls the build.
* libnm: add enum for setting prioritiesThomas Haller2017-06-071-4/+4
| | | | | | | | | | | | | | 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.
* libnm/trivial: rename _nm_register_setting function to _nm_register_setting_implThomas Haller2017-06-071-4/+4
| | | | | Avoid having the function _nm_register_setting() shadowed by a macro of the same name, but different behavior/arguments.
* core: negotiate the best base settingLubomir Rintel2017-05-311-2/+2
| | | | | | | 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.
* libnm-core: expose internal _nm_connection_verify() functionThomas Haller2017-03-021-16/+0
|
* all: cleanup includes in header filesThomas Haller2016-08-171-1/+0
| | | | | | | | | | | | - don't include "nm-default.h" in header files. Every source file must include as first header "nm-default.h", thus our headers get the default include already implicitly. - we don't support compiling NetworkManager itself with a C++ compiler. Remove G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support users of libnm to use C++, thus they stay in public headers. (cherry picked from commit f19aff89095ca192b8b2e37534b7a899aecd82f9)
* libnm-core: allow strict and relaxed error behavior for ↵Thomas Haller2016-03-261-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _nm_setting_new_from_dbus() 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.
* libnm: add nm_setting_verify_secrets() and nm_connection_verify_secrets()Jiří Klimeš2015-11-201-0/+5
| | | | | | | 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.
* libnm: mark properties that take effect immediately on active connection ↵Thomas Haller2015-09-181-0/+10
| | | | | | (REAPPLY_IMMEDIATELY) The flag is still unused.
* all: make use of new header file "nm-default.h"Thomas Haller2015-08-051-1/+1
|
* all: rename nm-glib-compat.h to nm-glib.h, use everywhereDan Winship2015-07-241-1/+1
| | | | | | | | | | | | | | | | 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).
* all: remove #if GLIB_CHECK_VERSION conditionals around g_type_init()Thomas Haller2015-07-121-1/+1
| | | | g_type_init() is now provided by nm-glib-compat.h as nm_g_type_init().
* libnm-core: change how new and legacy properties are serializedDan Winship2014-11-151-0/+8
| | | | | | | | | | | | | | | Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
* libnm-core: tweak handling of overridden propertiesDan Winship2014-11-071-1/+3
| | | | | | | | | | | | | | | | | nm_setting_compare() and nm_setting_diff() were ignoring the get_func of overridden properties, because that function requires passing an NMConnection, and they didn't have one to pass. This wasn't a problem yet because the only user of _nm_setting_class_override_property() wasn't using a get_func anyway, but it would cause problems later. The connection arg to NMSettingPropertyGetFunc is really there to be used by D-Bus-only properties (which don't get compared anyway), not for ordinary property overrides. So split it into two different function types: NMSettingPropertySynthFunc (used by D-Bus-only properties, to synthesize a fake property value for D-Bus, possibly using other properties in the NMConnection), and NMSettingPropertyGetFunc (used by overridden properties for both D-Bus and comparison purposes, and not getting an NMConnection argument).
* libnm-core: make nm_setting_verify() take an NMConnectionDan Winship2014-10-281-13/+2
| | | | | | | | | nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
* libnm-core: clean up NMConnectionErrorDan Winship2014-10-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename NM_CONNECTION_ERROR_UNKNOWN to NM_CONNECTION_ERROR_FAILED, following GError best practices. Replace NM_CONNECTION_ERROR_CONNECTION_SETTING_NOT_FOUND ("no NMSettingConnection") with a more generic NM_CONNECTION_ERROR_MISSING_SETTING. Use that new code in a few places that had previously been using NM_CONNECTION_ERROR_SETTING_NOT_FOUND, which was supposed to mean "the setting that you asked about doesn't exist", not "the connection is invalid because it's missing a required setting". Clarify that NM_CONNECTION_ERROR_INVALID_SETTING can be used for any "invalid or inappropriate NMSetting", not just a "conflicting" one. (But fix a case in nm_connection_update_secrets() that was returning INVALID_SETTING when it should have been return-if-failing instead.) For both MISSING_SETTING and INVALID_SETTING, always prefix the error message with "setting-name: ", just like we do with the various NMSetting MISSING_PROPERTY and INVALID_PROPERTY errors. And make sure that the error message is marked for localization. Drop NM_CONNECTION_ERROR_CONNECTION_TYPE_INVALID, which is pretty pointless; it was only used in the case where connection.type was the name of a valid setting type that is not a base setting type. Instead, just return NM_SETTING_CONNECTION_ERROR_INVALID_PROPERTY for connection.type in this case (which is what the code already did when connection.type was completely unrecognized).
* libnm-core: drop nm_setting_lookup_type_by_quark()Dan Winship2014-10-221-4/+2
| | | | | | | | | | | | nm_setting_lookup_type_by_quark() was only ever used in places that were still mistakenly assuming the old style of nm_connection_verify() errors, where the error message would contain only a property name and no further explanation. Fix those places to assume that the error will contain a real error message, and include both the setting name and the property name. Given that, there's no longer any need for nm_setting_lookup_type_by_quark(), so drop it.
* libnm: hide API for generic handling of secretsThomas Haller2014-10-121-0/+2
| | | | | | | | The functions nm_setting_clear_secrets(), nm_setting_clear_secrets_with_flags(), and nm_setting_need_secrets() are not used outside of libnm-core. Remove them from public API. Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-core: change connection hash tables to variants in APIDan Winship2014-09-181-26/+24
| | | | | | | | | | In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
* libnm-core: drop the ability to verify settings from property overridesDan Winship2014-09-171-11/+4
| | | | | | | | | | | | | | | | | | It needs to be possible to deserialize a connection hash into an invalid NMConnection; in particular, AddAndActivateConnection() explicitly allows this. Previously, the SetFunc and NotSetFunc passed to _nm_setting_class_override_property() could return a verification error immediately, but this functionality has to go away if we're going to be able to deserialize invalid connections. That functionality was only used in the handling of invalid virtual interface names; reorganize how that code works so that NMSettingConnection does all of the verification itself. (The code to make sure that it returned the "correct" error domain in that case turned out to be irrelevant, since the setting error domains don't get serialized over D-Bus correctly anyway.)
* libnm-core: add _nm_setting_class_transform_property()Dan Winship2014-09-041-0/+9
| | | | | | | | | | Add a new kind of setting property override, for indicating that a property exists in both the NMSetting and the D-Bus representation, but in different formats, requiring conversion from one to the other. Also, if a property is transformable, then compare the transformed forms in nm_setting_compare() (since the D-Bus property types have more metadata built-in).
* libnm-core: drop :interface-name properties on virtual NMSetting typesDan Winship2014-09-041-9/+12
| | | | | | | | | | | | | Remove the virtual :interface-name properties and their getters, and use property overrides to do backward-compat handling when serializing/deserializing. Now when constructing an NMConnection from a hash, if the virtual property is set and the NMSettingConnection property isn't, then the override for NMSettingConnection:interface-name will set that property to the value of the virtual interface-name. And when converting an NMConnection to a hash, the overrides for the virtual properties will return the value of NMSettingConnection:interface-name.
* libnm-core: simplify _nm_register_setting(), register error types tooDan Winship2014-09-041-2/+6
| | | | | | | | Simplify the use of _nm_register_setting() by having it splice together various symbol names itself rather than requiring them to be specified explicitly, and extend it to also ensure that the type's corresponding error type is registered (allowing one to find it via g_type_from_name() if necessary).
* libnm-core: add property overrides to NMSettingClassDan Winship2014-09-041-0/+11
| | | | | Add _nm_setting_class_override_property(), for modifying the mapping between a GObject property and its D-Bus serialization.
* libnm-core: add dbus-only properties to NMSettingClassDan Winship2014-09-041-1/+20
| | | | | | | | | | | | | | | | | | | | | Add _nm_setting_class_add_dbus_only_property(), for declaring properties that appear in the D-Bus serialization, but which don't correspond to GObject properties. Since some property overrides will require examining settings other than the setting that they are on (eg, the value of 802-11-wireless.security depends on whether an NMSettingWirelessSecurity setting is present, and NMSettingConnection:interface-name might sometimes be set from, eg, bond.interface-name), we also update _nm_setting_to_dbus() to take the full NMConnection as an argument, and _nm_setting_new_from_dbus() to take the full connection hash. Additionally, with some deprecated properties, we'll want to validate them on construction, but we don't need to keep the value around after that. So allow _nm_setting_new_from_dbus() to return a verification error directly, so we don't need to store the value until the verify() call.
* libnm-core: rename NMConnection to/from_hash methodsDan Winship2014-09-041-3/+4
| | | | | | | | | | | | Rename nm_connection_to_hash() to nm_connection_to_dbus(), and nm_connection_new_from_hash() to nm_connection_new_from_dbus(). In addition to clarifying that this is specifically the D-Bus serialization format, these names will also work better in the GDBus-based future where the serialization format is GVariant, not GHashTable. Also, move NMSettingHashFlags to nm-connection.h, and rename it NMConnectionSerializationFlags.
* libnm-core: make the NMSetting hash methods privateDan Winship2014-09-041-0/+6
| | | | | | | | | | | | Make nm_setting_to_hash() and nm_setting_new_from_hash() private, and remove the public nm_setting_update_secrets() wrapper around the existing private _nm_setting_update_secrets(). These functions should really only be called from the corresponding NMConnection-level methods, and in particular, with certain compatibility properties in the future, we will need to consider the entire connection all at once when setting properties, so it won't make sense to serialize/deserialize a single setting in isolation.
* libnm-core: normalize NMSettingConnection:type propertyThomas Haller2014-08-221-0/+1
| | | | | | | | | nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-core: normalize slave-type and slave-settings of connectionsThomas Haller2014-08-221-0/+3
| | | | | | | | | | Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-core: add _nm_setting_find_in_list_required() functionThomas Haller2014-08-221-0/+6
| | | | | | | | | | | This is an utility function that can be called during verify() to find an NMSetting from @all_settings. This is especially useful for looking up the NMSettingConnection which usually is present. So just get it quickly. In the unexpected case that it is missing, it sets @error and we can return. Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm: move declaration of NM_SETTING_SECRET_FLAGS_ALL to nm-core-internal.hThomas Haller2014-08-221-6/+0
| | | | | | | | As NM_SETTING_SECRET_FLAGS_ALL is used in libnm/nm-vpn-plugin-utils.c, it is exposed as internal API and should be declared in nm-core-internal.h. Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-core: declare NM_SETTING_COMPARE_FLAG_INFERRABLE flag in ↵Thomas Haller2014-08-221-7/+2
| | | | | | | | | "nm-core-internal.h" As this flag is used by NM-core, move it to nm-core-internal.h header file. Signed-off-by: Thomas Haller <thaller@redhat.com>
* all: add nm-core-internal.h headerThomas Haller2014-08-221-5/+0
| | | | | | | | | | | | | | | | Add a header file to expose private utility functions from libnm-core that can be used by NetworkManager (core) and libnm.so. The header is also used to give privileged access to libnm-core. Since NM links statically, these functions are not exported and not part of public ABI. This also removes the NM_UTILS_PRIVATE_CALL() macro and libnm.so no longer exports nm_utils_get_private(). Before, this functionality was partly declared in nm-utils-private.h. This was wrong because nm-utils-private.h is for functionality entirely private to libnm-core. Signed-off-by: Thomas Haller <thaller@redhat.com>
View Lorry Controller Status