From nobody Wed Jun 04 22:41:37 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bCMyS6f2Tz5xlQQ for ; Wed, 04 Jun 2025 22:41:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bCMyS4Gs5z3R4F for ; Wed, 04 Jun 2025 22:41:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-551ed563740so420082e87.2 for ; Wed, 04 Jun 2025 15:41:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749076910; x=1749681710; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8SzG/RJOzZPhRDxgdEEEJ0E3BmAYtaaMFp5XWq2M1EA=; b=PLHc6gQBmuvWdjKsrRy3ucz8K8W2WXlZ24TIKpw/qkPIzQR9/XoX0pItwpu/4lZmbK totb2Lx5+LWaig2u/KuVRTEWU77HbgZiZyU4QqlFe66Cm1AGGXqmlKTFMtoQH+Ay5m1w D2SnYVcghVYwOoXkQfjSbS+74b7Z9YdSCVStX3D9U9DHHJlEkbS+jlwwHdaO6stOCoFV VsLBZ+VbC9i0Ro4EO9XcKqxy/F8K48zZJVU3701tNwRjMo/KP+Yw+ymmwekhO7ttnfHI 3vQ1j0arULg0v8Vu/2e7oTyk3NqzLhEZgnSVW8+QifRTGiEC2itWe61XkysyEEu+f2x5 uSmQ== X-Gm-Message-State: AOJu0YymqMfzt2FCDARTwei4mWwY+ksKyzoliurpmB3tp5xbA4U3ra7p 6Wx519s992MAdQzpGCqYSnQpFEYNFPrA4SaO4AkrM1JiJmtHbcLhPHU63fR91tW9QcqlvYk/d/J bSOJIS73um9v+lB4MBaSnqi6db47MjHN3SQ== X-Gm-Gg: ASbGncshZ+TIQVFLKl2xqedmN/q/6mCcDB8uSjFFodKcnMzLoeVfUwz+G67+DaJ2cdb C4J3jnwf+PRhHp6RJDfD/zWglnx5iEiqXLxR75Dr+k8Vz7OehqwsE1srhJNGAVJV+0ftkbAV7Jx m/OOWSROTCftZbuttJV/zaVgGfBebAP6hsIw== X-Google-Smtp-Source: AGHT+IFqYjIQ6ADRewcoVAZ/SnGmrJpD70yPBNZcd3jsomTLNI33S3dES4GyRhzgeW5mv0ygFWjV9wkkKwW5P5tdmUk= X-Received: by 2002:a05:651c:3125:b0:32a:714c:12d1 with SMTP id 38308e7fff4ca-32ac716a5a0mr15540151fa.1.1749076910110; Wed, 04 Jun 2025 15:41:50 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <114q5890-nrs9-55r5-44n9-86506985490s@SerrOFQ.bet> <81d53b6a-dd89-4d53-986d-171cec48233f@rlwinm.de> In-Reply-To: <81d53b6a-dd89-4d53-986d-171cec48233f@rlwinm.de> From: Adrian Chadd Date: Wed, 4 Jun 2025 15:41:37 -0700 X-Gm-Features: AX0GCFtCS__kwUQv8kcwgokjPldH066F8uSTb4PBs7agEYUmBo6om1KRkWytDoc Message-ID: Subject: Re: HEADS UP: wireless KPI and KBI and FreeBSD 15 To: Jan Bramkamp Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e97e4b0636c6b3a1" X-Rspamd-Queue-Id: 4bCMyS4Gs5z3R4F X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] --000000000000e97e4b0636c6b3a1 Content-Type: text/plain; charset="UTF-8" On Wed, 4 Jun 2025 at 15:17, Jan Bramkamp 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 --000000000000e97e4b0636c6b3a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, 4 Jun 2= 025 at 15:17, Jan Bramkamp <crest@rlw= inm.de> wrote:
=20 =20 =20
On 05.06.25 00:04, Warner Losh wrote:

If you update userland and kerne= l at the same time, life will be good. It's only when you have skew that there's a problem.=C2=A0 So install both for src build, or up= date 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/1= 5 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 ge= t 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 bac= kport driver stuff only from current/16 to stable/15 where it's feasibl= e, but maintaining that will likely get difficult pretty quickly as the net= 80211 / 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.
<= div class=3D"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= .

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 ke= ys 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 repres= ent 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 managem= ent 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 abou= t 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

--000000000000e97e4b0636c6b3a1--