[WLANnews] [Fwd: [Madwifi-devel] Status of MadWifi, future plans and direction]

[Sven Wagner]

FYI

lg
	cven

-------- Original Message --------
Subject: [Madwifi-devel] Status of MadWifi, future plans and direction
Date: Thu, 14 Dec 2006 23:46:31 +0100
From: Michael Renzmann <madwifi at nospam.otaku42.de>
To: madwifi-users at lists.sourceforge.net
CC: madwifi-devel at lists.sourceforge.net

Hi all.

The recently added new branches (such as dadwifi, dadwifi-openhal or
madwifi-old-openhal) seem to have caused some confusion. In addition,
some people wonder about what the general plans for MadWifi look like,
so I think it's a good idea to sched some light on this topic.


A short look back
=================
It seems to be some kind of tradition to start such mails with a look
back on the past months. Even more if they are sent at the end of a
year. So don't let's break with this tradition ;)

2006 was the year when we brought our first three-and-a-half releases
out of the door - following the statistics at sf.net there were a total
of 131.932 release tarball downloads so far. madwifi.org served an
additional amount of 122.357 snapshot tarballs downloads up to now, plus
an uncounted number of checkouts directly from the repository. Even
spammers started to love MadWifi (or at least our website): since August
a total of 76521 spam postings were blocked from being posted.

Otherwise said: we managed to increase interest in the driver, from end
users as well as from developers.


MadWifi and the kernel
======================
The one goal that influences current MadWifi development the most is the
plan to get it included into the mainline kernel. This, however, is far
more complicated as it may sound. Various discussions have shown that
there are some major objections. The two most criticized attributes of
MadWifi are:

   1. The binary-only HAL. It's been made clear that MadWifi won't be
accepted for kernel inclusion as long as it depends on the
closed-source, binary-only HAL.

   2. The net80211 stack. The stack was originally written for some BSD
flavours, and when reviewing existing 802.11 stacks some months ago,
decisions were against merging net80211 into the kernel.

Addressing these points will take a long time and requires a *lot* of
work. The 802.11 stack is an integral element of a wireless driver, and
switching from one stack to another is complicated. Devicescape's David
Kimdon has stepped up some weeks ago and started to port MadWifi to
their d80211 stack (which is about to be introduced into the kernel).

The "HAL issue" is a complicated one. Available replacements that would
meet the requirements of open source advocates are not yet as
feature-rich as the Atheros HAL, and they are also behind when it comes
to supporting the latest chipset generations. Switching to one of them
means we limit the functionality of the driver (at least for a while),
which might be a problem for users.

On the other hand, chances are low that Atheros would be willing to open
the source of their HAL. The main point of keeping the HAL closed is to
comply with FCC requirements (see [1]). There recently have been voices
saying that the FCC is not as strict as Atheros believed them to be, and
they indicated that Atheros could be able to comply with the FCC
requirements even if they release the HAL sources under a FOSS license.
This needs to be investigated. A strong legal background is required for
this task, which hopefully will be provided by the SFLC (Software
Freedom Law Center [2]).

The project is evaluating both paths; that is:

   * We support the effort of porting "OpenHAL" - which is based on the
Atheros driver from OpenBSD - to Linux and merging it with dadwifi. The
results are kept in the dadwifi-openhal branch for now, and will be
merged back into the dadwifi branch later, which in return will be
merged back to trunk at some time.

   * We will get in contact with the SFLC, asking them for help in
evaluating the actual FCC requirements. Albeit the expected low chances
of success and in the hope that this evaluation will strengthen our
position, we will try to convince Atheros to make the sources for their
HAL freely available.


madwifi.org - founding a not-for-profit organization
====================================================
Another of our current activities is the process of forming a non-profit
organization as a legal background for the project. The motivation for
this step is roughly outlined on [3]. We are currently talking with the
Software Freedom Conservancy (SFC, [4]), which is a project of the
aforementioned SFLC and acts as an umbrella non-profit. They provide an
easy way to benefit from the status of a non-profit organization without
requiring its members to take care of the involved paper work.

