Hi Dan,
Is there a reason we do not modify Intel NS to support another chipset
instead of writing a vendor-specific NS? Or you think the Intel NS is too
specific that it is not possible to do so?
Thanks
Donald
On Thu, Oct 1, 2009 at 11:51 AM, Dan Williams <dcbw at redhat.com> wrote:
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxwimax.org/pipermail/wimax/attachments/20091001/f5fc0240/attachment.html>
