How do GL-iNet devices become supported by official OpenWrt releases?

[daniel]

@chance

• What are some examples of the "advanced features" that would be binary-only in this instance?

The relevant binary-only kernel modules are:

• sf_eswitch
  driver for an external (as in: chip next to the SoC) Gigabit switch

• sf_gmac
  Ethernet driver

• sf_hnat
  Hardware NAT flow-offloading

• sf_netlink
  middleware to speak with Linux Kernel interfaces

• sf_smac
  wifi driver

• sf_switch
  driver for the in-SoC Fast Ethernet switch

So without all that you basically have a nice CPU with a serial port and maybe bit-banged SPI for flash access. That's much better than nothing and a good base when starting developing the missing drivers.

@chance

• Would it be correct to say that the best path forward to support is for SiFlower to 1.) put in the work to update the binaries to work with the latest-ish kernel, 2.) rewrite the drivers to use kernel subsystems, and 3.) release the complete kernel sources.

2 and 3 are correct.
1 doesn't work.
(there are other options, such as a more clean dual-licenced middle-ware design like madwifi back then, but lets not go there)

@chance

• If this doesn't happen, is the best hope at support a limited feature set that forgoes the advanced, binary-only features?

Of course. You got to start from somewhere. In the moment you can build a recent kernel from source and it somehow boots that's a very good point for others to join-in.

@chance

• I take it that from a community/project perspective where developer time is incredibly precious, the herculean-sounding effort it would take to properly support such a device without any major support from the SoC manufacturer is hardly worth the benefit, right? Put another way, I imagine it's more beneficial to support devices where it isn't such an uphill climb?

It's not so easy to judge at this point because you may well find out that major parts of the proprietary components are not too different from existing ones and might be supported using existing drivers (e.g. stmmac Ethernet). WiFi is a huge amount of work even with the support of the vendor, and it multiplies if things have to be done using reverse-engineering techniques, of course. But it's not impossible.

@chance

• How does one even acquire the necessary experience to rewrite drivers in the manner necessary to provide support?

Well, unlike the proprietary mess out there, we got quite a bunch of well written and well documented drivers based on Linux subsystems. Understanding and working on improving these drivers (take any of the existing ethernet, dsa and mac80211 drivers which come with Linux as an example) helps to learn what is needed for such a driver to work, how to structure it and so on.