[lkml]   [2006]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectwireless: the contenders
    First, the news everyone will like.  Thanks to the team
    I now have a place to publish a wireless tree:


    The tree there has a number of branches, so many that you need
    a scorecard...


    The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
    changes I recently sent to Jeff. Those changes are also available on
    the "upstream-jgarzik" branch, but it is frozen to when I requested
    Jeff's pull.

    The tree also has "softmac" and "dscape" branches. The "softmac"
    branch includes the Johannes Berg softmac code as well as the the
    BCM43xx driver based upon that code. The "dscape" branch includes
    the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
    ported to the DeviceScape stack.

    The fact that the BCM43xx team has ported their driver to both stacks
    provides us an excellent opportunity for some objective, "apples to
    apples" comparisons between the major stacks. I would like to take
    this opportunity to thank them for taking the trouble to do that work
    and to make both versions available for comparison.

    BTW, those trying to actually use the dscape code will want to poke
    around Jiri's directories:

    Jiri has some information there that will likely be useful to you.

    The other branches are for administrative purposes, and can mostly
    be ignored.


    Along with bugfixes and enhancements to the current code (which will
    be targeting the "master" branch), I would like to see driver and
    stack patches for both the "softmac" and "dscape" branches. I would
    like to see what is really out there before making a final call on
    which stack to adopt permanently.

    If you have an out-of-tree driver which targets either (or both)
    stacks, please send patches. If you are working on porting an
    in-kernel driver to one of these stacks (either from the other stack
    or from its private stack), please send patches. If you have fixes
    or enhancements pending for either of these stacks, then please
    send patches.

    Don't waste any time with your patches. There is good reason to make
    a decision quickly, and plenty of pressure to do so. Your code could
    be a significant factor in making that decision.

    I know that many of you believe that this approach is a bad idea,
    for a variety of reasons. I find those arguments valid, and
    even persuasive. The point of this exercise is NOT to push two
    stacks forward into Linus' kernel. The point is to catalog the
    true state of affairs and to collect as large a wireless driver
    codebase as possible. You might think of this as a Domesday Book
    ( for Linux wireless.


    Hopefully the act of collecting these patches will also allow the less
    motivated among us to have a chance to evaluate the stacks involved.
    There are bound to be some wise and skilled kernel hackers out there
    that are just a little too busy to track-down all these patches
    themselves... :-)

    I appreciate all the commentary and ideas expressed over the past
    couple of weeks. I also think the driver writers are doing a good
    job with what they've been given so far. I hope this helps to bring
    the driver guys in out of the cold, and to put some weight behind
    the discussions of where we need to go.


    John W. Linville
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-18 21:09    [W:0.022 / U:58.120 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site