On Mon, 27 Sep 2010 17:49:14 -0500 "d.w. harks" <dave at dwink.net> wrote: > With rapier wit and elegant prose, Inaky Perez-Gonzalez wrote: > > On Tue, 2010-09-28 at 06:30 +0900, Stephen Hemminger wrote: > > > On Mon, 27 Sep 2010 10:47:37 -0700 > > > Inaky Perez-Gonzalez <inaky at linux.intel.com> wrote: > > > > > > > Hi Stephen > > > > > > > > > > > > > The driver is a mess, I have a long list of changes that need to be done, > > > > > the biggest is that the user space and API model are a mess. It really needs > > > > > to be completely rewritten. > > > > > > > > Could you do a write up of what is the API model? Additions will be > > > > needed to the minimal stack that there is now and I'd like to start > > > > thinking about them. > > > > > > > > Thanks! > > > > > > > > > > The existing code uses a single character device. Read/write are > > > control packets, and it has a long list of ioctl's to do things like > > > check link status etc. They also have a binary format configuration > > > file that is read in like firmware at the startup. Much of the configuration > > > can probably be eliminated and the rest can either be done as module > > > parameters or config fs. > > > > Ugly, very > > > > So this is probably an HCI for driving the scanning and connection > > process. It'd be interesting to find at which level the device operates, > > if at the NSP level (like the current Intel devices) -- aka, deals > > directly with base stations and then system software has to map that to > > NAPs (access providers) or if it deals directly with the concept of > > NAPs. > > > > Eventually we need to add a NAP interface to the WiMAX kernel stack so > > that low level system software only has to scan for NAPs and connect to > > them and deal with authentication parameters, so if we can find out how > > beceem does it, it'll drive feedback in the design so it works for all. > > From what I can tell it's running at the NAP level. When you initiate a > network search, you get back a list of base stations by BSID & > frequency, and the reference Connection Manager configuration Sprint > provides literally gives a list of frequencies to search. > > There is a userspace shared library which implements the interactions with the > character device Stephen mentions, providing the WiMAX Common API. > > CLEAR has an 'open source connection manager' which is built in Java and > uses JNA to wrap (theoretically) any library which implements the Common > API. This has a database of (what I understand to be) NSPs (CLEAR and > XOHM are represented). ( http://developer.clear.com/projects/list_files/open-src-conn-mgr/ ) > The kernel-user interaction is also very busy/noisy, so it probably consumes lots of power.
