>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) - do WiMAX NSP scan (given a channel and NAP id, returns NSP id list, verbose name list, change count) - do connect (given a channel and NAP id) - do disconnect - get serving BS info (returns channel info and BS id of the serving BS) - get NSP realm (returns the NSP realm string) - get neighbor list (returns list of current advertised neighbor basestations, channel and BS id) - get last error (returns code indicating last error) - 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) 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. >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. -Juuso
