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.
