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.).

Mister triple W. meets miss H.

I think the following image speaks for itself.



After my recent bug fixes, HelenOS is able to serve a web page from inside Qemu. TCP is still shaky, sometimes it works, sometimes it does not. But it's still progress :-). In the past weeks and months I got my hands dirty in the networking stack and I tell you, the code is weird throughout!

The web server is mostly fake, but it does serve its purpose :-) I should be committing it shortly.

A moment to remember

If you don't understand Czech, turn on CC (captions) in the player before starting the video.