On Thu, 5 Jun 2025 at 10:03, Brooks Davis <bro...@freebsd.org> wrote:
> On Thu, Jun 05, 2025 at 09:40:27AM -0700, Warner Losh wrote:
> > Bringing it back to wifi: we're so far behind the curve on WiFi today
> > that we shouldn't saddle it with stability prematurely. We should do
> > things like kv pairs to make it better. We should try not to shoot
> > ourselves in the foot. But mistakes will be made almost certainly
> > despite due care, and I'd rather give the wifi folks a
> > get-out-jail-free card on a temporary basis to allow them to catch up
> > because doing backwards compat stuff isn't super hard, but can be
> > super time-consuming especially when there's no tests to assure
> > accidents don't happen and tracking down why something crashed for
> > binary compat reasons can take a huge amount of time. At least when I
> > did this stuff for a release or two for drm-kmod when we did try hard
> > to stay compatible for several minor releases. It was a ton of work. I
> > don't think we currently have the resources to commit to that work
> > because it will come at the expense of new features.
>
> I think this is the best compromise.
>
> I do think we might want to consider batching of wifi MFCs so most
> breaks occur infrequently (perhaps around release time) rather than
> scattered through out the inter-release period. My thinking here is
> that we shouldn't be breaking things for stable users more often than
> necessarily and for the brave it wouldn't be that big a deal to pull
> from a rebased MFC candidate branch. This wouldn't be free, but maybe
> it's got a reasonable cost/benefit ratio.
>
The root of all of this is that we want to be able to do work in -HEAD that
is going to be disruptive enough
that MFCs that don't break ABI/KBI are non trivial.
Like, right now I'm starting on the /beginning/ bits of disruptive changes
that aren't going to
be MFCed back to stable/14, and said changes involve locking behaviour,
which includes
driver changes (as the locking is being removed and some stuff pushed into
the drivers.)
This creates maintenance overhead for bz@ if he wants to also MFC anything
else we do on
current/15 to stable/14.
There's a big one coming, and it's how we represent channels. That's not
going to be fixed
with structure padding or accessor functions. I'm going to have to do
significant surgery
first to everything to clean up how we access channels in drivers and
net80211, and THEN
change how we store/represent them. That'll absolutely be both an ABI and
KBI breaking
change. It'll be incremental, but it won't be backwards compatible.
This is what we want to unlock. Everyone's talking about the impact on
stable/15, but
let me be a bit clearer - development isn't going to happen on stable/15.
Development
is going to happen on the tail end of current/15 and current/16. The
discussion really
revolves around "how much would you all like to see merged into stable/15."
If everyone over-indexes on stable/15 wifi stability, ABI, KBI, etc, then
you're going to
see one of two things:
* development on current/16 will happen at a rate we can MFC it to
stable/15 without breaking stuff,
which means we won't really ever be able to do the intrusive changes we
need for the rest of 11ac,
11ax, 6GHz, 60GHz, WPA3, etc. All the juicy stuff people would /super/
like, and thus we'll end up
working slower or not at all in various areas, or
* development on current/16 will happen at a rate where we just sprint fast
and churn a lot of stuff,
and we can choose how much in stable/15 in the {stability, KBI/API churn,
features, drivers, effort}
tuple you'll tolerate/accept. If y'all want it frozen, keep it frozen. If
new drivers show up, great.
But at some point net80211 and the linuxkpi 802.11 code is going to
diverge between current and
stable, and things will be increasingly painful to keep updated.
-adrian
