On Thu, 2009-10-01 at 12:05 -0500, Hoi-Ho Chan wrote: > 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? We could modify the current Intel NS, but there are a few issues: 1) It uses the "code drop" model, where Intel pushes out new major releases. Thus, it's hard for outsiders to contribute major features or changes. Adding support for new non-Intel chipsets would likely refactor a large chunk of the code, and if you based your feature off the existing version, Intel's internal versions have likely been improved, and thus your feature patch would not apply. This can be fixed if the wimax service was developed more publicly in an externally visible source-control repository, like the Linux kernel or many other open-source projects. 2) The current code is fairly byzantine :( It re-implements a ton of functionality that is already provided by libraries like glib/qt, openssl/nss, and others. It's quite convoluted and could be dramatically simpler. Ideally, the Intel-specific stuff (for scans and whatnot) would simply be a plugin for a generic NS, and the generic NS would not be tied to Intel hardware while the small plugin would be. I don't want to diminish the contribution that Intel has currently made with its open NS and driver stack. But it can definitely be improved. As a connection manager writer, I would really like to see *one* common, generic Network Service that everyone can standardize around, much like Linux wifi has standardized around wpa_supplicant. That would be great. But it's going to take some work to get there. Often people take the easy path due to schedule pressures or time or whatever, which doesn't help us get to the nice bright rosy future though :( Dan > 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 > > >
