After a week’s waiting my mentor informed me that I had passed the mid-term evaluations. (he said that my performance for the first phase exceeded his expectations. :D ).

Its been a long time since I actually blogged about the progress. After I got the Freerunner in my hand (muhuhahahaa), it was more fun since there were subtle changes in the way the code ran on the device. Tracking down segfaults was uber awesome.

Plugins are now written entirely in vala. Earlier, this used to be an ugly abomination of hand-written and vala generated C code. Now, where good ol’ C is necessary, .vapis’ have been added that wrap around code written in C.

Additionally plugins for rtc, input and led were added. Input plugin is incomplete though. The code isn’t perfect yet, so need to refine them and make them a bit tight in some places. rtc and led especially needs some tweaks.

I guess most of the second phase will be spent on syncing with frameworkd. Now, the python device daemons have been integrated into a single daemon with odeviced as one of the subsytems. (Earlier this was separate). The python daemon is uber-cool by itself, but imagine a C implementation of the entire frameworkd. Light on resources and excellent in performance, if done right.

Git repository here.

Sunday’s are fun. Even more, when you get together with your school buddies for a long chaat.. Burp!

I haven’t seen most of these guys for a looong time. So it was fun reliving the school moments. As for me, I was mostly silent having my mouth full with “Dahi Puris”. Seriously, Adayar Ananda Bhavan in Tambaram makes a good bunch of them. Its an ecstatic experience, when the “puri” breaks in your mouth releasing dollops of fresh sweet yoghurt with an assortment of tingly sauces. Try it when you go there. Highly recommended.

It would have been awesome if the entire class turned up. (That way I could have eaten more ;) )

And special full credits to vidhya for bringing a camera that didn’t have batteries. Now, we have to be satisfied with crappy pics taken from even crappier mobile phones.

Also, my mentor is happy with my GSoC performance, so looks like I will pass my mid-term evaluations. Yay! What a weekend…

Wow, DHL dudes are fast. They took just 4 days to ship the device considering there was a sunday in-between. Thanks to Daniel for sending the devices to the SoC’ers.

I don’t have a dedicated camera, so pics are a bit sucky

(Evil maniacal laughter) Here are the pics…muhuhahaha

A few days gone by, and endless wrestling with git wherein I was not able to push code. Turned out, I was using the wrong URL to push ..doh!

But anyway, the code is beginning to stabilise a bit (Read no unexpected segfaults, only expected ones..). The last few days were spent in changing the method names in accordance with OTAPI naming conventions after my mentor went through my code.

There is also another important change. The sysfs nodes for backlight and power plugins were hardcoded in their configuration files. So, I came up with some helpers that creates DBus paths automatically based on the device class which they belong to. Here’s a picture of today’s code in action,

Notice the d-feet DBus debugger towards the lower left? It shows all the automatically created DBus object paths based on the device class which the plugin stands for. And the terminal to the right shows some debug messages. Note how odeviced spits out the current battery status viz. “Charging, Discharging”. The corresponding “battery-status-changed” DBus signal is emitted as well (along with “low-battery-warning” signal which ahem is emitted when battery is low).

For more follow this thread..

After a little chat with mickeyl, I realised that exposing crucial functions like load() and unload() was not that of a good idea considering how odeviced is supposed to closely interact with the underlying devices. Consequently there has been some changes over the last week,

• No DBus interface for the service.

• Plugins have now access to a set of helper functions. Only two at the moment (Think setting up DBus object paths)

• Plugins once loaded become resident, that is they cannot be unloaded. If plugins are to be disabled during startup, just remove them from the “enable” field in the global configuration file.

• Per plugin configuration. Each plugins now have their own configuration. Makes more sense, since this mean plugins can have greater freedom with their settings. I really like how the newly checked in battery plugin exploits this.

• Freshly checked in battery plugin. Makes use of sysfs for its functions viz. get_current_brightness, set_brightness, get_maximum_brightness.

SysFS (/sys in 2.6.x.x) is sort of similar to the /proc filesystem and acts as an interface for user-space applications to control/access various devices. One of the neat things about sysfs is the fact that all files consist of only a single entry. This means I don’t have to write a separate parser to extract data from them. So a simple fprintf or fscanf or even the seemingly mundane “echo” can be used to control the devices.

I am also planning to work on the python shell for odeviced for a while. This will be really convenient for testing the service. Something like this,

> Wifi is_on wlan0 True

The code can be checked out from here. I can’t wait till I get hold of a FreeRunner to test odeviced out. :)

Yay. Got the repository for odeviced set up at http://git.freesmartphone.org

