From nobody Thu Jun 05 16:40:27 2025 X-Original-To: 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 4bCqvF31X3z5y4qk for ; Thu, 05 Jun 2025 16:40:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 4bCqvD5p7yz46GV for ; Thu, 05 Jun 2025 16:40:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-234f17910d8so12490635ad.3 for ; Thu, 05 Jun 2025 09:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1749141639; x=1749746439; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+NsDsm2ggQVfjylY+KgnzlCdSqYYLriMWRgFpOhBDJ0=; b=XsqY93hg+Jgy5MMdebexezV/dR2xBOv4hv2t5fAN5tVnhc0ng5kXy7nSVhv2WzAl3F 4rWk2Kr2q903oCy91LUL0Am3f3FeI6lBfPcrvn6g6xdt71WpwQflSZAnPHcFrGNTRcry FyCS4LYpIlhEEtKdXRN+T49MHj/tn4LMQeWCy3WY0YAXU6dDXBYYF6zHVmjp+o3xZ29f WBijHiMiROKBr5444RAPSUjklopJhr+EhGhHTPm8qpayY52QP/kaGTw7FPkMpqs0Jo0v 0jkhCN4tp8qkjZE/tOlf9/icyqvMcKf6a0ycCgl+My34d/G+jBnjgF5ezwVlsFtu8ydA oX3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749141639; x=1749746439; h=content-transfer-encoding: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=+NsDsm2ggQVfjylY+KgnzlCdSqYYLriMWRgFpOhBDJ0=; b=NOyBYIdhzrtruqd644lWpLOWpA/yZnTdO++u2C05aK1o/sWrLoDAERKPqwvrBP0LAL 27VTdFq06yyP0XgBQXWd5Dh2SNV9FW86GHHgRl9dVsTmy6AHLmXLim+dOH5bhlKyt8dZ O9/K3uk7uwR4qYRoTQuMorfoR4K6wukrWmzoLrJ/L5oCr8AXbJB1xEEY7ecY17uoFbWC Vo2waO4adXVGHSvlgyakK2bz7tDEJVszB3A7zV61aDHSjh+vn3rupNGHmWoUM7D8tBRH nWQfFzjXODI8OmnwlfnSWKEeKvj/4k0Wii09XLVrC62JhjY9gCXwqGCwhN0ZW0fEw5mf tMWw== X-Forwarded-Encrypted: i=1; AJvYcCVVEj+smPnZk/BgI0jlaleLPYhswSjSbb4+kNm5TWcNgQRt72MdXPXOu5RLkI5qDzWIvmnfyE7z@freebsd.org X-Gm-Message-State: AOJu0YyqNFH4JZ+xO40NsZxXlXu92CnOPejZVTzX58x65h2cZzV/MhH4 SWzdJn76dk2VDj8JRmfe6M+W43RHiRLuxG24nXLQdPJ6Y8b/32D9QNxbqeuH5/vKxEhfvTM0kMS 597RV/6ugxfNnKVShrIuLwGKNAgpPVa/lh0b70rfFOA== X-Gm-Gg: ASbGncszqr7lbfG5YMvaCq5hBYcgXaO2gyJ9Rlcw6Rxh4I/wsw5NyDDVato3VVLjue/ EjUe8m+KERQ2nE6KGkmKMnvaa0eNZTMEQksVBbLLJ0mdgl5+ThdKJUxQn0yvgtfbbRpZk+QH9dj jB/LDCLUWgv8auaBX/a/z8Y+k6IXkx538O3ExTopyycAU= X-Google-Smtp-Source: AGHT+IEsje56mQizzVmk8OYuZaUMJ9hSo90yKidtK7uclOHp35YP6ARRw5DbHWWpe6IOy1M4WeNRX+SXDHZudrVeMZM= X-Received: by 2002:a17:90a:dfcb:b0:312:959:dc4f with SMTP id 98e67ed59e1d1-313472b6a6dmr552538a91.5.1749141638715; Thu, 05 Jun 2025 09:40:38 -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> <6803DF9A-5660-4F05-82CC-B4085584EF30@freebsd.org> <81E0167A-7330-4C67-BEAA-074A7CA26E63@FreeBSD.org> In-Reply-To: <81E0167A-7330-4C67-BEAA-074A7CA26E63@FreeBSD.org> From: Warner Losh Date: Thu, 5 Jun 2025 09:40:27 -0700 X-Gm-Features: AX0GCFsfX1-dK5L1XL7n1fXmb0EUHIVoXcfSTLTxGYCXwUFnuyQXBbWyxmkxPyI Message-ID: Subject: Re: HEADS UP: wireless KPI and KBI and FreeBSD 15 To: David Chisnall Cc: "Bjoern A. Zeeb" , wireless@freebsd.org, FreeBSD Current , FreeBSD Stable ML , desktop@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4bCqvD5p7yz46GV 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)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Thu, Jun 5, 2025 at 9:20=E2=80=AFAM David Chisnall wrote: > > On 5 Jun 2025, at 15:59, Warner Losh wrote: > > > Never going to happen. That's not possible today for any module at all. W= e can't even do minor releases with anything complicated (though some simpl= er drivers can work with sufficient effort). > > > When did this stop being a guarantee that we at least tried to provide? = We used to go through structures and add padding in places we thought might= need changes before a major release, make things that modules might use ha= ve explicit initialisation functions that would initialise newly added fiel= ds, and so on. We never did over major releases. Ever. The minor release for network drivers with the padding has generally worked OK. LinuxKPI has never been KBI stable because it's broken-by-design inlining encodes too many offsets into the clients. It's 100% of the reason we have the per-release repos now. Network clients have the padding for ifnet and other things that mostly works within a minor release. Many drivers are also insulated via newbus. That's why it's possible. But there always seem to be something that comes up that is an 'oops' in the interfaces that we don't know we did wrong until it breaks. > I thought KBI stability was something we promised during a major release = but it seems that now there=E2=80=99s an expectation that you recompile all= of your kernel modules every point release. The release engineering docs = still talk about KBI freezes for stable branches: > > https://download.freebsd.org/doc/en/articles/freebsd-releng/freebsd-relen= g_en.pdf This is the goal. We fall far short of the goal. LinuxKPI isn't KBI stable. It's broken by design, and nobody listened to me when I complained about it early because they were hyper worried about being able to inline for performance (without measurements to show that it actually helped). In addition, there's parts of the VM system that aren't stable that too many drivers need to use for performance. Etc. So while in theory you are correct, the observed history tells us we've fallen short and/or have too many unstable interfaces that drivers want/need to use. The biggest problem, imho, is that we don't designate which structures must be KBI-stable and we have no way to test that they remain stable. We could come up with these lists w/o a lot of difficulty. However, new things get added all the time, so it would be better if this were automated. We could now write something that checks this, but have not done so. It's become technologically possible in recent years. 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. Warner