GNOME Bugzilla – Bug 724365
danw/wifi-platform: move wifi-utils into platform (?)
Last modified: 2014-04-17 16:52:24 UTC
The danw/wifi-platform branch moves wifi-utils into platform, and adds NMPlatform wrappers around the wifi-utils functions. (If we're going to go this way, we'd probably eventually want to simplify the code some more, and, eg, use NMLinuxPlatform's existing libnl socket to get wifi data too.) The driver for this (other than a general feeling of "it belongs there", and that it could eventually help with testing) was that I wanted a single nm_platform_link_get_wake_on_lan() that checks for both ethernet WoL and WoWLAN (to genericize the patch in https://mail.gnome.org/archives/networkmanager-list/2013-November/msg00021.html) However, dcbw points out that this would mean that if we split NMDeviceWifi out into its own plugin, that we wouldn't be able to move wifi-utils with it, which would cut out on some of the savings. One way to address that would be to make NMPlatform be plugin-able too... though I'm not sure how we'd sanely do that, although wifi-utils is already an abstraction with netlink and wext backends, so making them both be implementations of "NMPlatformWifi" and then letting that be plugin-able could work... That could then lead to other stuff being moved into NMPlatform (and having testable dummy versions) too. Eg, bluez-manager, modem-manager, rdisc.
In the dcbw/dev-plugins branch I moved all those "managers" into the plugins themselves because I felt they logically belonged there, but obviously there's an argument to be made that it should be somewhere in the platform since that's what should be abstracting hardware-type stuff. My gut feeling here is that since Bluez and ModemManager are pretty encapsulated, and are D-Bus services, they can exist outside NMPlatform for now and still be easily testable with 'fake' D-Bus services like I did for libnm-glib. WiFi is harder because of both the supplicant and the direct kernel communication. I think we should move most of the wifi-utils/ stuff into the supplicant eventually, and then only the device detection (eg "is this wifi or is this ethernet") and maybe the WoL stuff will be left. I forgot that NMAccessPoint could also be shoved into a WiFi device plugin, and that totals ~65528 bytes. Which is a good savings. So my thought for now is to continue on your path here (wifi-utils/ -> NMPlatform) and then put only nm-wifi-ap & nm-device-wifi into a WiFi device plugin. Eventually most of wifi-utils will merge with the supplicant-manager code and the question will be mostly moot :)
(In reply to comment #1) > In the dcbw/dev-plugins branch I moved all those "managers" into the plugins > themselves because I felt they logically belonged there, but obviously there's > an argument to be made that it should be somewhere in the platform since that's > what should be abstracting hardware-type stuff. Let's say I originally meant it to include stuff that belongs to the operating system level. That basicaly covers the kernel and udev. Any other part of the system is to be evaluated separately. For example I don't think talking to wpa_supplicant would belong there, as wpa_supplicant has its own HW abstraction layers and you could either have fake implementation as part of the supplicant or you could have a whole fake supplicant. > My gut feeling here is that since Bluez and ModemManager are pretty > encapsulated, and are D-Bus services, they can exist outside NMPlatform for now > and still be easily testable with 'fake' D-Bus services like I did for > libnm-glib. +1 > WiFi is harder because of both the supplicant and the direct kernel > communication. Sounds like it could well be split. The kernel part would probably warrant inclusion into nm-platform. > I think we should move most of the wifi-utils/ stuff into the > supplicant eventually, and then only the device detection (eg "is this wifi or > is this ethernet") and maybe the WoL stuff will be left. Sounds good to me. > I forgot that NMAccessPoint could also be shoved into a WiFi device plugin, and > that totals ~65528 bytes. Which is a good savings. Sounds great. > So my thought for now is to continue on your path here (wifi-utils/ -> > NMPlatform) and then put only nm-wifi-ap & nm-device-wifi into a WiFi device > plugin. Eventually most of wifi-utils will merge with the supplicant-manager > code and the question will be mostly moot :) +1
(In reply to comment #0) > One way to address that would be to make NMPlatform be plugin-able too... My original intention was to avoid it and keep the API rather thin and shallow. If it was intended to be pluginable and complex, I would most probably try to make it a separate library and share it with other folks out there in a similar way that pyroute2 works.
pushed
oh, btw, you'll need to do: rm -rf src/.deps ./autogen.sh after updating. Apparently automake doesn't quite deal with moving files between directories when using non-recursive make?