extending WiMAX network service to other chipsets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2009-09-28 at 14:34 -0700, Inaky Perez-Gonzalez wrote:
> On Sun, 2009-09-27 at 02:49 -0500, Hoi-Ho Chan wrote:
> > Hi all,
> > 
> >     I wonder if how much effort would it be to extend the current
> > WiMAX network service and APIs to support another chipset in which the
> > message structures and protocols and totally different? Are the
> > various Agents (NDnS, Supplicant, etc) use a chipset-agnostic message
> > or it is specifically bound with the Intel-specific messages?
> 
> The network service is going to be a stretch, as it is very Intel
> specific (protocol, device format, program behavior). The high level
> functionality, is however, probably very similar to other devices.
> 
> Which kind of functionality are you looking at? Is the device you are
> thinking about implemented at the NAP level or the NSP level?

A while ago a number of us at Intel and Red Hat had collaborated on a
vendor-neutral D-Bus interface specification for the network service,
with the idea that the Intel NS would eventually get ported to use that
interface.  The specification is still around in the archives of the
mailing list, but nobody has had enough time yet to port the Intel NS as
a proof-of-concept.

That's still the best way to move forward and ensure that higher-level
software like connection managers can talk to any vendor's WiMAX
hardware and driver.  Otherwise, if we do not develop a standardized
interface specification, we risk having every vendor develop a different
driver interface for their hardware, and then every connection manager
would have to write a new backend for every vendor as well.  That's a
lot of work for everyone that can be avoided by standardizing on the
spec.

The idea was more or less like this:

.----------------------------------------.
|            Connection Manager          |
`--------.---------------------.---------'
        / \                   / \
         |                     |
      Standardized D-Bus Interface
         |                     |
        \ /                   \ /
.--------`-------.   .---------`---------.
|    Intel NS    |   | Other vendor's NS |
`--------.-------'   `---------.---------'
        / \                   / \
         |                     |
         |                     |    (userspace)
--------Standard Netlink Interface-------------
         |                     |      (kernel)
        \ /                   \ /
.--------`---------------------`---------.
|          Kernel WiMAX stack            |
|----------------------------------------|
|  Driver #1       |    Driver #2        |
`----------------------------------------'

Obviously, making the Intel NS (or some successor support as many
devices as possible is the *best* course of action (since there's one
place to concentrate fixes and features instead of many), but failing
that, the D-Bus specification made it possible for more than one
vendor's NS to work seamlessly with connection managers.

Dan




[Index of Archives]     [Linux Kernel]     [Linux Wireless]     [Linux Bluetooth]     [Linux Netdev]     [Linux Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux