Re: HEADS UP: wireless KPI and KBI and FreeBSD 15
Date: Wed, 04 Jun 2025 20:42:55 UTC
On 6/4/25 11:58, Warner Losh wrote: > On Wed, Jun 4, 2025, 10:52 AM Bjoern A. Zeeb <bz@freebsd.org> wrote: > >> Hello, >> >> Cc: wireless, current, stable, desktop >> >> FreeBSD WiFi development has regained traction. We are facing a >> decision with FreeBSD 15 coming before the end of this year [1]. >> >> In order to continue WiFi development, upcoming changes will inevitably >> break the net80211-driver and net80211-userland interfaces. >> By FreeBSD's standards those would not be mergeable to stable branches, >> such as stable/15 then. >> >> This would imply development happening in FreeBSD 16-CURRENT (main at >> that point) would stay there. The first release to ship anything major >> beyond now would be FreeBSD 16.0 in December 2027 [1]. >> >> After some discussion we think this is not a feasible solution and we >> will declare the KPI and KBI for wireless as unstable in FreeBSD 15. >> >> This allows us to merge changes from main into stable/15 for inclusion >> in future point releases (e.g., 15.1, 15.2, etc.) as the code matures. >> However, this also means that during the lifetime of FreeBSD 15, we may >> introduce breaking changes affecting out-of-tree and in-tree drivers, >> userland-kernel interfaces, and chipsets. We will address these >> disruptions as they arise. >> >> Before finalizing this decision, we invite feedback from the community. >> If you have concerns or objections, please speak up now. >> > > I strongly support this. Ideally, we'd have good compat on 15.0 vs 15.4, > but wireless is in such a state that I think the project is better served > with the hassle of instability and better features faster than stability > and stagnation with our currently incomplete feature set. > > Please work with the maintsiners of the point release pkg repo maintainers > to help smoothe the experience for those ports that use the unstable ABIs. Please consider what breaks, when, and if support breaks then make sure it is being well documented in appropriate places (errata, src/UPDATING, ports/UPDATING, likely mailing list HEADS UP, etc.). Not sure why but it seems like developers sometimes don't get things into release notes that are issues which really should be documented there too. Man pages may benefit from bringing attention to user facing breaking changes and/or mentioning of the instability. It would be unfortunate if users broke networking because a driver in ports has/hasn't changed to the newer API with a matching a system update. We should consider more port versions and/or flavors for that case so someone doesn't have to choose between upgrading outdated/insecure packages and breaking their wifi connection. Care should be taken to keep pkg entries also matching (kmods repository should help there). Alternatively, strongly suggesting ports of the drivers need to be used/built though mandating it would probably be a bit far. If things break, it should be hard for users to get a system into a state that broke without getting all packages/tools/documentation needed to fix the issue while offline. I've never considered it to be a big stretch to need to switch to stable or current when going for newer and less tested features. Doing so would require users be aware that more things break more often. If the update improves security then I doubt users would complain so much even if special steps/considerations are needed. If it improves stability then such interaction could reduce complaints. If 15 becomes so unstable, will 14's updates and support look any different too? Wifi stability should also be considered for if these changes are just because of rapid development to get the network stack usable now vs if/when such changes are to update against upstream. We aren't Linux and aren't on their release schedule. Since we use some of their drivers we have to balance between breaking things and not updating sometimes just to follow what they are up to. Wireless in general leads to instability with WiFi and non-WiFi RF noise, implementation variations and bugs (all operating systems), materials traveled through (walls when mobile, dry vs rainy surfaces, etc. Documentation should make users aware that this driver update instability is a different instability than the natural one and maybe clarify implementation upgrades/fixes. Thanks again for making these improvements. > Warner > > Bjoern (on behalf of the Wireless Development Team) >> Tom >> Adrian >> Ed >> Joe >> >> [1] https://www.freebsd.org/releng/ >> >> -- >> Bjoern A. Zeeb r15:7 >> >> >