On Wed, 4 Jun 2025 at 15:17, Jan Bramkamp <cr...@rlwinm.de> wrote: > On 05.06.25 00:04, Warner Losh wrote: > > > If you update userland and kernel at the same time, life will be good. > It's only when you have skew that there's a problem. So install both for > src build, or update all the pkgbase packages at once. > > Are there neither WiFi driver kernel modules in ports nor any consumers of > the unstable ABIs (e.g. a WiFi manager other than the base system > wpa_supplicant)? >
The work that we need to do in -16 is likely going to churn both the KBI and ABI significantly. I can't stress enough how much work there is to do. For me - options really are: * we backport driver/stack/userland from current/16 to stable/15 when we have a good idea of when we've reached some feature/stability/driver support milestones, and it's a flag day in stable/15 * we backport driver/stack from current/16 to stable/15 like above, but we don't change the net80211 userland APIs in stable/15 - you won't get new net80211 facing userland features, and it's going to make stable/15 maintenance increasingly difficult as we'll have to spend time on a "stable/15" ioctl and management layer in net80211. * we backport driver stuff only from current/16 to stable/15 where it's feasible, but maintaining that will likely get difficult pretty quickly as the net80211 / linuxkpi 802.11 stuff changes quickly * we just don't backport anything to stable/15 except bugfixes, so whatever you have in stable/15 is what you get. One of the big sticking points is that the existing ioctl API has a bunch of issues which makes extending it difficult. For example: * we don't pass in the key size and net80211 treats the whole key ABI as a fixed size thing, so we can't support encryption keys bigger than 128 bits. * we don't have an extensible API (like nvlists, or any other form of type+length variable stuff like nl80211 uses in its messages) so growing 11ax, 6GHz features in structures becomes an incompatible ABI change. * how we currently represent channels is not going to scale for 6GHz support and beyond; we need to massively overhaul that, and a lot of driver, net80211 and userland management code is going to need changing. I also can't stress enough how much work bz@ has put into doing work in stable/15 and backporting it to stable/14 so stable users can benefit from the linux 802.11 driver work. It's a /lot/ of work. It however comes with being careful about how much stuff in current/15 can change without being forced to merge it to stable/14 to keep maintenance efforts under control. I hope that helps! -adrian
