Tuesday, May 01, 2007

410

Three digit numbers abound in this world. Some are used for emergenices, some for information. Some of them can give u train information, others can tell you the status of your cell phone. Such numbers are not what I am gonna talk abt it, however. The three numbers that shook (and are shaking) my world this past semester have a very familiar ring to anybody who's taken a similar course at the tartans, and anywhere in this country.

Four-ten. These simple digits, put together in this fashion have been shaping me since January. Its caused ups and downs, and swings of all kinds. Yes, its also a very good weight loss program for those of you who can handle the stress, the workload and the pressure.

It starts in baby steps. You write a neat little program that tells you who called it. :-) Yeah, I dumbed it down a little, but a week and the tracer is done. That was the warmup.

Its now game time. This is where the buildup begins. Its time to begin the drivers. Start out with the video drivers, so that you can see things on the screen. Move on to the keyboard drivers, so that you can actually write what you want to on the screen. Now to test it, write a sweet little game. Something like pac-man. Nothing fancy. Just a maze, with a mite roaming around and trying to find his way out of the crazy world us crazy programmers dumped him in. This is where the fun began. Silly mistakes became evident, and the pressure began to show. What ifs needed to be answered. Stubborn fool that I am, I decided to continue. It'll be a great experience, and its something that I just wanted to do. With this resolve in mind, I ploughed on to the third project.

P2 they called it. The first group assignment. The task, should we choose to accept it, to write a thread library for a kernel. This thread library would have to be very robust given the kind of test cases we were about to encounter. As the code came to being, our thread library slowly took shape. Things seemed to be going along, with every new bug showing us the way to a brighter and better code. All until one day. (It could have been night, they were all the same to us.) Suddenly something stopped working. Or staretd working sporadically. And thats the toughest part of debugging. If it doesnt work all the time, fine, u can catch the troublemaker. If it works sometimes, and not others, then you are in one big soup, and the bowl just keeps getting deeper. After 3 sleepless nights, of going home at 5-6 am and trying to catch some shut eye, we realised that we were crashing the provided kernel. That wasnt our fault. The course staff, quickly rectified it and "shipped" us a new kernel. This of course, not before my partner, R, and I lost a few kilos, and nearly tore each other's hair out. (Her hair was short then, so couldnt really grab much.) But yes, the pressure and the stress were mounting. We had 4 days to fix our code to work on the new kernel, and were about 2 days behind the rest of the class. At one point I distinctly remember the feelings that rocketed through me with R pacing behind me as I debugged and thinking out loud that she would drop the course if it didnt get fixed. Lets just say that thankfully it did, and with 2 days to go at 3 am with just the two of us sitting in the kitchen of the department we were now able to run all their tests. The smile that R cracked then, was amazing. Something not seen for three weeks, and relief swept over us both, as she dozed off for a bit (trying to do another subjects homework).

Now it was time for the biggie. Time to write our own multi-threaded, pre-emptible kernel. Scary? Oh you have no idea. To add to the boiling pot, this came out in the dreaded mid term week, so we all started one week late, with a checkpoint racing towards us. The sleepless nights began. With it came the raised volumes, and the heated discussions. I cant imagine what either of us (R and I) would have done to the other had we not been friends before we started this course. But neither of us could be blamed, it was just the frustration that kept building up inside. Checkpoint 1 approached, and we moved to the first big step of the kernel. We loaded a program. Sounds simple? Far from it. The night before I worked on the loading, as R prepared for her exams. When I finally got something to happen, I was so elated, I didnt cross check what else had to be done. Wrote some code, and crashed for the night,. Wake up in the morning, and R has some news for me. I forgot to check my latest addition of code, and had created some sort of mess. Some quick fixing, and she managed to recover from that, but we still fell a little short of where we needed to be. I'll never hear the end of that!
With the mess we had for the first checkpoint, we quickly attacked the next one. Spring break saw us work like maniacs, never going home before 5 am, for the first few days. Then we hit something we never thought we would. Success. Something worked. And we were ready for checkpoint 2, ten days ahead of schedule. Things eased up a bit there, and we each caught up with the other courses we had for the semester. (Yes this wasnt our only course!) Sometimes things are just to good to be true. As the d-day approached, we decided to run their tests to see how things worked, and boom! It crashed. Debugging this was one week of pure hell. In all senses. Nothign seemed to work that week. The whole world fell apart at the seams, as we tackled this issue. R, not quite the patient person, went ahead with three different implemntations of the system call. Nothing seemed to work. Tempers were flaring. Yet work progressed parallely. Two things we learnt from that one bug.
1. Never ever copy paste!!
2. Debugging one issue can find so many bugs in so many other places just by re-reading.

That one week will never leave me. It ended with a call from R on a friday afternoon, 7 days since we found the bug. We went out for lunch that day :-)

After that things seemed pretty much under control. And soon enough we had a non-preemtible kernel working. Making it pre-emptible took another week of tweaking, and stupid blunders kept getting caught. This one ended with a jump as all the tests worked in a pre-emptible fashion, and we implemented some of our own cute things. The department rewarded us for our hard work with a "floppy disk seminar." Big 16 inch floppies with cheese and meat, with some soft drinks. :D

Time for the final hurdle. P4. The bootloader. This is what would boot the kernel we wrote, which could then use our thread library, and would use our keyboard and video drivers.. Neat? But yeah, first we had to write the thing. This was a relatively lighter project. (I mean really light). Just make sure to read the documentation properly as you code. That cost us 1 day. R and I could have gone out for dinner with some friends had we done so. Come Sunday afternoon, and we fix the last of the bugs... I'm still reading the spec to see if we missed out on something, when I hear R scream.. and the she calls me over.. and begins jumping... we had booted our kernel. She couldnt contain her joy. And a flood of relief swept over her. I saw who R was again. A person. Not a machine. ;-)

This was a course that redefined my life. Four to five hrs of sleep became the norm. More than that and you'd feel guilty at times, and be made to feel guilty at others. It taught me a lot. I learnt stuff I had never even heard of. I managed to implement some of them with the help of R of course. Towards the end, we had set roles... as we debugged... i became the guy who'd find the problem, and she's fix it. The debugger and the coder.. thats the relationship we had on the field of play... the one off the field, well, not much can stand in the way of friends.


R and I

The course isnt done yet. The exam is yet to come. And so are the grades for our thread library and kernel. So theres still a long way to go... yet, I cant help but say it, there's no way I'd have gotten here without R.

P.S. For more experiences, check out R at Chatterati and V at Rise of the Phoenix.