All,
We've been discussing different kinds of devices with Inaky and others
(offline). Here I'd like to summarize/continue our discussion so that it's
available to everyone.
To start with, two kinds of user devices exist so far: NAP and NSP. Here is
some definition (by Inaky):
Connectivity provider: VNO (virtual network operator)
A VNO runs on one or more NSPs
(for example, MyCompany could provide connectivity using Yota's
network in Russia, Clearwire in the US under the same credential).
network: one or more NSP networks
NSP: provide connectivity, serviced by different NAPS
NAPs: set of basestations (NAPs) with the same operator ID.
So a NAP (basestation) belongs to some guy who provides access to a
number of NSPs (connectivity providers). The NSPs resell the service to
the Network Operators. Of course, the VNO, NSP and NAP could all be the
same entity.
So the basic interface for all is the same:
- NAP: connect / disconnect, scan for NAPs
- NSP: connect / disconnect, scan for NSPs
-----------------------
The proposed architecture for wimax stack is as follows:
Conn Manager
|
wimax dbus API
|
/-------------\
| |
NSP-to-NAP |
mapping |
-------|-------------|---- user/kernel interface
NAP inteface |
| NSP interface
| |
-------|-------------|---- wimax stack / wimax driver
driver A |
backend for |
NAP interface |
driver B
backend for
NSP interface
The idea is that every component other than a driver will be common for all
devices. (However I have a question here: how do we handle private message
exchange (op-msg) between a driver and a user-space component given a
user-space component is common.)
-----------------------
There is an open (minor) question on how to handle firmware updates. Since
different devices require totally different update-procedure it looks
non-trivial to come up with some kind of an abstraction layer.
-----------------------
While a NAP interface is almost defined and coded, the NSP interface is not yet
defined. No official information from any vendor is available yet to clearly
define this interface. Does anyone have such information?
-----------------------
I have quickly reviewed an op_nap_scan branch (the development of NAP interface
API is going there). Is there a user-space component available which works with
this version of WiMax stack? I'd like to try to look deeper into it.
-----------------------
There also was some discussion with Dan W. I'd also like to share this for
everyone's information:
[Oleg] In addition to this there is a port of the madwimax project to the
kernel space.
(http://git.altlinux.org/people/silicium/packages/kernel-source-u200.git). Note
that they create an interface with wireless extension and it can be managed by
iwconfig and other tools.
[Dan] Using wireless-extensions is EVIL. We're trying as hard as we can to
kill it because it's a horrible API and completely non-extendable. This was
the main reason why Inaky and the Intel guys created the netlink-based API for
WiMAX.
It would be good to get everyone using the same API, then we dont' have
to update every connection manager every time a new chip comes out or
the firmware interface changes. That's the whole point of abstraction.
>From my perspective (I work on NetworkManager), I don't really want to
write a new shim layer for every new wimax part that gets released. I
want the driver to provide a common interface (or, really, have the
Wimax Network Service provide the common D-Bus interface) and then have
NetworkManager talk the same protocol/API to every card.
[Oleg] Have you looked at the Device Kit
(http://www.freedesktop.org/wiki/Software/DeviceKit)? It looks to me like
user-space daemon can become a part of it.
[Dan] Forget DeviceKit; just use udev. DeviceKit is only a thin D-Bus shim
around udev anyway, so most uses should just integrate with udev
directly. There are various convenience libraries (gudev, which is part
of the udev sources in v143 and later) that make using udev's API much
easier from programs themselves.
[Oleg] Why are user-space drivers bad?
[Dan] Again though, we shouldn't be writing userspace drivers really, because
they simply don't integrate the right way: they don't have the right
sysfs integration, so all the normal tools won't be able to do hardware
detection and inspection, and they won't be able to use the normal
kernel rfkill subsystem, and they won't be able to use the normal WiMAX
kernel APIs. Basically, it creates more problems than its worth.
Thanks,
Oleg Yakovenko
Software Engineer, Yota
_______________________________________________
wimax mailing list
[email protected]
http://lists.linuxwimax.org/listinfo/wimax
