On 6/4/25 11:58, Warner Losh wrote:
On Wed, Jun 4, 2025, 10:52 AM Bjoern A. Zeeb <[email protected]> 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
