On Thursday 04 December 2008, juuso.oikarinen@xxxxxxxxx wrote: > >From: ext Inaky Perez-Gonzalez [mailto:inaky@xxxxxxxxxxxxxxx] > >Sent: 4. joulukuuta 2008 21:33 > > > >> I agree with you. The best solution would be a fusion. A netlink > >> message based interface with the abstract WiMAX operations (with > >> interface abstraction at the level used in the Nokia driver) > > > >would be > > > >> the way to start defining a uniform WiMAX driver interface for Linux. > > > >Well, no ioctl is the way, it has to be netlink. > > > >What set of calls/signals do you propose that should be in the > >kernel interface? > > Our current set, from a very high level point of view, the current WE > header: > > - do WiMAX NAP scan (given a list of channels, returns found channels > with NAP id, RSSI, CINR) Yep. I am assuming you mean extract the NAPid from the base station addresses right? > - do WiMAX NSP scan (given a channel and NAP id, returns NSP id list, > verbose name list, change count) Unless the hw provides the facility, this should be done at user space The NSP <-> NAP mapping requires provisioning/networkin knowledge information. So this would build on top of kernel-based NAP scanning. > - do connect (given a channel and NAP id) > - do disconnect > - get serving BS info (returns channel info and BS id of the serving BS) What do you mean with 'serving'? > - get NSP realm (returns the NSP realm string) This is another case of needing NSP/NAP mapping, based on what the hw supports will have to be done in user space or kernel space. > - get neighbor list (returns list of current advertised neighbor > basestations, channel and BS id) What do you need this for? Handover? > - get last error (returns code indicating last error) Why? Each operation, when it fails should return an error; relying on an extra op to get you the last error opens a lot of windows for race conditions. > - set EAP result (used to indicate whether EAP failed or alternatively > specify the MSK to the driver) > - set config (used to configure things like idle timeout, idle paging > timeout, etc) This is also very HW specific; the intel hw has it, but others might not. > Wireless events are used to notify the client of events. Obviously, > they're used with things like connect to indicate completion, scan to > indicate available results and completion, etc, but there are some > special events too: > > - "realm available" the realm becomes available during the connect > procedure, this indicates that it can now be retrieved > - "bs info available" info on which BS the device is going to connect to > becomes available during the connect procedure, this indicates that it > can now be retrieved > - "ip renew" it is possible, that due to handovers, the DHCP renew needs > to be executed although the connection never went down and lease never > expired, this is to indicate that > - "neighbor update" indicates there were changes in neighbor bs > information > > There are lots of parameters affecting detailed behavior. I would be > happy to provide a more detailed design, with sequence charts, for this > interface. I would be happy to write a template for message structures > too if there's interest. There is -- keep in mind, however, that for the case of the i2400m, the kernel cutline has to be at the NAP level. All the NSP operations will have to be implemented in user space using the NAP-based primitives offered by the driver/hw. > >I really don't want to set this on stone until there is at > >least a second vendor coming in, but that doesn't mean we can > >start thinking about it. > > > >BTW, where can we find your user space code? > > This is not as simple as I might hope :( Although open source EAP stacks > exist, Nokia is currently using a proprietary one, and its sources are > not available. The daemon component (called "wimaxd") is open source, > but is currently not available, but there is work ongoing to make it so. > It will be in the same repository as the kernel sources. > > To be truthful, however, the network selection logic (and OMA DM) is > proprietary, and most likely will be for some time in the future. These > are considered "differentiating" features. Well, that's a problem. Without that, we are dead on the water. This is the most important chunk of code once you want to do real use of WiMAX outside of a lab. We have the network-service tarball, which implements that part and we are shaping it out, but it takes time. For now it works. Baby steps :) -- Inaky
