- Remove list of authors from files that had them; these serve no
purpose except to quickly get out of date (and were only used in
libnm-util and not libnm-glib anyway).
- Just say "Copyright", not "(C) Copyright" or "Copyright (C)"
- Put copyright statement after the license, not before
- Remove "NetworkManager - Network link manager" from the few files
that contained it, and "libnm_glib -- Access network status &
information from glib applications" from the many files that
contained it.
- Remove vim modeline from nm-device-olpc-mesh.[ch], add emacs modeline
to files that were missing it.
Some type-specific NMSetting implementations (bond, bridge, team, vlan)
have their own 'interface-name' property. This property will be
deprecated in favour of 'interface-name' in NMSettingConnection.
Change verify() and normalize() to check that the redundant
values match and repair/normalize the properties.
Force the virtual interface name of the type-specific setting to be
equal to NMSettingConnection:interface_name. This way, the depreacted
field stays valid and backward compatible.
NMSettingInfiniband is special, because it does not have a backing
property for the interface name, although it implements
get_virtual_iface_name(). To account for this, some special handling
is needed in order not to change the behaviour of get_virtual_iface_name().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Remove all the GParamSpec docs, since everything now uses the gtk-doc
docs instead, so there's no point in having two copies of each (which
are often out of sync anyway).
Since we're touching so many lines anyway, also fix up the indentation
of the remaining property-installing lines, and add
G_PARAM_STATIC_STRINGS to each paramspec (so the nick strings don't
get strduped). Also, be consistent about starting a new line between
"g_object_class_install_property" and its opening parenthesis.
Fix up various issues with the docs for the NMSetting properties, and
pull in text from the GParamSpec docs where the GParamSpec docs were
better (or contained information that is necessary in the context of
nm-settings.5).
Also, consistently wrap all of the doc comments to the same width (80
columns).
Fix misused gtk-doc annotations and incorrectly-identified properties.
In particular, the upcoming introspection-based generate-settings-spec
expands macro and enum values, so if you use '%' where you should have
used '#', it will fail to find an expansion, and error out.
- refactor register_settings to allow lookup by GType and
add the settings name to SettingInfo.
- setting NM_SETTING_NAME is deprecated and should not be set anymore.
Indeed it has always be a bug, to reset the name to a different value.
The only valid place to set the name was in the _init() function of
the derived class itself.
This is now no longer needed/possible. Instead the name get's
detected based on the registered setting types. This makes use of
the registered metadata that is available anyway since every
usable setting has to register itself.
Signed-off-by: Thomas Haller <thaller@redhat.com>
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
The public property is called NM_SETTING_VLAN_INTERFACE_NAME,
so also the internal field and the PROP_* enum should carry
the same name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
We want to free the element data, then remove the element from the
list. Instead the code freed the element data, then treated the
element data pointer as a GSList link, which is completely wrong.
For settings corresponding to devices that have a :carrier property
(ie bond, bridge, infiniband, vlan, and wired), add a :carrier-detect
property specifying how that affects the connection:
yes: The connection can only be activated when the device
has carrier, and will be deactivated if the device loses
carrier (for more than 4 seconds).
no: The connection ignores carrier on the device; it can be
activated when there is no carrier, and stays activated
when carrier is lost.
on-activate: The connection can only be activated when the
device has carrier, but it will not be deactivated if the
device loses carrier.
https://bugzilla.gnome.org/show_bug.cgi?id=688284
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
Do slightly more validation if NMSettingVlan properties, and make sure
that at least one method of specifying a parent is used.
Remove the check that id is in range, since gobject will not allow you
to set the property to a value outside its declared range anyway.
Add documentation so the API spec generator can do something
for the VLAN setting. Also enforce validation of the ingress
and egress priority maps; 802.1D priorities are limited to
values from 0 - 7 and Linux SKB values are 32 bits.
Also, the 'slave' property is a duplicate of the 'master'
property added to NMSettingConnection in the bonding work
so we can get rid of it and use 'master' instead.
