On Thu, Jun 5, 2025 at 9:20 AM David Chisnall <thera...@freebsd.org> wrote: > > On 5 Jun 2025, at 15:59, Warner Losh <i...@bsdimp.com> wrote: > > > Never going to happen. That's not possible today for any module at all. We > can't even do minor releases with anything complicated (though some simpler > 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 have > explicit initialisation functions that would initialise newly added fields, > 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’s 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-releng_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
