TCP... the truth will be revealed

I have long before recognized that the current network stack in HelenOS is messed up beyond repair and trying to fix it anymore is a waste of time. Since it's been two years after the master thesis was defended and we still do not have something that would work, it might not be well received by others if I threw everything out and started from zero, though.

So I started with a complete rewrite of TCP. This is arguably the only more complex / non-trivial module in the stack and the part that is obviously most broken.

Despite lack of spare time I have now a new TCP module that is not 100% complete, but complete enough so that it could be test-run against itself over the wire. I implemented it as a completely independent server that has nothing in common with the current networking stack. I tested the functionality using internal loopback in the TCP module and internal clients.

Yesterday I started hooking it into the current network stack, the idea is to create a minimal connector between the two components. After three hours of work there is still some way to go before I can successfully send/receive PDUs to/from IP (I haven't started with the socket interface yet).

During this work I had the chance to fully 'appreciate' the quirks and complexities of the network stack. IP understands sockets and TCP pseudo headers. TCP knows about IP headers and network devices. But who cares about layers or separation of concerns, right?

Since quite a few people claimed that the remainder of the network stack actually works -- to some degree -- I wonder whether I get something at least remotely useful when I plug my TCP implementation into the stack. The truth will be revealed. And then I can maybe throw the rest of the rubbish out.

The first sentence counts

Of the novels and short stories I've read there were two cases where not only they were works of sheer literary genius, but also written with a humour that sold them to me with the very first sentence.

In the first case the short story Jupiter Five, my favourite by sir A. C. Clarke, partly due to the excellent and slightly unusual Czech translation.

Profesor Forster měl tak drobnou postavu, že pro něho museli vyrobit speciální kosmoskafandr. (Profesor Forster's stature was so small they had to make a special spacesuit for him.)

In the second case this was the (perhaps more widely known) novel Harry Potter and the Philosopher's stone:

Mr. and Mrs. Dursley, of number four, Privet Drive, were proud to say that they were perfectly normal, thank you very much.

When a story starts with a sentence like this, you just know you're in for a treat :-)

Will ARM architecture go 64-bit?

For some time now I have been thinking about the increasing memory capacities of mobile devices and the fact that the ARM architecture, upon which they are built, is still 32-bit only. This was puzzling for me, so I decided to dig around a little. The results are more than interesting.

Apparently, in November last year (2010) rumors started spreading that ARM holdings is working on a 64-bit ARM processor (see Xbit labs, v3.co.uk). These rumors were denied by ARM CEO Warren East in February 2011.

In an interesting turn of events, before that in January 2011 at the Consumer Electronics Show in Las Vegas Nvidia announced project Denver which aims to create a 64-bit ARM processor powerful enough to compete on the desktop and server market. At the same time Microsoft announced that Windows 8 will run on ARM as well as on x86. You can read a vey nice analysis on Ars Technica or the interview with Nvidia CEO.

Nvidia's plans are very bold. Who knows whether they will succeed. If they do, this could stir the stale waters of x86 deskop quite a bit. Spending the last HelenOS camp finding a bug in the ARM context save/restore routines might not have been a waste of time after all. Who'd have thought? ^_^

How to ride your magic carpet

Magic carpets are, you know, pretty much commonplace stuff. Everybody rides one, including Prince of Persia and the Rescue Rangers. Now the thing which has always bugged me is the question: How do you control which direction the carpet should fly?

Looks like another big mystery solved. And I didn't have to look far for the answer, too. It's all written in, I am not kidding you, the USB HID specifications. Quoting:

Magic Carpet Simulation Device

CA – Allows a device to be generally classified as one that uses the standard control of a magic carpet. This control is a bar, grasped by both hands, that controls the Yaw, Pitch and Roll of the carpet.

The bar, at which the pilot sits, may be pushed forward or pulled back to cause the carpet to dive or rise, respectively. In the zero position, the carpet is in level flight. Pushing forward on the bar causes the carpet to nose down and generates negative values. Pulling back on the bar causes the carpet to nose up and generates positive values.

Turning the bar turns the carpet. In the zero position, the carpet travels straight ahead. Pulling back on the right side turns the carpet to the right and generates positive values. Pulling back on the left side turns the carpet to the left and generates negative values. Rotating the bar rolls the carpet. In the zero position, the carpet travels level.

Rotating the bar in a clockwise direction rolls the carpet to the right and generates positive values. Rotating the bar in the counterclockwise direction rolls the carpet to the left and generates negative values.

Now fortunately HelenOS will soon get USB HID support. So that means I can run HelenOS on my magic carpet's on board computer and still use the standard controls of the magic carpet, right? Right?

Granumophobia

Getting dynamic linking to work right is a never-ending series of dumped cores. Today I found two bugs which were actually quite generic (i.e. not architecture-specific) and, to be honest, quite silly.

First a sizeof(ptr) instead of sizeof(*ptr) passed to memset() caused the dyn_info_t structure not to be properly zeroed out. If something in dyn_info_t is not zero, it is assumed to be valid entry present in the dynamic section. Hence mysterious occasional crashes. Luckily thanks to the new memory allocator which has debugging turned on there was a suspicious quantity of dead beef being thrown around which slightly helped me find the problem.

Second, the relocation processing code was dying while trying to fix up references to libc variables in the text segment of the main program, which is stored in a memory area with R-X permissions. Huh? Well, the main program is loaded by loader, instead of dynload. Unlike dynload, loader does not make all loaded segments writable. Bummer.

Dynamic linking takes patience. If you suffer from granumophobia, then stay away.

Base class constructors? Oh my!

When a person with quite limited exposure to OO programming (like me) gets such a crazy idea like designing an OO programming language (like Sysel), they shouldn't be surprised when they forget about something important. Like invoking base class constructors.

GSoC - Great System on a Chip? No!

It seems a little pointless repeating what has already been said, but, wow, is this something special! HelenOS has been accepted as a mentoring organization for 2011 Google Summer of Code.

What more to say? It feels great to be in company of so many well-known open-source projects from areas of OS, desktop, applications, games, scientific software, etc., etc.

Now we need some students!

Observations on HelenOS device drivers framework

Some time ago we merged Lenka's new Device Drivers Framework (DDF henceforth) to HelenOS mainline. When I finally read through her thesis and had a closer look at the code I promised to do a writeup of my observations. Here it is. A bit of a long read though, be warned.

Let's start with a quick overview. Lenka's contribution can be broken down into several parts. First there is the devman server which (a) manages the physical device topology, driver task life cycle, driver attaching and detaching, (b) maintains a 'logical' device topology (devices grouped by their class).

Second, Lenka proposed that for any IPC communication between two drivers or an application and driver should be strictly defined in terms of function calls and the client- and server-side IPC glue code should be kept strictly separate in a library to be reused by all servers and clients using such code.

Third, when mapping the function calls to IPC, Lenka reserved the first field of the message for an interface id. This allowed her to communicate with a driver using several different protocols, namely a protocol for talking to the driver as such (create new instance) and for talking to the device itself (e.g. read/write, etc.).