Words from the inside

Are you using Debian for Arm through QEmu? If so, and you want to use it in text mode (useful, for example, to use it outside a graphical window), the key is the special terminal ttyAMA0.

You must configure your debian to put a getty on ttyAMA0, so you can log in it, and to send boot messages  to that terminal too.

First, enter in the virtual machine, and edit /etc/inittab and add the following line

T0:23:respawn:/sbin/getty -L ttyAMA0 9600 vt100

Next time you boot on machine, a ttyAMA0 terminal will be spawn.

Finally, add to -append options the option “console=ttyAMA0″, so all boot messages will be sent to ttyAMA0.

Now, you can start qemu-system-arm with -nographic option work in text mode.
If you want to login as root, add the ttyAMA0 to the /etc/securetty list.

And the final tip! You can exit from qemu with “Ctrl+A X” (don’t forget to power-off first your virtual machine).

Recently Igalia gave me a new laptop, a Lenovo “The Beast & The Best” Thinkpad, for everyday work. I decided to install Ubuntu Hardy Heron 64bits, as I had never worked with such operating system, and I am eager to learn benefits and drawbacks of working on a 64bits OS.

Among other features, Hardy comes with PulseAudio, the new sound system which has a lot of features.

As I am playing with Maemo I have installed a scratchbox too. A workmate, Calvaris, wrote about how to install scratchbox in a Linux Amd64.

Now the problem: scratchbox comes with esound to manage the sounds. When I am working within the scratchbox, esound daemon blocks the /dev/dsp device, preventing other applications outside the scratchbox to be able to play. This disturbs me a lot, as I like listening music while working. Of course, we can kill esd daemon to free the dsp device, but in this case I can not play songs inside the scratchbox, which I need to do too.

So, what is the solution? The idea is to use the soundcard to play songs for our Ubuntu applications, while the scratchbox will use a virtual soundcard that will sent the music to another host using networking capabilities of esound. The trick is that the ‘another host’ will be our own host, which will receive the music stream and will play it. Cool, uh?

Lets do it!.

Configuring PulseAudio

The first step is configuring Pulseaudio to be able to receive streams through the network. Therefore, edit /etc/pulse/default.pa and add the following line:

load-module module-esound-protocol-tcp

It is likely that line already exists in the file but commented. In this case, uncomment it.

Now you must restart pulseaudio in order to load the new configuration.

Configuring a Dummy Soundcard

Scratchbox esound daemon requires to have a dsp device even when sending the music through network. So we are going to add a dummy sound card that will be used by the daemon.

Linux kernel provides a driver for a dummy soundcard. To load it, execute as root:

modprobe snd-dummy

A new dsp device, /dev/dsp1, will be created.

Configuring Scratchbox eSound

We must configure esound daemon in scratchbox to use the new dummy soundcard. To do this, enter in the scratchbox and edit /etc/esd.conf file. Search the options line and add at the end:

-d /dev/dsp1

In my case, the esd.conf file contains:

auto_spawn=1
#spawn_options=-promiscuous -nobeeps
spawn_options=-promiscuous -nobeeps -d /dev/dsp1
spawn_wait_ms=500
# default options are used in spawned and non-spawned mode
#default_options=-promiscuous -nobeeps
default_options=-promiscuous -nobeeps -d /dev/dsp1

Thus, scratchbox will use the dummy soundcard, while the real soundcard will remain free for Ubunutu. Of course, being a dummy sound card, don not expect to hear music playing in the scratchbox. To resolve this problem, the last step is send what is playing with esound daemon through the network to our own host to be played through pulseaudio.

Configuring eSound’s Network Transparent Sound

This is the last step. Network sound uses a authentication mechanism. So in order to use network transparency both sides must be authenticated between them. When pulseaudio is launched, an .esd_auth file is created in the home directory. Copying this file to the scratchbox home will allow esd to send music to pulseaudio daemon. After copying the file, restart esound daemon.

Now we can send the sound to the pulseudio daemon. From the scratchbox, execute this:

esdmon | esdcat -s 127.0.0.1 &

esdmon listens all data sent to esound daemon, sending it also to the standard output. On the other hand, esdcat reads all data from the standard input and sends it (in this case) to the localhost. As you can notice, working together means that all sound sent to the dummy sound card is also sent through localhost to the pulseaudio daemon, which in turn sends it to the real soundcard.

