gc>
gc> Linux does the same thing (driver is configured by application code)
gc> although there does not yet exist a single app
gc> that can serve as a common point of control for multiple vendor drivers.
gc> I believe that achieving that goal is the real payoff for wireless Linux
gc> users.
I would not fully agree here: for timing reasons, you can do scanning/AP
selection in user space, but for rate scaling, if we ever can do it generic,
you better be in kernel.
From architecture point of view, MLME should be stack, not user app. For me,
management packets generation is same kind of activity as arp.
gc>
gc> > It is simply waste of resources.
gc> >
gc> > To make step forward, I suggest the following:
gc> >
gc> > 1. Dave's code is at least year old. someone need to start maintain it,
gc> > starting with update for current kernel infrastructure. Get it compile
and gc> > load for 2.6.9, for example.
gc> >
gc> > 2. To debug stack, you don't need real driver. I can write dummy .11
driver gc> > that will silently discard all Tx, and will provide some way
for user level gc> > tool to simulate Rx (ioctl, netlink, does not really
matter). For logic, it gc> > is sufficient. Later, when it will come to
timing, performance etc, it will gc> > be easy to strip some real driver.
gc> >
gc> > This may be king of "proof of concept".
gc>
gc> Yes, for logic it is sufficient.
gc> My personal approach would be to test the theory by examining
gc> what fits or doesn't fit into David's API if I were to port one of the
gc> MLME implementations that I work with. Discover if it fits or not.
Sounds promising. Don't forget to share you findings.
pgpFqwmMXI77j.pgp
Description: PGP signature
|