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.
