Date: Wed, 27 Jun 2018 20:37:22 -0400 From: waddlesplash <waddlesplash@gmail.com> To: freebsd-wireless@freebsd.org Subject: Haiku's usage of the FreeBSD net80211 stack and drivers Message-ID: <CAEesM77h45EcKPBN4h7REhG==d=3CzVbjyVj6wKTzrD-dw_MiA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, I'm one of the developers of the Haiku operating system [1]. For those who are unfamiliar, it's a free and open-source reimplementation & continuation of BeOS. We have our own kernel and driver stack, initially (~2003) forked from the NewOS kernel, but now very substantially diverged in both structure and essence from it. Most of our network stack (buffers, TCP, UDP, etc.) is a work of our own creation. However, we are still a pretty small team, so for network drivers we have (since 2010) a compatibility layer for FreeBSD network drivers. This layer essentially implements all of the FreeBSD KPIs (ifnet, busdma, mbuf, etc.) that network drivers use. We've fallen behind a bit; until earlier this year we were still using said drivers from FreeBSD 9, but we're finally rectifying that now. To make a (very) long story short, I have indeed managed to sync FreeBSD 11.1's net80211 code as well as the iwn driver and make them work on Haiku, with many thanks to the assistance of various people from EFnet#freebsd-wifi. Upon hearing that we had Haiku-specific patches to said code, Adrian suggested he'd like to look at them, mentioning that he'd also potentially like to de-FreeBSDify net80211, and directed me to this mailing list. The specific changes which might be candidates for merging into FreeBSD are as follows: 1. no *SYSINIT() -- our runtime loader doesn't support it, and we have no plans / otherwise need for it, so instead we call all functions that SYSINIT would manually in the appropriate location. 2. ieee80211req_scan_result now contains a complete ieee80211_channel, not just the freq and flags (we use this in userland) 3. NULL checks on dst in ieee80211_output(), as we pass in NULL from our hooks code in some places 4. casts so the header files can compile as C++ (ieee80211_haiku is a .cpp not a .c so we can use Haiku kernel routines which are C++) 5. calling ieee80211_vap_xmitpkt instead of iv_output in ieee80211_output(), as our iv_output is pretty much ethernet/IFQ_DRV queue-only. 6. Behavioral change to ieee80211_check_scan: default to IEEE80211_SCAN_NOJOIN if we are not explicitly looking for a SSID 7. Behavioral change to ieee80211_ioctl_setmlme relating to wpa_supplicant behavior (see lengthy comment in the diff) The complete diff (minus ieee80211_haiku) can be found here: [2] (Disregard the stuff blacking out counter(9) usage -- the manpage for it said that it was non-atomic and had some specific behavior re. interrupts so I deferred looking into it, but it looks like that's an implementation detail; I'll probably implement it on our end as an atomic.) The patchset isn't too large, so even if none of these get merged, it's not really a huge burden on our end. The harder part is always the KPI changes that get made, as our compatibility layer makes a lot of assumptions about net80211 and driver behavior (e.g. the ieee80211com / IFQ_DRV removal took me quite a while and a good amount of assistance to figure out.) Anyway, thanks for the help so far, and thanks for a (mostly) portable net80211 stack! -waddlesplash [1]: https://www.haiku-os.org/ [2]: https://git.haiku-os.org/haiku/commit/?id=af8988cdb6664339b2958b32863554c70d2fe76f
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEesM77h45EcKPBN4h7REhG==d=3CzVbjyVj6wKTzrD-dw_MiA>