Now, you can play songs inside the scratchbox and you will hear them! Moreover, you can be playing at the same time music in the scratchbox and in the host, due to multiplexing capabilities of pulseaudio. So both systems, Ubuntu and scratchbox, will sing duet.

If you are an Emacs fan, you may have notice a lot of cool changes from Emacs21 to Emacs22. One of those changes is related to defuns. A defun is simply a function definition. But, what is actually a ‘function definition’? Until Emacs21, a function definition is the code that defines the function (easy, is not it? ). There are a lot of functions in Emacs that are based on defuns: beginning-of-defun, mark-defun, narrow-to-defun, etc.

One of those functions that is very useful is narrow-to-defun (C-x n d): it hides all source code except the current function. Then, you can do all kind of changes that will affect only the shown code. If you try it with a C example, you will notice all code except the function you are positioned is hidden. Unfortunately, as you can check, the function definition is not part of the defun, so it is also hidden. Besides being upset, as you can not see the definition, there are other problems, like Emacs indenting wrong.

But with Emacs22, this has changed, so now a defun includes both the code of a function and its definition. If you try again the previous example in Emacs22, you will notice that now the function is shown fine, and it even indents fine.

The problem is that some Emacs packages are not aware of this change. One of that package is gtk-doc: it creates a skeleton of the Gtk function you are writting. Unfortunately, this package, which works fine until Emacs21, does not work fine in Emacs22, because of the change of defun.

The fix is very easy, and I attach the package already fixed. You need to load Emacs22, and compile it (gtk-doc.el) with compile it with byte-compile-file funtion, which creates a gtk-doc.elc, and then replace the current file with the newer. If you want to have a look at the change done, I attach also a patch with the fix.

Some time ago I began to look at WebKit, the render engine used in Safari and ported to other platforms, like our favourite, Gtk. Some of the issues it takes to me understand is the design of WebKit, mainly the differences between WebCore and WebKit.

So, here is my conclusions. Notice that I’m roughly speaking. Like The Three Musketeers or Three Little Pigs, WebKit is composed by three high level modules: JavaScriptCore, WebCore and WebKit (latter names the global project).

• JavaScriptCore, as its name suggests, is the interpreter of JavaScript.
• WebCore is the core of the project. Implements the render engine itself: analyzes the web pages, generates a DOM tree, a render tree and finally renders it with a backend. There are as many backends as ports. So WebKit/Gdk, the port of WebKit for the best platform uses widgets Gtk/Gdk and Cairo to draw the elements. Though in the figure the backend is separated from WebCore, actually the backend is part of WebCore.
• WebKit is a façade of WebCore. It hides and adapts WebCore to the current platform. In WebKit/Gtk, shows WebCore as Gtk objects, with their signals and API similar to other Gtk objects.

I hope this information be helpful to any one.

One of the most scary problems when I develop an application is a buffer overflow, that happens when you access a memory zone that it doesn’t have be assigned. The problem is that if you overwrite that zone, not always the program crashes, but it stills continues running with that zone corrupted. And, if you are lucky, the program crashes after 10 lines, 50 or God knows.

One of the most used applications to find buffer overflows is Valgrind. It is very sophisticated, and is able to find other type of problems. The drawback is that it only runs on x86, AMD, PPC32 and PPC64.

When I was studying, I discovered Electric Fence, a library that detect illegal accesses to memory. Roughly speaking, it changes the malloc function, so when a buffer is allocated, it adds around it a “red zone”: if you touch that zone, the program aborts with a segmentation fault. What is the advantage? It always crashes in the moment you access an invalid position of memory, not 100 or 300 lines far away. So you can use a debugger and see in which line is crashing: surely, in that line there is an illegal access to memory.

How to use it? More simply, impossible. You only need to link your program with the library (-lefence). That’s all! A banner is showed when the program is executed. Even you may use the Electric Fence with an already compiled program if you preload first the library (exporting the LD_PRELOAD environment variable to libefence.so.0.0).

The drawback with Electric Fence is that it makes the program more more slow. So use it only when developing, and disable it in the final release.

And remember: Electric Fence is in almost all GNU/Linux distributions. Happy bug hunting!