tag:blogger.com,1999:blog-4361733293216582854.post661168566901697910..comments2024-01-24T23:36:45.356-08:00Comments on Adrian Chadd's Ramblings: I'm back into the grind of FreeBSD's wireless stack and 802.11acAdrianhttp://www.blogger.com/profile/17496219706861321916noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-4361733293216582854.post-66315263905674672232020-08-25T23:16:43.786-07:002020-08-25T23:16:43.786-07:00You had a comment in the wiki on whitespace cards ...You had a comment in the wiki on whitespace cards tuning at 500kHz for the center freq and the necessity to convert that to a structure. If a structure is being built would it be handy to have a static map definition which ties a channel ID to it's: starting frequency, center freq resolution, channel width, and a bitmap of indices which are active in each a given regulatory domain? Thinking this should be outside of net80211 as there could be correlation as the frequency use, channel selection, etc could be shared between 802.11, 802.15, 802.16, etc. One could even argue wired interfaces with CWDM/DWDM/TDM interfaces the PHY's channel attributes could be stored in similar structures.<br /><br />I've always felt like the physical "configuration" items were oddly outside of the scope of operating system's driver implementations and tend to get done differently for each driver. We have sockets, which sit on if_wlan or if_ethernet and may have firmware to control the necessary bits, but then we pack all of the L1 function into the net80211 implementation and require separate per manufacturer implementations with lots of rewrite. I'm just feeling like there might be opportunity to improve future development performance by leveraging common structures.<br /><br />I am by no means an expert... just a fan with a question on your thoughts.xkhttps://www.blogger.com/profile/05889212960761838838noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-56636544754868942712020-07-19T21:22:27.613-07:002020-07-19T21:22:27.613-07:00why make an effort to improve FreeBSD, vs linux, v...why make an effort to improve FreeBSD, vs linux, vs dfly, vs netBSD? Why have you decided that FreeBSD is the fork to follow?<br />I've been struggling with deciding which way to to focus my efforts. Why FreeBSD? DragonflyBSD has a lot of features that seem to address your linux-y considerations?<br /><br />Please keep going, and Thanks :-)Anonymoushttps://www.blogger.com/profile/16870924437425341383noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-33748854885936133362020-07-18T09:08:39.777-07:002020-07-18T09:08:39.777-07:00I replied to someone else here who asked - there&#...I replied to someone else here who asked - there's a wiki page on the freebsd wifi stack that we're trying to get into better shape with a todo list. But you should just grab freebsd-head, grab a supported wifi device and try using it! Find what's not quite right and let's fix it!Adrianhttps://www.blogger.com/profile/17496219706861321916noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-46970949063427163542020-07-18T09:07:56.315-07:002020-07-18T09:07:56.315-07:00Thankyou!Thankyou!Adrianhttps://www.blogger.com/profile/17496219706861321916noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-85222347537189840232020-07-18T09:07:40.078-07:002020-07-18T09:07:40.078-07:00Thanks!Thanks!Adrianhttps://www.blogger.com/profile/17496219706861321916noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-54412144129564955992020-07-18T09:07:32.900-07:002020-07-18T09:07:32.900-07:00hi! We have a list of things in our wiki - https:/...hi! We have a list of things in our wiki - https://wiki.freebsd.org/WiFi - there's a todo section that I'm trying to sort into more useful tasks.<br /><br />But basically - grab something that's supported and try to make it better. :-)Adrianhttps://www.blogger.com/profile/17496219706861321916noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-20210135486871777432020-07-18T09:06:48.792-07:002020-07-18T09:06:48.792-07:00So there are a couple of areas.
first up - the nl...So there are a couple of areas.<br /><br />first up - the nl80211/mac80211 bits are just different than the ye olde net80211/madwifi layout. mac80211 has a lot more stuff pushed into a deferred path, like crypto key management - but net80211 doesn't. it makes writing stuff for firmware nics hard.<br /><br />next up is the structure of locking and wakeups. on linux, you can grab a lock and disable your software irq at the same time - ensuring that you're not going to contend locks with the irq path. FreeBSD doesn't do this (outside of linuxkpi); so you end up with a bunch of lock contention that kills performance. It means you can't "just" port a Linux driver to BSD and hope the performance is the same; you need to sit down and make sure the locking is efficient.<br /><br />Next - the tasklet abstraction. On freebsd (again outside of linuxkpi) waking up a tasklet wakes it up on the same CPU you're currently on, so you know it won't be scheduled to run until after you finish your current work. On FreeBSD a taskqueue can run on any CPU by default, so if you schedule a taskqueue entry it'll immediately run if there's a free CPU. This can also lead to fun lock contention and also there's some cases where you need to add/modify locking.<br /><br />Then there's the increasing use of the lock-free algorithms which require that not only you try to do the same thing, but all the consumers do the same thing. mac80211 makes a lot of use of their lock-free bits, and net80211/freebsd doesn't. they kinda have to line up or you end up with behavioural differences that can be difficult to debug.<br /><br />I can keep going.. :-)<br />Adrianhttps://www.blogger.com/profile/17496219706861321916noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-45269321761745986292020-07-17T07:22:09.636-07:002020-07-17T07:22:09.636-07:00Could you explain Linux-y code by example?Could you explain Linux-y code by example?Anonymoushttps://www.blogger.com/profile/16870924437425341383noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-5734865593005993712020-07-16T21:50:42.405-07:002020-07-16T21:50:42.405-07:00This seems really interesting and I'd like to ...This seems really interesting and I'd like to help! Please let me know how to get startedsurbhithttps://www.blogger.com/profile/15789139567655407382noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-13034587683133872432020-07-16T10:48:45.853-07:002020-07-16T10:48:45.853-07:00Just wanted to give you words of encouragement! Th...Just wanted to give you words of encouragement! Thanks for all the hard work you do to make open source firmware awesome. I recently delved deeper into some firmware code and realized just how much work it can be to get things to a semi working state.Jeff Tchanghttps://www.blogger.com/profile/16674769228742309517noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-86467752563162156452020-07-16T07:41:21.166-07:002020-07-16T07:41:21.166-07:00
I would like to help you out. Let me know where t...<br />I would like to help you out. Let me know where to start off.Emekahttps://www.blogger.com/profile/16813050192458088812noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-19432325399586542042020-07-16T03:50:20.163-07:002020-07-16T03:50:20.163-07:00Much, much thanks for the work you're putting ...Much, much thanks for the work you're putting into this. Unknownhttps://www.blogger.com/profile/18364943554920472728noreply@blogger.comtag:blogger.com,1999:blog-4361733293216582854.post-81628747207646637792020-07-15T23:07:06.623-07:002020-07-15T23:07:06.623-07:00Welcome back! I love your coding style !Welcome back! I love your coding style !neutronizationhttps://www.blogger.com/profile/13264271893072578209noreply@blogger.com