GNOME Bugzilla – Bug 747846
wimax: drop WiMAX support
Last modified: 2015-04-17 16:43:53 UTC
I keep belatedly noticing that I've broken the wimax plugin in my gdbus branch. So, time to say good bye, I think.
Created attachment 301542 [details] [review] wimax: drop WiMAX support Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll eventually accidentally break some of the code in src/devices/wimax/ (if we haven't already). Discussion on the list showed a consensus for dropping support for WiMAX. So, remove the SDK checks from configure.ac, remove the WiMAX device plugin and associated platform/manager support, and deprecate all the APIs. For compatibility reasons, it is still possible to create and save WiMAX connections, to toggle the software WiMAX rfkill state, and to change the "WIMAX" log level, although none of these have any effect, since no NMDeviceWimax will ever be created. nmcli was only compiling in support for most WiMAX operations when NM as a whole was built with WiMAX support, so that code has been removed now as well. (It is still possible to use nmcli to create and edit WiMAX connections, but those connections will never be activatable.)
> src/platform/nm-linux-platform.c I think that platform should continue to detect the link_type WIMAX, even if it doesn't do much with it. E.g. we also detect OLPC_MESH, regardless of whether we support it (and whether the device plugin is loaded). I would completely drop LOGL_UNUSED1 and add to nm_logging_setup(): /* Check for compatibility domains */ else if (!g_ascii_strcasecmp (*iter, "HW")) bits = LOGD_PLATFORM; + else if (!g_ascii_strcasecmp (*iter, "WIMAX")) { + /* ignore removed log-domains silently */ + } LOGD_DEVICE = (1LL << 21), /* Device state and activation */ LOGD_OLPC = (1LL << 22), - LOGD_UNUSED1 = (1LL << 23), - LOGD_INFINIBAND = (1LL << 24), - LOGD_FIREWALL = (1LL << 25), ... + LOGD_INFINIBAND = (1LL << 23), + LOGD_FIREWALL = (1LL << 24), ... Maybe split this large commit into several smaller ones, so if somebody wants to resurrect WIMAX code, he can revert them one-by-one? Something like: - wimax: remove support from cli - wimax: remove device plugin - wimax: remove log-level from nm-logging - wimax: deprecate client API in libnm-glib/libnm-util - wimax: deprecate client API in libnm - wimax: remove build
Kill Kill Kill! (In reply to Thomas Haller from comment #2) > > src/platform/nm-linux-platform.c > > I think that platform should continue to detect the link_type WIMAX, even if > it doesn't do much with it. E.g. we also detect OLPC_MESH, regardless of > whether we support it (and whether the device plugin is loaded). Yeah, and we could even just create them as NMDeviceGeneric or something instead, so that they could be used with L3 connections if somebody bothered to install the WiMAX daemon. > Maybe split this large commit into several smaller ones, so if somebody > wants to resurrect WIMAX code, he can revert them one-by-one? Something like: > - wimax: remove support from cli > - wimax: remove device plugin > - wimax: remove log-level from nm-logging > - wimax: deprecate client API in libnm-glib/libnm-util > - wimax: deprecate client API in libnm > - wimax: remove build Not a bad idea, though I don't have a strong feeling on it.
(In reply to Dan Williams from comment #3) > > I think that platform should continue to detect the link_type WIMAX, even if > > it doesn't do much with it. E.g. we also detect OLPC_MESH, regardless of > > whether we support it (and whether the device plugin is loaded). OK. (Although a better analogy/precedent would be NM_LINK_TYPE_OPENVSWITCH, which we always recognize but never support.) > Yeah, and we could even just create them as NMDeviceGeneric or something > instead, so that they could be used with L3 connections if somebody bothered > to install the WiMAX daemon. They'll get created as NMDeviceGeneric whether we keep NM_LINK_TYPE_WIMAX or not. The only difference would be whether they have a :type-description of "wimax" or "unknown".
(In reply to Thomas Haller from comment #2) > Maybe split this large commit into several smaller ones, so if somebody > wants to resurrect WIMAX code, he can revert them one-by-one? If somebody wants to resurrect it then wouldn't they want to revert the entire patch? But anyway, if we think there's any plausible chance that someone will want to bring back WiMAX support in the future, then we shouldn't be removing it... But we don't. Pushed fixups to danw/no-wimax-bgo747846.
LGTM
pushed as 721e917