Now that NMDevice reads the hwaddr directly from netlink, it's silly
to have every device subtype maintain its own hw-address property
(using data that it gets from the NMDevice base class).
Remove all the device-specific hw-address properties, and add one to
NMDevice instead. (Because of the way nm-properties-changed-signal
works, this has no effect on the D-Bus API.) Subclasses now call
nm_device_get_hw_address() in places where they used to just refer to
priv->hw_addr (and to simplify this, we now allow passing NULL for the
out length parameter, since the subclasses almost always know what the
length will be already).
Also reorganize/simplify a few other methods to take advantage of the
fact that NMDevice is now keeping track of the hw-address directly.
https://bugzilla.gnome.org/show_bug.cgi?id=699391
As with the other connection-matching methods, move the loop and the
device-independent bits into NMDevice. By reusing
nm_device_check_connection_compatible(), this means that most device
types now no longer need any type-specific code for this.
https://bugzilla.gnome.org/show_bug.cgi?id=693684
nm_device_connection_match_config() sounded more generic than it
really was; rename it to nm_device_find_assumable_connection(), which
is what it really does.
There was also a lot of redundancy/cut+paste in the subclass
implementations of connection_match_config(); Improve things by moving
the looping-over-connections code into NMDevice itself, and also doing
the general-device-compatibility and IP-config checking there, leaving
the device subclasses to just verify L2 properties. Which most of them
aren't doing...
https://bugzilla.gnome.org/show_bug.cgi?id=693684
Since NMDevice has a generic get_hw_address() method now, it can do
nm_device_spec_match_list() itself (for everything except ethernet,
which needs to match against s390 subchannels too).
https://bugzilla.gnome.org/show_bug.cgi?id=693684
Add a "need_carrier" argument to nm_device_is_available(), to allow
distinguishing between "device is not available", "device is fully
available", and "device is available except for not having carrier".
Adjust various parts of NMDevice and NMManager to allow for the
possibility of activating a connection with :carrier-detect = "no" on
a device with no carrier, and to avoid auto-disconnecting devices with
:carrier-detect = "on-activate".
https://bugzilla.gnome.org/show_bug.cgi?id=688284
Move some duplicated carrier-handling code into NMDevice (which can
introspect itself to see if it's a subclass that has carrier).
The "mostly ignore carrier" special handling for bridges and bonds is
now also handled as part of the NMDevice-level carrier handling.
https://bugzilla.gnome.org/show_bug.cgi?id=688284
The bridge master's carrier follows IFF_UP when no ports are added
and the ports' carrier when ports are added, so we shouldn't
depend on carrier when deciding whether to activate a bridge which
may not have any ports. Also when the
The code flow is actually somewhat simpler this way since the
subclasses don't have to ask NMDeviceWired for the address
every time. Plus then NMDeviceWired doesn't have to know
anything about its subclasses in the constructor.
When no slave is present, dynamic IP configuration (DHCPv4, DHCPv6,
IPv6 autoconf) cannot proceed. But static and link-local
configuration can. So if IPv4 requires DHCP but IPv6 is static,
it makes no sense to block IPv6 configuration from proceeding
just because DHCPv4 cannot.
