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. 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