There are some details left that need to be discussed, but the SFC
generally seems to be willing to accept MadWifi as a member. I think a
SFC membership might be of help for our consultation of the SFLC
regarding the FCC requirements (see above).


New iron
========
You might remember that around May this year Netgate donated a server to
the project. The plan was and still is to move madwifi.org to this new
server for better performance and greater flexibility.

Although the server is up and running, the actual move requires by far
more work than I originally thought. For example, I want to switch to a
more current version of Trac (that's the stuff that runs the madwifi.org
website with its wiki, ticket engine and so on), which in return
requires updates to some custom modifications I've set up on
madwifi.org. Then there are various ideas I have in mind for improving
the website as such, which require additional Trac plugins. The
necessary testing is easier on a non-live server, of course. And so on,
and so on.

Anyway, my current plan is to finish the actual move of madwifi.org to
the new server in the first quarter of 2007, ideally in February. At
least when everything works out as expected, that is :)

Long-waiting stuff such as coming up with a solution for mirroring the
madwifi.org is also still on my to-do list.


Making good things better
=========================
Quality assurance and improvement is the last section I'd like to
mention here. This is partially related to "getting MadWifi into the
kernel", since drivers that are to be included will receive an extensive
and critical review by the kernel maintainers. But increasing the code
quality and usability of the driver is generally a desirable task.

Some of the existing ideas are:

   * Moving the users guide into the wiki. This will make it easier to
maintain and improve it, and with some of the features of the Trac setup
on the new server we will still be able to provide the guide as a
consistent PDF, for example.

   * I'd love to see the users guide being extended, incorporating some of
the recipes and howtos that have been contributes by users in the "User
Documentation" section of the wiki. Something like the "Subversion book"
[5] would be awesome (and a lot of work).

   * Improving the existing documentation. For example, the wiki mentioned
madwifi-old in different places. Since madwifi-old is deprecated, we
should remove such references and, while being at it, streamline the
documentation.

   * There is room for improvement in reporting error messages and
explaining the actual cause of the message, along with a more in-detail
troubleshooting guide (which could become part of the users
guide/madwifi book) based on the troubleshooting information we already
have.

   * Reduce dependancy on wlanconfig as much as possible and increasing
compatibility with the wireless tools. Things such as "allowing to
change the operation mode of a VAP with wireless tools rather than
requiring the VAP to be destroyed and recreated in the desired mode"
come to my mind, for example. However, this needs some further
evaluation, since not every functionality of wlanconfig can be achieved
with the wireless tools.

   * The source code quality needs to be improved. For example, there are
a lot of places where pointers are dereferenced without asserting that
they are not NULL. Locking issues is another subject requiring
attention, although mentor already spent some time on that. And I guess
it wouldn't hurt to subject the code to a general security audit.

   * Automated build tests, in order to discover potential problems in
recent commits earlier. My current plan is to get an initial setup done
for such a testing environment in Q1/2007. Later I want to extend that
to a small test setup with a few WLAN-capable hosts which allows to
perform predefined tests procedures.


Bottom line
===========
I hope I succeeded in answering some of the questions that are out there
and was able to give a prospect of the near future. Please feel free to
ask if you think that I left out an interesting part.

The plans I've sketched above are not carved in stone. We are always
open for suggestions. The same goes for any other contribution to the
project - as you can see there is a lot of work waiting to be done, and
every help is highly appreciated.

On behalf of the MadWifi team I wish everyone merry christmas for you
and your family, and have a start into a happy new year!

Bye, Mike

[1] http://madwifi.org/wiki/HAL
[2] http://www.softwarefreedom.org/
[3] http://madwifi.org/wiki/non-profit
[4] http://conservancy.softwarefreedom.org/
[5] http://svnbook.org


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Madwifi-devel mailing list
Madwifi-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-devel


-- 
 >>>sync.ports<<<
https://cven.crew.c-base.org
cven[at]c-base[dot]org
clash at jabber.berlin.ccc.de
skype_id: cven42