On Thu, 2009-10-01 at 11:18 -0600, Dan Williams wrote: > 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 > ... > 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. There is not much that can be done to change that, as of now :( > 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. Yep, that's the idea. That was captured in the summary Oleg made a couple of weeks ago. > 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 :( Well, this is what I am working on in a best-effort basis, but I currently have little to show other than the very-low level generic primitives in the op_nap_scan branches of the wimax.git kernel tree and wimax-tools.git tree. I am hoping to have more time these coming weeks to advance. -- -- Inaky
