Why Milestone? Nope, I didn’t come up with fancy code or a “beautiful” one for that matter (Came up with a way to unload plugins). Milestone, because today was the first day I was squeezing up my half empty head to work around a teency weency problem. In short, I am happy I was actually thinking today about squishing a segmentation fault which was bringing the whole house down due to dbus and the kinky wifi plugin.

Now a word of warning. The wifi plugin is a circus freak of sorts. Being the lazy bum I am, I found it a drag to manually get into the trouble of coming up with xml introspection data for the “org.freesmartphone.Device.plugins.wifi” interface.

Instead I just came up with a grand plan of letting valac generate wifi.c and wifi.h, which I could modify later. Piece of cake? Sure…

After the wifi plugin is loaded it works pretty well. The keyword being “After”…By the way, check the progress report which I sent to the smartphone-standards list. That should give you an idea of how odeviced works and looks like. In fact, it works pretty satisfactorily discounting the segmentation faults :D, which is easily reproducible in the following ways,

• Don’t load the wifi plugin on startup, set enable=0 in odeviced.conf. Instead load it manually after odeviced starts up and begins to idle.

• If the wifi plugin is already loaded, unload it and then try to load it again.

Part of this problem might be my arrogance of not to use GTypeModules for dynamically typing the plugins. I need to discuss with my mentor, mickeyl about this once he gets back to business after LinuxTag.

The barely bare bones powercontrol plugin loads and unloads without any problems, but it doesn’t do anything as remotely useful as the wifi plugin!! Just contains an init function that has a printf in it (bleh!, thank goodness it didn’t bail out).

Oh and the all important tarball is here. Highly effective than laughing gas!

…Another gdb session beckons