Commit graph

9 commits

Author SHA1 Message Date
Thomas Haller
989a6911ba
libnm: always finalize direct properties in NMSetting base class
Certain properties need to release memory when destroying the NMSetting.
For "direct" properties, we have all the information we need to do that
generically in the NMSetting base class. In practice, this only concerns
string properties.

See _finalize_direct() in "nm-setting.c".

However, if the NMSetting base class takes care of freeing the strings,
then the subclasses must not also unref the variable (to avoid double free).
Previously, subclasses had to opt-in for the base class to indicate that
they are fine with that.

Now, let the base class always handle it. We only need to make sure that
classes that implement direct string properties don't also try to free
the values during destruction.
2021-11-04 20:25:19 +01:00
Thomas Haller
0c7286a855
libnm: implement special setter for direct string property for mac address 2021-07-23 17:02:03 +02:00
Thomas Haller
b688fc3da4
libnm: use direct properties for NMSettingBluetooth 2021-07-23 17:02:02 +02:00
Thomas Haller
82e9f43289
libnm: add nm_sett_info_propert_type_direct_mac_address
A MAC address is a relatively common "type". The GObject property is of type string,
but the D-Bus type is a bytestring ("ay"). We will need a special NMSettInfoPropertType.

Note that like most implementations, the from-dbus implementation still is based
on GObject setters. This will change in the future.

Also note that the previous compare function was
_nm_setting_property_compare_fcn_default(). That is, it used to convert
the property to GVariant and compare those. The conversion to GVariant
in that case normalizes the string (e.g. it is case insensitive). Also,
only properties could be compared which were also convertible to D-Bus
(which is probably fine, because there is no guarantee the profiles that
don't verify can be compared).

The code now uses the direct comparison of the strings. That mostly
preserves the case-insensitivity of the previous comparison, because
the property setters for mac addresses all use
_nm_utils_hwaddr_canonical_or_invalid() to normalize the strings.
This is subtle, but still correct. Note that this will improve later,
by ensuring that the property setters for mac addresses automatically
perform the right normalization.
2021-07-23 17:02:01 +02:00
Thomas Haller
dc2e4d04f1
libnm: normalize mac-address properties in GObject property setter
The aim is that properties have a "type", that is, that similar
properties share a common behavior and appearance.

Most properties of type "mac-address" normalize the string in the
GObject property setter. Three don't. Let them also do that.

This is also relevant, because the compare function for mac-addresses
(_nm_setting_property_compare_fcn_default()) converts the properties
first to a "ay" GVariant. Which means the comparison is case
insensitive. Normalizing the values in the setter avoids that
inconsistency.
2021-07-23 17:02:01 +02:00
Thomas Haller
d6f802abcd
libnm: extend NMSettInfoSetting with an offset to the private data
NMSetting instances either have no private data, they use
g_type_add_class_private(), or they embed the private data in the
NMSetting struct.

In all cases, we can find the private data at a fixed offset. Track that
offset in the NMSettInfoSetting meta data.

This will be useful, because properties really are stored in simple
fields, like a boolean property can be stored in a "bool" field. We will
extend the property meta data to track the offset of this property
field, but we also need to know where the offset starts.
2021-07-12 13:34:40 +02:00
Thomas Haller
f3abf2491a
libnm: add code comment about preserving ABI for libnm GObject structs 2021-06-17 17:48:10 +02:00
Thomas Haller
65278461a3
libnm: hide NMSetting types from public headers
When subclassing a GObject type, the class and object structs
must be available and defined in the header.

For libnm, and in particular for NMSetting classes, we don't want
users to subclass NMSetting. It also doesn't work, because libnm
has internal code that is necessary to hook up the NMSetting class.
You cannot define your own type and make it work together with
libnm.

Having the structs in public headers limits what we can do with them.
For example, we could embed the private data directly in the structures
and avoid the additional indirection.

This is an API break, but for something that most likely nobody cares
about. Or better, nobody should care about. API is not what is
accidentally defined in a header, API was the library provides to
meaningfully use. Subclassing these types is not meaningful and was
only accidentally possible so far.

Only hide the structs for now. More cleanup is possible later. We shall
however aim to keep the padding and struct layout to not also break ABI.

(cherry picked from commit e46d484fae)
2021-06-11 22:36:50 +02:00
Thomas Haller
fdf9614ba7
build: move "libnm-core/" to "src/" and split it
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.

Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.

Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.

The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
2021-02-18 19:46:51 +01:00
Renamed from libnm-core/nm-setting-bluetooth.c (Browse further)