Boy, do I love git.

I will be entering final year in a couple of months and this means…PLACEMENTS!!! yay! (..or the lack of it)

This means more “Mock Interviews Sessions” and “GDs” to “empower” engineering students to get placed in the only 3 software companies that exist in this physical Universe. Infosys, TCS and CTS (Apparently our college is too dumb for hybrid corporates like m$).

And this blog post sort of sums up my thoughts. Highly hilarious, rolled on the floor injuring my mutti.

Especially at this,

“Any actual work experience? Buying groceries for my neighbour who has this pretty daughter called Gayathri.”

Oh, yeah! I can empathize.

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

So, presenting a preliminary skeleton service for odeviced that loads shared object libraries (or in other words plugins). Nothing to be proud of, but hey, something is better than nothing.

Here’s a screenshot of a very very preliminary odeviced in action..

Basically its just a dbus service that can load modules from a predefined location. Here’s how it works currently,

• Setup all the boring stuff like registering the object path and getting the connection to the DBus system bus. The interface used will be “org.freesmartphone.Device”.

• The service reads the configuration file at /etc/odeviced.conf whose contents are as follows,`

  General configurations

  [odeviced] device_name=FreeRunner [powercontrol] enable=1`

• So from the above configuration, the device name is set to FreeRunner and odeviced tries to load the powercontrol plugin since “enable” is set to 1. Of course, the dbus service exposes the load method to load plugins manually after the service has started if the need arises.

• The default directory for plugins is at ‘/usr/share/odeviced/plugins’. Maybe additional directories for other plugins can be set in odeviced.conf. By now odeviced tries to load the plugin libpowercontrol.so under ‘/usr/share/odeviced/plugins’.

• After successful loading of the plugin, odeviced executes the init function in the plugin which is of the form <plugin_name>_init. In our case it is powercontrol_init. The dbus paths for the plugins are to be set here. So we would have object paths such as “/org/freesmartphone/Device/plugins/powercontrol’. This is yet to be done.

• As evident in the above screenshot the powercontrol_init contains a single printf statement which merely spits out “In powercontrol”. And yes, the powercontrol plugin is written in good ol’ C.

Notice the gnome-terminal at the right. It is running a simple python helper script for testing odeviced. It simply reads from stdin and calls the `load’ method offered by the dbus service with the input as the argument. As you can see, powercontrol has been loaded successfully but “l” and “this_aint_a_plugin” gives a critical warning that these plugins couldn’t be found.

What needs to be done

• Make the code “beautiful”. :D. I am constantly on the lookout for vala’ish ways of doing things. Still need to work on my OOP skills :/.

• Come up with a decent plugin for powercontrol.

• Put in some example apps or port the existing OM ones to use odeviced.

After the lousy semester exams, I decided put in some time to learn vala and dbus to cheer me up. For the unitiated,

• ‘Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C.’

• DBus is a low latency IPC system with less overhead with emphasis on desktop applications

I must say the folks at #vala in GimpNet has been patient with me, especially considering the silly questions I had been asking for the last couple of days. I should get commit access to the git repositories of freesmartphone.org in a short while as well :D.

I learned a couple of things on the way. Especially the KeyFile API from the GLib library really rocked. Note that odeviced would have configuration file sitting in ‘/etc’ containing various settings like plugins to be loaded, their own internal switches and so on. I would have almost “reinvented the wheel” trying to reimplement stuff thats already provided by GLib if I hadn’t browsed through the API reference of GLib. Implementing something like the above for odeviced in vala looks something like this,

1
2
3
4
5
6
7
8
9
10
11
12

....
private GLib.KeyFile file = new GLib.KeyFile();
private string[] plugins;
private string dev_name = new string();
......
/* vala will warn you if you dont put this under a try, catch block */
file.load_from_file("/etc/odeviced.conf", GLib.KeyFileFlags.NONE);
if (file.has_group("odeviced"))
this.dev_name = file.get_string("odeviced", "device_name");
plugins = file.get_groups();
_load(plugins);
....

Of course, the corresponding configuration file will look something like this,

1
2
3
4
5

[odeviced]
device_name=FreeRunner

[powercontrol]
enable=1

In the above example, things within ‘[’ and ‘]’ are group names and each of these groups consist of a key-value pair.

As for the dbus part, each plugin would set up dbus objects on their own. GModule library will be used to load the .so libraries. So we’d have object paths like /org/freesmartphone/Device/powercontroller. And of course, odeviced will be on the System Bus.

On a related note, the “surprise” gift is on its way :D.