dillon at apollo.backplane.com
Fri Nov 5 10:34:03 PST 2004
:Damien Bergamini has released a new version of his ipw(4) driver for Intel
:PRO/Wireless 2100 cards. This release solves the lockups that occured in
:combination with ACPI C3 sleep state. A DragonFly version can be downloaded
:It works great for me and Damien asked, whether it could be included into the
:DragonFly source tree. I think the following things need a look from a more
:experienced DragonFly developer:
As Joerg expressed the interest he's the lead on this. Joerg: I think
the lack of an ability to include the firmware is not a big deal, we
can still bring the code into the tree with it looks like only minor
modifications to reintegrate the FreeBSD-style modules/ Makefiles into
our style, but it does mean that we can't hook it into the build.
:- I just replaced mutex locks/unlocks with s = splimp() / splx(s) calls as
: Joerg Sonnenberger suggested. For performance reasons this might
: need some changes.
Probably good enough for now. Eventually all the drivers will need to
be made MP safe but it hasn't been a priority. They are all in the same
boat right now.
:- There are some malloc() calls with M_NOWAIT. I am not sure, if this is ok.
I did a quick pass through the code and it looks like all the malloc()'s
are in the initialization pass, which means they have to all be changed
In DragonFly, M_NOWAIT really does mean that the malloc can fail and
return NULL if it would block, and it actually does happen to be the case
(esp on SMP systems).
:- I ifdef'ed out calls to bpfattach2() and similar as I did not find the
: corresponding functions in the DragonFly tree.
:- The license is a little shorter than the one found in e.g. if_wi.c.
Looks fine. It seems to be a 2-clause BSD license.
:- For the driver to work, some external firmware from INTEL is needed, that has
: licensing issues. Damien is trying to resolve this problem. But as the
: firmware is not compiled into the kernel module this is not that much of
: an issue, I think.
Not a show stopper with regards to getting it into the tree, but it
does mean we can't hook it up to the build (i.e. to build automatically
for GENERIC or as a module), though perhaps we can conditionalize it
with a make.conf variable while the Intel issue is worked out.
:Please let me know, what I can do to work towards an inclusion into the
If no action is taken in the next ~month (Joerg being a busy person and
all), please email a reminder and I will bring it in.
<dillon at xxxxxxxxxxxxx>
More information about the Submit