Date: Wed, 4 Jun 2025 15:41:37 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Jan Bramkamp <crest@rlwinm.de> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: wireless KPI and KBI and FreeBSD 15 Message-ID: <CAJ-VmokZhpPtwjK-%2BbJVsUTQusCm9i1pTNwvGFQvovsnVPNT9A@mail.gmail.com> In-Reply-To: <81d53b6a-dd89-4d53-986d-171cec48233f@rlwinm.de> References: <114q5890-nrs9-55r5-44n9-86506985490s@SerrOFQ.bet> <b22a18d4-2b39-46ad-9888-53c189e41182@rlwinm.de> <CANCZdfrK_79aw1kg72%2B07ATfjyOnDAqsV3xt6fwua625A1xuFg@mail.gmail.com> <81d53b6a-dd89-4d53-986d-171cec48233f@rlwinm.de>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Wed, 4 Jun 2025 at 15:17, Jan Bramkamp <crest@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
[-- Attachment #2 --]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 4 Jun 2025 at 15:17, Jan Bramkamp <<a href="mailto:crest@rlwinm.de">crest@rlwinm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>On 05.06.25 00:04, Warner Losh wrote:</div><blockquote type="cite"><br><div dir="auto"><div dir="auto">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.</div>
</div>
</blockquote>
<p>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)?<br></p></div></blockquote><div><br></div><div>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.</div><div><br></div><div>For me - options really are:</div><div><br></div><div>* 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</div><div>* 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.</div>* 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</div><div class="gmail_quote gmail_quote_container">* we just don't backport anything to stable/15 except bugfixes, so whatever you have in stable/15 is what you get.</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">One of the big sticking points is that the existing ioctl API has a bunch of issues which makes extending it difficult.</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">For example:</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">* 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.</div><div class="gmail_quote gmail_quote_container">* 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.</div><div class="gmail_quote gmail_quote_container">* 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.</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">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.</div><div class="gmail_quote gmail_quote_container">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.</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">I hope that helps!</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">-adrian</div><div class="gmail_quote gmail_quote_container"><br></div></div>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokZhpPtwjK-%2BbJVsUTQusCm9i1pTNwvGFQvovsnVPNT9A>