... as the OG author of this thread I should say I /did/ drop in a memory upgrade into my Atari 1040STF. :-) I should write a blog post about that too if I haven't already.
yup, the community is really coming together over this. I'm shocked and happily surprised. :-)
There are gary / buster drop-ins now too. Super Buster has been talked about for Zorro-III, but yeah, the AGA and A3000 glue logic stuff hasn't yet been dropped in.
that's why the later OS releases after amiga/commodore imploded extended some of the memory APIs to say "This needs to be globally visible". That way you'd allocate message memory in globally accessible memory and the MMU could do "things".
(Not that I'm a fan of that solution, just saying, they had to hack around it.)
11ac adds to 11n. you have new channel widths, instead of just 20 and 40. It's 20, 40, 80, 80+80, 160.
You have MCS0->9, and then you have 1->n spatial streams. It's like 11n, but they didn't make the MCS numbers just keep going up above MCS15, MCS23, etc. Negotiation is easier - you have to do MCS0..7, then you can say whether you also do 8 and 9.
Everything is block-acked when you negotatiate it - even individual frames. It still negotiates AMPDU and AMSDU like 11n, but then everything is BA'ed versus 11n where some frames are and some frames aren't. The 11ac AMPDU is almost the same as 11n, but it adjusts the maximum AMPDU sizes to be much bigger.
It's still MIMO, and you can implement multi-user MIMO when you're ready. You don't have to out of the gate. This makes it easier to do basic 11ac bringup before you have to do more useful optional bits. There are some extra IEs to handle in beacons, probe request/resp, etc, which isn't all that scary.
The trouble(!) is it kinda forces one to tidy up their 11n codebase first. The way we represent channels in net80211, for example. We have one channel for each PHY type and frequency - so, say channel 36. There's 36/a, 36/ht20, 36/ht40. For 1, it's 1/b, 1/g, 1/ht20, 1/ht40. For 11ac we're going to have to add say, 36/vht20, 36/vht40, 36/vht80. Now, 80+80 becomes painful because the other 80MHz slice can be anywhere and that's not easily represented without a massive explosion in the number of channels. So, how channels are fetched/accessed/etc needs to be changed.
There's also the situation where we currently support a "global" channel for a device, rather than one channel per vap, separate scanning state per VAP for full offload devices, etc. That has to change for full offload devices (iwn, iwm, ath10k, rsu, etc) which can do scans in firmware without the stack being involved.
Linux mac80211/cfg80211 solved this with the concept of "channel contexts" - they used to do exactly what we did in net80211 (one channel struct entry per PHY type + channel combo) but fixed it when 11ac came along. Every driver needed modification, so that's going to take some time to plan out and implement.
There's also some tidying up to do with notifying the upper layers about frames. Eg - NICs does AMSDU offload now in the 11ac world. AMSDU is multiple MSDUs in one frame - ie, multiple ethernet frames in a single 802.11 frame. So, you have to tag received frames with some information that states it's a de-cap'ed AMSDU frame with the sequence number, crypto info, etc of the single big 802.11 frame you received. This is problematic because the stack right now expects each frame to have its own sequence number, crypto IV, etc and does duplication detection. I just started committing some newer pieces to the net80211 RX path so we can handle cases like this when AMSDU offload happens - which is very soon now.
So yeah, it's "a few bits away", but since the four of us actively doing wifi stuff in FreeBSD are unpaid volunteers, things happen at the rate of spare time. If you're interested in learning about this stuff and aren't afraid of a C compiler than hit me up ([email protected]) and let's hack on this.
* ath(4)'s 11n support is much, much better now. All the AR93xx/AR95xx PCIe devices are supported and STA/AP 11n should work great.
* iwn(4)'s 11n is much, much better. It still has some warts, and I'd love some help in chasing them down.
* urtwn(4) in -HEAD does 11n now.
* rsu(4) in -HEAD does 11n now.
* iwm(4) (intel 7260, etc) is getting better every day in freebsd and dragonflybsd. Thanks to another developer for that !I think we're almost ready for starting the 11n bits? once the 11n bits are done and working, we can start on the 11ac bits.
* Another developer is working on urtwn/rtwn unification and support for 11ac USB devices from realtek.
* I'm working on an ath10k port from Linux to FreeBSD - I have association working now and I'm about to start on normal data TX. Once that's done, I'll get crypto and 11n station mode operation working.
now, where's 11ac? It's mostly waiting for some stable like 11ac devices to appear in the tree with 11n support. 11ac is partially revolution and partially evolution - if 11n doesn't work, 11ac definitely won't work. So, between iwm 11n work, the rtwn/urtwn 11n/11ac USB work going on and my ath10k work, I think we're heading in the right direction.
I'm hoping that once I get ath10k up in monitor, STA and AP mode, with crypto, QoS and 11n working, the 11ac bits will be trivial - at which point I can start on the 11ac stack pieces. I know what those stack pieces are and I've started writing them down - https://wiki.freebsd.org/WiFi/80211ac .
All of this is non-commercial btw - no-one is sponsoring any work on BSD wireless at the present moment. If you'd like to help or contribute, please consider talking and donating to the FreeBSD foundation, or consider funding someone to help in these efforts.
Yeah I looked; it's the IPC from Mach with some shimmed bits to do VM-y things for mapped message passing.
Mach was mostly VM and IPC - so of course it looks like it's a lot of Mach code. But there's no separate mach kernel running - it's just the IPC instances and they only exist as FD bits. It's not a complete kernel and FreeBSD isn't running "on" mach.
https://github.com/ingwarsw/tinyfugue
-adrian / erikarn