I'm going to FOSDEM

You can find me in the Microkernel OS Devroom.

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.

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.

Watchen sie die blinkenlichten

Turn on CC (captions) in the player before starting the video.

GCC: plus plus or not plus plus?

It appears that GCC has green light to start using C++ in their code. The idea seem to have been under consideration for about two years. This time, however, it has been approved by the GCC steering commitee and the FSF.

The surrounding discussion is is pretty much the old battle between C++ proponents (who point out its many merits) and opponents (who point out its many flaws). Concerns about speed and the need to teach GCC devs to use C++. Concerns about 'misuse of C++ features.' I find the slowness argument especially amusing since Clang/LLVM is written in C++ and it does not appear to be suffer from severe performance problems.

And of course there are those who suggest only to use a subset of C++ that would not incur performance penalty nor contain features that are 'easily misused'. I hear many software projects claiming to use C++ are actually written in different, mutually incompatible subsets of C++ (using or not using exceptions, RTTI, templates, etc.) This seems to be encouraged by the historically bad conformance of C++ compilers to the language standard.

Looking away from the rather amusing bickering, does this change affect me, a mere mortal user? Well normally I couldn't care less. When I compile GCC on Linux this certainly does not present any problem. From HelenOS point of view, this is more interesting.

To make HelenOS self-hosting, we need to be able to have some compiler which can be compiled within the system. Question is, which compiler should it be? Today GCC is still a hot candidate -- it is probably the only compiler supporting all the CPU architectures and other features we need. Another selling point was it being written in C -- which it will now lose. In the future it would be necessary to implement or port the C++ standard library (and STL) to HelenOS in order to compile GCC in it.

This makes GCC drop closer to Clang/LLVM on our suitability ladder. (Clang/LLVM is also written in C++). Practically the only remaining deficiency of Clang/LLVM w.r.t GCC is that unlike LLVM itself, which should have good support for several architectures, Clang currently only has good support for i386/x86_64. It should not be hard to improve Clang support for other targets, but still there must be sufficient demand to drive the development (Apple does not need it).

Another player in the field is the Portable C Compiler. It is written in C, but it is a relatively small project and supports only a few CPU architectures. (Interestingly neither LLVM nor PCC support Intel Itanium architecture). I have some misgivings against depending on such project whose future is not very certain.

In any case, the choice of a (first) C compiler to run in HelenOS remains open for now.

The woes of C

If I wanted to make this article look interesting, I would title it C considered harmful, but I will not. HelenOS is written in C. C is a programming language created at the beginning of 1970's. It's creation is closely tied with the birth of UNIX. At the time of its creation, C was a simple and yet extremely powerful programming language.

C maps (or can map) rather closely to the hardware. Originally it required no or very little run-time support. (What this means: a piece of code using only the core language -- not library routines -- can be compiled directly to machine code and does not require additional libraries or other support to execute).

For quite some time C has been showing its age. Both the core language and the standard library are becoming more and more inadequate for implementation of applications.

Working with strings has always been an extreme pain in C, but with multi-byte encoding (i.e. UCS/Unicode) it has become a nightmare. In HelenOS we decided to drop the standard C99 way of handling multi-byte strings altogether and implement our own. Needles to say, it's only a little better, the language won't allow us more. I demand automatic memory management! I demand user-defined operators!

String formatting in C is a chapter on its own. While this could be re-implemented in the standard library to be extensible (i.e. allow the consumer to register a formatting function for their custom type) we cannot really do away with the need to provide the type of argument in the formatting string, at least not in a sensible way. I demand virtual methods!

What usually drives me mad is the complexity involved in using a hash table in HelenOS. I need to implement several callbacks just to get my int->pointer map. I want generics! I demand collections!

There is a plan to implement a graphical user interface for HelenOS. Having to implement it in C is just giving me the Willies. We would probably end up with some monstrosity like GTK... or worse. I demand inheritance!

I demand a language worthy of the 21st century!

... to be continued.

What this blog is about

Now wait a minute... this blog has existed for a few months already, but the first post is dated today?! That can mean only two things: either (a) I am the laziest person in the solar system or (b) I prefer coding to writing about coding.

This blog shall deal mostly with my contributions and ideas for HelenOS. If you don't know what HelenOS is by the time you've finished reading this sentence, then you obviously have not followed the hyperlink embedded within it. Redo from start. Now you know HelenOS is a supercalifragilisticexpialidocious operating system.

This information is mostly targeted at fellow HelenOS developers and enthusiasts so I will probably not bother to explain all background for the average passer-by most of the time.

I might also blog here about other geeky stuff not related or vaguely related to HelenOS. That is, if I manage to blog at all. Because of (a) or (b).

Hey Jakub, I blogged! Jakub's been persuading me to blog about HelenOS for some time. So there. I've blogged. Blogo ergo sum. Although I don't have a MySpace account. So I don't exist. And I don't have FaceBook account nor a Twitter account nor a Peprnet acount and omega other accounts. So the cardinality of my non-existence set is omega. Doh.