From owner-freebsd-wireless@freebsd.org Mon Apr 27 13:58:19 2020 Return-Path: Delivered-To: freebsd-wireless@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C75AE2B99FA for ; Mon, 27 Apr 2020 13:58:19 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 499mZg3qyrz44ly for ; Mon, 27 Apr 2020 13:58:19 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4F6101E66A for ; Mon, 27 Apr 2020 13:58:19 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4575A8D4A171 for ; Mon, 27 Apr 2020 13:58:18 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id DADD5E707D4 for ; Mon, 27 Apr 2020 13:58:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id yM_bPs-e0fmy for ; Mon, 27 Apr 2020 13:58:14 +0000 (UTC) Received: from [169.254.219.26] (unknown [IPv6:fde9:577b:c1a9:4902:e841:8270:be49:c245]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 8E8EEE707D3 for ; Mon, 27 Apr 2020 13:58:14 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-wireless@freebsd.org Subject: pondering WiFi forwards Date: Mon, 27 Apr 2020 13:58:13 +0000 X-Mailer: MailMate (2.0BETAr6146) Message-ID: <67FD6C98-7C30-463B-A052-4CC7F9FFD5CD@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 13:58:19 -0000 Hi, there is a longer-term vision that’s been floating around for more than a year now. I was contemplating it last year around BSDCan times when my private life came in the way. Times now are not exactly easy for most of us either at the moment. I want to float it around for discussion anyway. First I’d love to say thank you, everyone who has worked on wifi in the last two decades for FreeBSD. You deserve massive thanks and cheers as you made it work, kept it working, kept users happy! The fact is that looking back, for a long time now, (Free)BSD has been running behind the WiFi game. Like every BSD we don’t have enough hands. We’ve been porting drivers from one another and most of them from a Linux upstream or otherwise, e.g., via documentation. The current state is: we are lacking ac, ax, ay, ad, .. some mesh, some “IoT standards”, .., we are constantly lacking support for newer chipsets or even entire drivers. A lot of Linux drivers are currently Dual-Licensed or ISC licensed so we could just “take” them. We may not always like their coding style, they have different infrastructure, locking models, .. that’s all sortable. We saw that with drivers for wired networking, where vendors have a common “library” part and an os specific part to the extend possible. We see that it is possible with OpenZFS now where people are targeting 5 different OSes (to my knowledge). Neither happened over night. Graphics is in a similar position I’d guess though way ahead of WiFi. One thing that I personally see is that for as long as we look at upstream drivers and re-write them to our style and needs we’ll keep playing the 2nd class citizen game as we’ll have close to no chance to ever engage with upstream and only do the catch-up. We get snapshots at the time we port a driver with the features we have at that moment; moving forward afterwards means tracking upstream and keep porting things. If that work stalls, it is even harder for someone else to pick it up due to all the rewriting. It’s even harder if the path was upstream -> one BSD -> two BSD -> this BSD as we do have for some drivers. This often (only and thankfully) worked as one of you was responsible for all three BSDs :-) If you’ve seen the EuroBSDCon talk “Wireless Fidelity with bwfm(4)” [3] or looked at other WiFi driver ports they can take quite a while (especially if done in spare time). I recently looked at the ath10k code noticed this: The current total lines of upstream code measured like this (rough estimate): $ find . -type f -name "*.[ch]" | xargs wc -l | tail -1 61094 total The changes (including build framework) since the FreeBSD worktree was initially branched: 62 files changed, 37953 insertions(+), 6315 deletions(-) That is half the upstream driver having changed basically. If you cannot just create the diff from git and fast-forward most parts (re-)applying these changes might be a massive effort but even if you can do this along, maintenance stays a big task. The bottom line is: we need to find a way to make it easier to port drivers over, on the hw attach side, on the 80211 side, on the data path side. We need to catch up to support the newer standards. And then we should try to engage with upstream as well; but we do need to do our homework first. And we need this not only for the “in-tree” drivers, we need this for all drivers. If it is easy to port a driver, a non-friendly licensed driver can always live in ports, as it’s sometimes better to support something than nothing for users. And if porting is easier that means more people can help as the bar to entrance is lower. And that gets us out of the “hands” problem. FreeBSD has downstream consumers, Haiku, RTEMS (to my knowledge), NetBSD is synching from us as well [4] and I hope we can extend this “synching” more into collaborations and stay on the same page all-together also with the other BSDs in the future. If it is, this is not going to happen in the next weeks or months. How, I don’t know exactly yet. Some of this would probably be a largely iterative process. Some of this will require more work now and delay a few things a bit, some of the things we’ve been missing for too long already. The hope is that in the long-term it’ll be more rewarding for everyone. As the Phoronix article says “There is a lot of work left and years overdue.” We’d all love to just snip our fingers now and have this all solved in an instant. If you can please do ;-) Also, if you’d love to do something WiFi and not port and get working an entire driver, yet equally important, there’s PRs open for current drivers, the maintenance mentioned earlier to be done on quite a few, which equally would want someone looking at them. Any comments, questions (as much as I can answer at this point), .. would be appreciated. /bz [3] https://www.youtube.com/watch?v=8N0IL8APCHg&t=1m40s [4] https://blog.netbsd.org/tnf/entry/wifi_renewal_restarted