lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectState of the Union: Wireless


    State of the Union - Wireless
    January 5, 2006


    Another banner year has passed, with Linux once again proving
    its superiority in the area of crappy wireless (WiFi) support.
    Linux oldsters love the current state of wireless, because it hearkens
    back to the heady days of Yuri Gagarin, Sputnik and Linux kernel 0.99,
    when getting hardware to work under Linux required either engineering
    knowledge or luck (or both).

    Linux has made remarkable progress in the area of hardware support,
    in the past five years, reaching a state where it is unusual for
    mainstream hardware to -not- be supported by Linux as soon as it
    is released. Unfortunately, this does not extend to wireless.

    Wireless drivers today are scattered to the four winds: many
    are in-tree, but for older hardware, and lack active maintainers.
    They work. A few drivers exist for "relatively" modern WiFi hardware
    in-tree; they work, but they don't have active maintainers either.
    Current hardware, many of it "softmac", is driven by a wild variety of
    drivers, for a wide variety of wireless stacks, none of them in-tree.
    Or, the in-tree drivers are simply out of date versions of actively
    maintained out-of-tree drivers. In one or two cases, users have turned
    to awful emulation solutions like NdisWrapper. But can you blame them?
    They just want their hardware to work.

    Twelve months ago, the community consensus was that the best basis for
    a wireless stack was HostAP, or as it turned out, a HostAP derivative
    whose sole users are the Intel ipw drivers. So that got merged.
    Now, twelve months later, fashion has changed, ieee80211 lost a lot of
    momentum, and it seems that the DeviceScape wireless stack is all the
    rage, and there are convincing arguments for merging the DeviceScape
    code floating about.

    But you -- I'm talking to all you wireless kernel hackers -- need to
    come up with some solutions for some key issues:

    * We really have no wireless maintainer. I'm just the defacto guy,
    with no interest in the job. The ideal maintainer knows 802.11 well,
    uses git, and isn't an asshole with no taste. I'm just the guy who
    wants to make sure the net driver portion doesn't turn out to be a
    stinker (read: review and pass up the chain).

    * Once you pick your favorite stack, STICK WITH IT. In Linux, there
    is collectively very little patience with a rewrite every 12 months,
    particularly one that is dropped in out of the blue rather then
    evolved out of existing code.

    In Linux, today's wireless code will probably live at least 10 years,
    if not more. Long term maintainability is paramount. This is
    why we prefer to evolve code, rather than constantly rewrite it.
    Rewrites are often improvements, but bring in their own wave of
    bugs and incompatibilities, while eliminating years of carefully
    culminated knowledge buried in the existing code. As a solution,
    pragmatic users wind up running both the pre-rewrite code and the
    new code -- duplicate code. Code duplication in turn brings in its
    own wave of bugs, and assaults on open source's economies of scale.

    * Wireless drivers and the wireless stack need to be maintained IN-TREE
    as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now.

    The whole point of working in-tree, the whole point of this open source
    thing is that everybody works on the same code, and the entire Internet
    is your test bed. Quality improves the more people work together.
    The entire Linux kernel engineering process is focused on getting core
    kernel code out to distributions (then to end users) and power users.
    Out-of-tree code breaks that model, breaking the It Just Works(tm)
    theme applicable to other Linux-supported hardware.

    * Release early, release often. Pushing from an external repository to
    the official kernel tree every few months creates more problems
    than it solves. Out-of-tree drivers fail to take advantage of
    recent kernel changes and coding practices, which leads to bugs and
    incompatibilities. Slow pushing leads to huge periodic updates,
    which are awful for debugging, testing, and general use.

    * Wireless management, in particular the wireless kernel<->user
    interface, needs some thinking. Wireless Extensions (WE) isn't
    cutting it, but I haven't seen any netlink work yet (or some
    other interface). Whatever the userspace interface is, it will be
    basically carved in stone for years (unlike kernel APIs), so this
    needs a lot more thought than people have been giving it.

    * ALL wireless stacks need work. It is currently fashionable to laud
    DeviceScape and trash in-kernel ieee80211, but outside of the
    cheerleading, BOTH have real technical issues that need addressing.
    IOW, no matter what code is chosen, _somebody_ is on the hook for
    a fair amount of work. A switch is not without its costs.

    * I would prefer that people patch the in-tree ieee80211 code,
    probably in the direction of Jiri Benc's proposed ieee80211_device
    direction. I take patches from all parties, not just Intel.

    * However, if the engineering reasons for switching to DeviceScape
    or another wireless stack are powerful enough to overcome Linux's
    "no big patches, evolve it" maxim, great! But make sure to work
    on converting drivers to this new stack. The wireless drivers and
    wireless stack should evolve in tandem. Otherwise, drivers get
    left behind, grow moldy, and Linux users suffer.

    * Feel free to submit radical changes -- wireless is yet young --
    just make sure all drivers keep working from release to release.

    * Long term, wireless should go from being a library of common code to a
    "real" wireless stack, as shown in the template developed by David Miller:
    http://kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2
    Zhu Yi @ Intel and Vladmir @ somewhere both independently did some
    work in this area.

    * Please CC wireless stack/driver discussions to netdev@vger.kernel.org
    mailing list, rather than everybody hiding in their own little
    corner.

    * I prefer GPL-only code. Dual licensing has proven in practice to
    be a logistical nightmare that concentrates power in the hands of
    a few. Dual licensing, BSD licensing works for some, but GPL-only
    code is quite simply the least amount of flamewars, headaches
    and worry. IOW, the P.I.T.A. level of GPL-only code is lowest.

    Open source is about not only merit, but lack of control. If I am
    being a knucklehead, or you just don't like me, you can always go
    through Andrew Morton, David Miller, Linus, ... With dual licensed
    code, engineers are really really really really encouraged to submit
    code through a single channel for legal rather than merit reasons.

    Dual licensed code gives kernel hackers yet more legal crapola to
    worry about, which is never a good thing.



    Patches welcome from all motivated, clueful parties. Jiri Benc has a
    long series of patches that looks nice. Johannes Berg has done some
    work on the ieee80211 softmac stuff and hw WEP. But maybe DeviceScape
    is what people like now.

    So... there it is. We suck. There's hope. No Luke Skywalker in sight.
    I hope we can avoid being slaves to fashion, by merging a rewrite, but
    that way be the way to go.

    Jeff



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-06 05:24    [W:0.030 / U:29.428 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site