The Minix Process Table

The complete state of a process is defined by the process' data in memory, plus the information in its process table slot. See picture for details.

Minix Kernel Data Structures

While studing the kernel data structures, it is a pain to go back and keep referring to the source in order to visualize the inter-relationships and references among the various pieces of data. I am currently working on some diagrams that will make it easier to visualize the layout of data in the kernel. I hope to upload these diagrams this weekend.

Have been busy

I have been busy for a few weeks. Work from my day job has picked up and I am short staffed. Too many night phone calls. Too many meetings. No time to do anything worthwhile. I hope to fix the staffing situation at my work place and then get back to Minix after that. It is a real bummer. I was on a roll.

The heart of Minix

The 'save' assembly function in /src/kernel/mpx386.s is really the heart of the Minix OS. Discovering and understanding this function is like finding the holy grail. 'save' does some magical things. It doesn't follow any rules. It lives in its own world :-)

Coding on bare metal

Went through the startup process in the Minix book again. It makes more sense now. The next section explains interrupt processing excellently. This is where we really begin to understand how the illusion of multiple processes is created.

vish is a little closer to looking normal

One of the good engineers I know found out why my shell is not able to deal with commands without absolute path names. The problem was that I was using the wrong flavor of exec. Now that I am using execvp, this issue is resolved. execvp searches for the executable in the directories that are listed in the PATH env variable. Thanks Linu.

Minix Startup

Just slogged through the OS startup process in The Minix Book. Could not understand some things in the first pass. I will have to re-read. In order to understand this section, I had to go back and revise assembler syntax and also how programs are laid out in memory. These topics led me to other related topics and I spent quite some time today reading all kinds of stuff. Ultimately I 'unwound the stack' and came back to The Minix Book but I am still not satisfied. I find the kernel initialization process quite tough to grasp. I have to keep reminding myself that since the system is not yet fully initialized, concepts like files and processes don't even exist. All we have is a processor with registers, memory and kernel data structures. It is getting really steep here. But this is probably the most important part of this book. I have to keep my focus and keep working through it.

Made some improvements to vish

I had forgotten to handle the possibility of no user input i.e. the user just pressing enter at the vish prompt. I took care of that today. I also found an issue that was being caused by not setting a pointer to NULL after freeing it. (The pointer variable was being reused in a loop.)

Finally, I had to make a minor change in order to account for some of the quirks in the behaviour of strtok().

I think vish is a lot more robust now. But it still does not handle cd, pwd, input and output redirection etc. Will get around to it later as I need to spend time studying the Minix kernel source.

vish is alive and kicking butt!

vish works great! Feels good. The data corruption had nothing to do with fork(). It was happening because I was trying to hold on to some data on the stack! I must be getting old. Need to work the pipe facility and possibly wildcards into this new shell.

Also, even though I am passing the environment string array into execve(), it does not seem to use it and is forcing me to supply full path names of commands I want to execute. Will figure out what is going on later. For now, this is a good point to break and move on to later topics in the book (process management etc.)

Writing a new shell

So I started writing my own shell called 'vish'. Lots of issues. The 'execve' system call does not seem to work consistently. I tried to track down the problem and what I found is this: I have a pointer to an array of strings which represent the command arguments that the user types in. I am using strtok to parse user input and build this structure. But as soon as I call fork(), this data structure is getting corrupted in both the parent and child processes. This just does not make any sense. Will get back and take a closer look.

Process Scheduling

Just went through various algorithms for process scheduling. The one that really interests me is Lottery Scheduling. Can't wait to get into how exactly scheduling is implemented in Minix.

On an unrelated note, I am about to start writing my own shell. Think I will call it vish! I guess this shell could produce error messages that start with "You vish".

Programming with semaphores

Just studied the different examples on using semaphores in the Tanenbaum book. Consider a non-trivial one like the solution given for the Dining Philosopher's problem. Sitting and staring at the algorithm for hours helps you understand it but not in such a way that you can recall it at a later time. Nor is it easy to find flaws in these algorithms just by inspection. I think that the only way to get good at using semaphores intelligently is to spend lots of time programming and debugging with them. If you don't use it you lose it.

Race conditions are painful because of their unpredictability.

Semaphores

But then, race conditions can happen in Petersen's approach too and even in the sleep/wake-up approach suggested in the producer-consumer (which share a read-write buffer) problem. That is where Djikstra's semaphores come in. Semaphores basically keep track of pending wake-up calls and account for each of them. Semaphore 'ups/downs' are analogous to 'wake-ups/sleeps' in the producer-consumer problem.

Cooperating processes

I am currently reading about different approaches to ensure protection of shared resources in a system that supports multiples processes: the concept of mutual exclusion. Petersen's approach is very simple and elegant. A variant of this relies on the hardware by using the TSL hardware instruction. Fun stuff.

I also wrote and tested a C program that tests most of the system calls on Ubuntu Linux 9.0.4. It was a great experience. The actual exercise is to test this on Minix but I don't yet have a machine on which I can install and play with Minix.

Hardware Interrupts

Back to the basics! I want to plug holes in my knowledge so I am currently studying Tanenbaum's 'Operating Systems: Design and Implementation' also known as The Minix Book.

The topic is 'hardware interrupts'. This concept is a little difficult to understand for an application programmer who takes many things about the hardware and software for granted. Tanenbaum explains it well but I had to read it multiple times to grasp it. One reason is that the author does not provide a diagram to illustrate what happens when a hardware interrupt occurs. Maybe I will create one and post it here!

Comments welcome.