Make WWAN support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1187224 1125208 (-5%)
MM: 0 100576
(all results from stripped files)
Make Bluetooth support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1253016 1187224 (-5%)
BT: 0 85752
(all results from stripped files)
Make ADSL support a plugin using the new device factory interface.
Provides a 1% size reduction in the core NM binary.
Before After
NM: 1265336 1253016 (-1%)
ATM: 0 27360
(all results from stripped files)
In preparation for making WWAN and Bluetooth plugins, rework
the device plugin interface to meet those plugins' needs and
port WiMAX over in the process.
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
Changing the default wired connection has always deleted the connection
(thus disconnecting the interface) and re-added it as a settings plugin
connection. That was always sub-optimal, but until the 'unsaved' connection
stuff landed this summer, we couldn't do anything about that. Clean
that all up, adding the connection as an unsaved connection right from
the start, which allows changes to the connection without having to
delete and recreate it, thus preventing disconnection of any interface
that is using the connection.
A new signal is added to NMSettingsConnection that is only emitted when
the connection is changed from D-Bus (thus indicating an explicit user-
requested change) since the connection may be modified internally by
NetworkManager. NM-triggered changes should not result in the connection
no longer being a default-wired connection.
https://bugzilla.gnome.org/show_bug.cgi?id=712188https://bugzilla.redhat.com/show_bug.cgi?id=1029464
NMBluezManager is now a proxy and only delegates to either
NMBluez4Manager or NMBluez5Manager. It detects the running BlueZ
version at runtime, and once it decides for one version, it cannot be
changed anymore as long NetworkManager is running.
This means, when switching from BlueZ4 to BlueZ5 or vice versa you have
to restart NetworkManager. This should be acceptable, because it is
not a common use case (most systems won't have both versions installed
anyway) and it greatly simplifies implementation.
Also note that NMBluez4Manager and NMBluez5Manager do not implement a
common interface. NMBluezManager delegates to the correct manager.
Having them share an common interface or base class would not simplify
the code, because NMBluezManager not only delegates, but it also acts as
a proxy until it is decided which BlueZ version is running. So, this
proxy-like behaviour would still be needed. The alternative would be to
merge the functionality of all three NMBluez*Manager classes into one.
This also removes the --enable-bluez4 configure switch, because both
versions are now always enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=709412
Signed-off-by: Thomas Haller <thaller@redhat.com>
The files nm-bluez-device.c and nm-bluez5-device.c are similar.
Merge them together into one file and handle the differences
using #if directives.
This commit does not actually change any functionality. All it does, is
merging the files together and separating the differences with #if#else.
The next commit will further add common functionality, so this
reduces code duplication for now.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At this moment we only support one of BlueZ 4 and 5,
which has to be defined at build time.
Patch rewritten by Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Build and use NMConnectivity regardless of build options; if you build
without libsoup, NMConnectivity will just always report that you have
full connectivity (like it does when you build with libsoup but don't
enable connectivity checking).
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
The nm-rdisc subsystem, just as the nm-platform subsystem is separately
testable and it proved convenient to be able to build the test programs
by just typing 'make' in the rdisc/platform directory where the source
code for those modules resides.
src/rdisc doesn't need a makefile just to point to the tests,
we can do that more easily from src/Makefile.am like we do for
all the other tests subdirs.
Merge the net-subsystem-monitoring functionality of NMUdevManager into
NMLinuxPlatform (and kill NMUdevManager). NMLinuxPlatform now only
emits link-added signals after udev processes the device, and uses
udev attributes to further identify the device. NMManager now
identifies devices solely based on the NMLinkType provided by the
platform.
This requires a very recent kernel to even compile, and the kernel
code is still rapidly changing (eg, adding IPv6 support). So take it
out for now, until it stabilizes.
This reverts commit 7f0f04d106.
With carrier handling moved to NMDevice, the only thing left in
NMDeviceWired was speed, which was actually ethernet-specific anyway.
So move that to NMDeviceEthernet, and then kill NMDeviceWired.
And change src/main.c to use the local allocation macros. This
results in much cleaner code, as one can see from the diff.
Because libgsystem is designed for nonrecursive make, it fits best in
the current recursive setup if we build . first. This will be a lot
nicer when we switch NM to a nonrecursive setup.
