On Thu, 2008-10-09 at 13:22 -0500, charles zhuang wrote: > Nice saying Dan. > I agree that the user space code has an overwhelmingly structure > spanning from code written in year 2005 to 2008 and it's much like a > windows project. I guess a big chunk of the code may not directly > relevant to what the current simple connection utility provides. It will > be nice if Intel can share with us the big picture on what the user > space wimax stack will provide in terms of API, functionality and > features. > I believe a big portion of user space functionality should be on ND&S, > OMA DM, and various user initiate actions on service flow, connection > control, etc. However now I didn't see a clear path in the user space > code as where those features are or supposed to be in. > I am working in the process to port over this wimax package to a > handheld device, while immediately I realized the user space components > have too loose structure which doesn't fit well into an embedded > environment. Here's the way that Marcel and I have discussed it at various conferences over the past few months... it fits in pretty well with the standard Linux design philosophy and keeps things flexible enough to allow the WiMAX network service to be used easily on both desktops and mobile devices where the highest UI layers may be quite different: 1) The WiMAX network service abstracts the hardware specifics and handles intermediate operations, much like wpa_supplicant does for WiFi on Linux. It doesn't store any state but simply controls the card and does what higher-level clients tell it to do. 2) The WiMAX network service provides a D-Bus service for higher-level clients, essentially providing the Common API or a subset of the Common API that is actually usable. Things like scan, associate, disassociate, get connection quality, etc. Design of this D-Bus service's methods and properties should start with the simplest core operations and add functionality from there. To begin by trying to implement the entire Common API would simply take too long. 3) Higher level clients of the WiMAX network service control actual policy, operation, and IP-level connectivity. The NS itself should not be doing the DHCP or assigning the address to the interface, that should be left up to the network daemon (ConMan, NetworkManager, whatever) that can take the users preferences and overall network topology into account. What the full stack should look like: .---------------------------------------------. | UI | |---------------------------------------------| | OMA-DM | Network/Connection manager service | |---------------------------------------------| | WiMAX NS | Bluetooth | WiFi | 3G | |---------------------------------------------| | Kernel and drivers | `---------------------------------------------' On the desktop side we've got various implementations of the other bits: Bluetooth == Bluez, Wifi == wpa_supplicant, 3G == ModemManager. Dan > Charles > > -----Original Message----- > From: wimax-bounces@xxxxxxxxxxxxxx [mailto:wimax-bounces@xxxxxxxxxxxxxx] > On Behalf Of Dan Williams > Sent: Thursday, October 09, 2008 11:46 AM > To: wimax@xxxxxxxxxxxxxx > Subject: General suggestions for the network service code > > On Thu, 2008-10-09 at 09:50 -0500, charles zhuang wrote: > > Hi, > > > > The current wimax service provider code seems only build on 32 bit > > machine. Here's the error when build on a 64 bit machine, does anyone > > have idea what it is? > > > > > > > > make[2]: Entering directory > > > `/root/charles/wimax/intel-wimax/WiMAX-Network-Service-1.2.5/tools_proje > cts/Pipe/Common/Services' > > > > make -C ../../OSAL all CONFIG=Debug > > > > make[3]: Entering directory > > > `/root/charles/wimax/intel-wimax/WiMAX-Network-Service-1.2.5/tools_proje > cts/Pipe/OSAL' > > > > gcc -o Debug/libosal.so wimax_osal_win.o wimax_string.o osaltrace.o > > wimax_osal.o wimax_util.o osal_event.o -shared -lpthread -ldl > > > > /usr/bin/ld: wimax_osal_win.o: relocation R_X86_64_32 against > > `LASTERROR_THREAD_KEY' can not be used when making a shared object; > > recompile with -fPIC > > Ugh, that thing really does need a rewrite with a *NIX-style build > system (even eclipse project files would work). First, it should be > using correct CFLAGS for the architecture in question (-m32 or -m64 or > whatever) as determined by a configure script, second the directory > structure is really quite weird for a *NIX project and looks quite a bit > like a Windows port which it probably is. > > Third, the network service needs to provide a D-Bus API so that stuff > can actually talk to it sanely without yet another IPC layer > implementation. Net savings: 1500 LoC or more. > > Fourth, if the service _really_ needs to implement the common API, it > should export two different D-Bus interfaces, one that actually > implements the common API and a second one that most tools will actually > use. > > Fifth, it's pointless to include yet another implementation of crypto > algorithms when multiple libraries (nss, openssl, gnutls) already do the > job just fine and are quite tested. > > Sixth, it should just use an existing project like qt or glib for a > mainloop, and it shouldn't need to re-implement stuff like strcpy, > memset, etc, since those already exist. > > Seventh, why is it including its own copy of expat? > > Eighth, why does it need threads? Most of the time things don't really > need threads and they create quite a lot more confusion and headache > than convenience. If you have a sane event loop with timers and > callbacks and asynchronous event support (glib, qt, whatever) then you > don't need threads, and you save all the mutex code and having to think > about concurrency. > > Ninth, why a re-implementation of a linked list? Again, if based on a > sane event library (glib, qt, etc) this is all provided for you. No > need to roll your own. > > Tenth, XML as the config file format is nice, but there are much simpler > mechanisms that would save a lot of code (GKeyFile in glib for example). > That's _if_ the service requires configuration in the first place. It > should really just be a generic controller and shouldn't need to store > any state at all, since that's what connections managers built on top of > the network service (and talking to the network service via D-Bus) > should be doing. > > Anyway, that's from a quick look at the 1.2.5 package. I mean this to > be constructive and I'm *volunteering* to help fix these things up even > though it probably means a significant rewrite or starting from scratch. > That's fine, Intel has done a wonderful thing by making these pieces > open so that everyone can help improve them. > > Marcel/Inaky, what's the status on the supplicant? Any progress getting > other supplicants to work instead of the binary supplicant? Is anyone > doing an open-source OMA-DM client that you're aware of, maybe Intel has > one they'd be willing to open-source? Any open OMA-DM code from > anywhere would be a great starting point. > > Thanks, > Dan > > > _______________________________________________ > wimax mailing list > wimax@xxxxxxxxxxxxxx > http://www.linuxwimax.org/mailman/listinfo/wimax >
