Collection of WebKit ports

WebKit is a very successfull project. It is that in many ways. The code produced seems to very fast, the code is nice to work on, the people are great, the partys involved collaborate with each other in the interest of the project. The project is also very successfull in the mobile/smartphone space. All the major smartphone platforms but Windows7 are using WebKit. This all looks great, a big success but there is one thing that stands out.

From all the smartphone platforms no one has fully upstreamed their port. There might be many reasons for that and I think the most commonly heard reason is the time needed to get it upstreamed. It is specially difficult in a field that is moving as fast as the mobile industry. And then again there is absolutely no legal obligation to work upstream.

For most of today I collected the ports I am aware of, put them into one git repository, maybe find the point where they were branched, rebase their changes. The goal is to make it more easy to find interesting things and move them back to upstream. One can find the combined git tree with the tags here. I started with WebOS, moved to iOS, then to Bada and stopped at Android as I would have to pick the sourcecode for each android release for each phone from each vendor. I think I will just be happy with the Android git tree for now. At this point I would like to share some of my observations in the order I did the import.

Palm

Palm's release process is manual. In the last two releases they call the file .tgz but forgot to gzip it, in 2.0.0 the tarball name was in camel case. The thing that is very nice about Palm is that they provide their base and their changes (patch) separately. From looking at the 2.1.0 release it looks that for the Desktop version they want to implement Complex Font rendering. Earlier versions (maybe it is still the case) lack the support for animated GIF.

iOS

Apple's release process seems to be very structured. The source can be downloaded here. What I think is to note is that the release tarball contains some implementations of WebCore only as .o file and Apple has stopped releasing the WebKit sourcecode beginning with iOS 4.3.0.

Bada

This port is probably not known by many. The release process seems to be manual as well, the name of directories changed a lot between the releases, they come with a WML Script engine and they do ship something they should not ship.

I really hope that this combined tree is useful for porters that want to see the tricks used in the various ports and don't want to spend the time looking for each port separately.

Random notes on building Android

This is mostly a note to myself. The easy way to build a profilable image for Android (e.g. Gingerbread). I am applying the patch from the bottom to build with framepointers. I am build an unstripped image, I use the environment script and then launch the emulator. With the default engineering mode opcontrol and oprofiled will be installed only the events will be missing from the image.


$ make TARGET_STRIP_MODULE=false
$ . ./build/envsetup.sh
$ help
$ setpaths
$ ./out/host/linux-x86/bin/emulator


diff --git a/core/combo/TARGET_linux-arm.mk b/core/combo/TARGET_linux-arm.mk
index ae1997c..66e55fd 100644
--- a/core/combo/TARGET_linux-arm.mk
+++ b/core/combo/TARGET_linux-arm.mk
@@ -56,7 +56,7 @@ TARGET_LD := $(TARGET_TOOLS_PREFIX)ld$(HOST_EXECUTABLE_SUFFIX)
 TARGET_NO_UNDEFINED_LDFLAGS := -Wl,--no-undefined
 
 TARGET_arm_CFLAGS :=    -O2 \
-                        -fomit-frame-pointer \
+                        -fno-omit-frame-pointer \
                         -fstrict-aliasing    \
                         -funswitch-loops     \
                         -finline-limit=300
@@ -68,7 +68,7 @@ TARGET_arm_CFLAGS :=    -O2 \
 ifeq ($(ARCH_ARM_HAVE_THUMB_SUPPORT),true)
 TARGET_thumb_CFLAGS :=  -mthumb \
                         -Os \
-                        -fomit-frame-pointer \
+                        -fno-omit-frame-pointer \
                         -fno-strict-aliasing \
                         -finline-limit=64
 else

Switching back to Ubuntu/Debian from Fedora

My initial reason to try Fedora Linux was that a lot of good things (glibc, SELinux, systemtap, gdb) are mostly developed by Red Hat and put into Fedora. So it felt natural to try Fedora Linux to see the state of things. Now after more than a year with Fedora I am back to Ubuntu/Debian. For some simple reasons:

yum is ultra slow. When I try to search a package it decides to update the package database over the network, it is slow to start, it is slow to carry out simple operations. The other is that the various databases on the system are quite big and take a lot of space.

My upgrade to Fedora15 was hosed. Not so much to complain about as the distribution is not meant to be released the next week or such. So I was experiencing integration issues (e.g. setroubleshootd causing SELinux denies which will start the settroubleshootd), systemd not logging to /var/log/messages.

With Fedora15 I also had the opportunity to try GNOME 3.0 and in many ways it is promising, I don't think it is ready for end users yet though.

The biggest issue with Ubuntu right now is to get SELinux up and running, their policy modules are quite outdated.

Playing with a MSC over the A-link

One of the benefits of having a dynamic language like Smalltalk is that it becomes easier to experiment. For one of my current projects I am dealing with some simple USSD message handling and want to see how much load my application and the backend system can handle. Using the Smalltalk TestPhone this becomes quite easy.

The first thing I do is to make up an Identity. This includes the IMSI and the AuKey (e.g. COMPv1 as found in libosmocore) and the next is to establish the A-link to the MSC.


> phoneConfig := PhoneConfig new.
> phoneConfig imsi: 'XXXX...' auKeyv1: 'AAAAAAA'.
> (server := IPAConfig new addr: 'A.B.C.D' port: 5000) connect serve.


The next part is to do 'procedures' (SCCP connections with a specific goal). Right now there is an implementation of the LU Procedure, the beginning of Call Control (no way to hang up or such) and and sending some bits of USSD (processUnstructuredData Request). To warm up I can execute a simple USSD query. The below code will wait until the operation has completed, it could also print out if it was considered a success or a failure.


> (server doUSSD: phoneConfig nr: '**1234#') execute


Now to produce load I can repeat this, or create multiple processes. In the below code I am going to create four processes that each will do the query 100 times.


> 4 timesRepeat: [:time |
[
100 timesRepeat: [:each | (server doUSSD: phoneConfig nr: '**1234#') execute]
] fork.


Another thing missing is to add a timeout on each of these operations, e.g. if the MSC does not answer fast enough or such but I will blog about transactions and dealing with time-outs in another blog.