:Hi,
:
:The problem is "dfbsd should port over the ath driver." ;-)
:
:The actual cause is likely radio related - the AR9285 code that Rui
:initially ported over was based on what was in ath9k and it was
:suitably unfinished. (So it's not Rui's fault, he did a great job with
:what he had.) I subsequently found/fixed/ported a bunch of stuff with
:an ath9k developer as we *ahem* discovered the ath9k support was
:incomplete.
:
:In fact, if the dragonfly bsd guys were interested, I could have my
:arm twisted into forking off a "shared" project where we have a shared
:ath driver and HAL, and pull it into *BSD as a contrib project.
:
:That way I'd only have to fix bugs once (hah), and everyone could
:immediately benefit from it.
:
:What do you all think? You'd (mostly) get 802.11n for free. :-)
:
:Adrian
I'd say we're definitely interested, but I don't know how easy it would
be to maintain a common infrastructure. I have to say honestly that it
might not be worth maintaining a common infrastructure for the driver.
DragonFly's network subsystem differs hugely from FreeBSD's and the
wireless infrastructure also has some major differences on top of that.
We're working with Rui's original port of the 802.11 infrastructure
to DragonFly, plus various hacks we added afterwords to stabilize it.
The major differences relative to his port are related to the fact
that the WLAN pseudo-interfaces and the ATH (and other) physical
interfaces used different locks, but were able to call each other
recursively via the 802.11 framework. This led to the drivers doing
crazy unlock/relock sequences and STILL hitting deadlocks in some cases.
But even with the unlock/relock sequences that left the driver open
to reentrancy issues which we were constantly hitting.
So in our network infrastructure I basically gave up on the 802_11
psuedo-vs-phy locking issue and I have a single global serializer
that covers the *entire* wireless infrastructure on the system...
all pseudo-interfaces and all physical interfaces use the same
serializer.
--
In our normal network subsystem there are also major differences.
We have an ifnet serializer that is installed on a per-driver basis
(but as per above, for the wireless physical interfaces we just specify
a single global serializer), but the system infrastructure is
responsible for acquiring the serializer (our version of the driver
locks) rather than the drivers having to code them up for each entry
point, which greatly simplifies driver design). Even the fan-in/fan-out
locking for multiple rx/tx queues is handled by the higher level
system for the most part, for things like IF_EMX.
We also have to always change all the M_NOWAIT allocations in FreeBSD
drivers that appear to be used for everything, including small one-time
critical driver structures, to M_INTWAIT in DragonFly. I guess M_NOWAIT
in FreeBSD doesn't actually ever return NULL, but in DragonFly it can
return NULL in virtually any situation (such as if a lock cannot be
acquired non-blocking).
Plus some (mostly) minor changes to numerous other things... differences
in how BUSDMA works, for example. Other issues such as DragonFly not
overloading the stdio namespace so kernel printfs in dragonfly are
'kprintf()' not 'printf()', and allocations are 'kmalloc()' rather
than 'malloc', and so forth.
--
Sorry, don't mean to discourage you. I'd really love there to be an
easier way to synchronize driver code too.
-Matt
