Re: ipw(4) driver

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 
:at http://www.ecademix.com/JohannesHofmann/#ipw 
: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
    to M_WAITOK.

    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.

    -> Joerg.

:- 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.  

    -> Joerg.

:Please let me know, what I can do to work towards an inclusion into the
:source tree.
:
: Johannes

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>