Please see my responses inline below. rgds Jayant -----Original Message----- From: wimax-bounces@xxxxxxxxxxxxxx [mailto:wimax-bounces@xxxxxxxxxxxxxx] On Behalf Of Dan Williams Sent: Thursday, October 09, 2008 9: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_projects/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_projects/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. [j] we are leveraging the lead work that happens on windows. We are evolving it to native Linux as time and resource permit. The upcoming release (very soon) uses automake and hopefully should address these build related issues. 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. [j] this is in our plans too. Expect soon in one of the coming releases. 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. [j] which one are you specifically referring to - AES? 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. [j] yes we do plan to fix this. Seventh, why is it including its own copy of expat? [j] Ack. will fix. 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. [j] this relates to inheritance from windows. 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. [j] once we move to glib, that will change. 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. [j] thanks for the review and inputs. 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
