There are two good articles about install Minix : How to Get and Install Minix 2.0.4 and Install Minix on Qemu. There are also a Qemu image to download on the net. However they are all about Minix 2.0.4, the latest of the 2.x series. However as I’m reading the book, I prefer to use the same version the book is using, so I won’t get line number mismatch or something like that. And after I read the changelog of 2.0.4 and found out the change is pretty big, I decide to install it my own, using the version come with my book.

It turns out to be not that hard, just a few points:

First, we could make the install image by

and then start with

or we could start qemu with

and then supply “/dev/fd1″ when the setup script asks for the USR
disk.

Second, as I’m installing it on a virtual machine I want Minix to take all the disk. But don’t know why it won’t take /dev/hd1 and complains /dev/hd1c. And the “parts” program give me two partitions although I made one. I guess this might be a bug in the “parts” program, but
anyway, if I install Minix on the 2nd partition it made, it works for me.

Third, and this is really a touth one. I made the floppy images as in the two articles above, using the dd(1) command. However on the last floppy of SYS.TAZ and USR.TAZ, there is a complain from tar “header checksum error”. I tried both the files on my CDROM and the CD-ROM-2.0 version downloaded from the official Minix website, both got the same problem. (Well the two sources have the same file size and md5 checksum so this is expected). Those two files can be un-tar-ed on my FreeBSD box without error, though. Finially I found “talkd.h” is missing on the installed Minix OS and I typed that file in manually. It looks it’s the only file missed because “make world” works fine after that. And even there are something missed in “USR.TAZ”, my “make world” should have fixed that.

So I decide to put my fresh virtual box online, in case it could save some time for other people reading the book. I didn’t touche anything in it, except set the hostname to “minix.dryice.name”. It’s in Qemu “raw” format, which should be easily used by other virtual machine software. The disk is 300M which should be enough for testing and learning, while the download is about 10M, zipped.

Share This

And today, when I reading the memory management chapter of Minix, I understand part of the reason why MULTICS is so slow: To locate a single address in the memory, it will need to look up 3 tables. And all these 3 tables are paged. That is, in the worst case, there will be 3 page in operation needed to location the address

This is the approache I do things sometime: the design looks perfect, however, overkilled. We are engineers, we need to find the most reasonable solution instead of the most “correct” solution.

Share This

In 3.2.4, it is said that “for a special file, this i-node contains the major device number, and the minor device number”. This is different from what we know for normal files, where the i-node contains file access time, etc.

It is not effecient to hold one i-node structure for both the normal file and the special file, and maybe some other file types. So I’m guessing that there will be different structure for different file type.

I’ll need to keep an eye on this when looking at the code.

Share This

And here’s some of my thought about how I will read and document the code:

The best way I can think of is to use Doxygen and Doxymacs. And I’m learning mind map and FreeMind, I’m thinking using freemind to get the scheleton of the code. One question now is that I don’t know how to point to a freemind node from the doxygen document.

And I think I can use version control systems to manage my update on the using of doxygen. Say the trunk for keeping up with the official code, a document branch for doxygen changes, and a sandbox branch for change it here and there to build and test.

I’m not sure if the license allow me to publish my doxygen and freemind output. Need to check this later, if I can make it, ofcause

Share This

My question is, all these is based on one assumption: that the buffer on the disk controller can only hold the data of one disk block. However, if most of the time we’ll need the block one by one, why won’t we increase the buffer size of the controller? This way we may need only one circle of the disk to read all the data in one track.

I guess this must be a simplification of the book. The hardware designeers must think more about this than me And thinking the disks with 8M or 16M cache on the disk (even not on the controller!). The real world must be more complicated than the book

Share This

On page 52 of the book it is mentioned that the process table that handles process management, memory management, and file management are seperated in different modules with different data structure.

This is the first time I heard about this kind design. And thinking it through, as a microkernel system, or client-server model, this is a nature choice.

This is just a note. I’ll look deeper when I look at the source code.

Share This

• The Minix core only have 59 system calls to be POSIX compitable. I never thought it could be so less…
• Why the best is the best. On page 25 of my paper book, The author took some time to talk where the “.” should appear. This being careful of the detail makes this a book trustworthy.

I’ll start the detail tomorrow, from Chapter 2, process, and on.

Share This

I’ve got a pretty high score for the operating system class when I was in school, however, that’s only the theory. I read the first edition of the Minix book when I was in school, but didn’t finish that before I return it to the library. And I did some RTOS work during my last employee time. That’s quite different from a generic OS.

The road map will be Minix 2 -> Minix 3 -> NetBSD. I begin with Minix 2 because I only have the paper book of Minix2. There’s no Minix3 book selling in China. And finish in NetBSD because it’s quite famous for it’s clean design and code.

As usual, when I start to do something, I join their mail lists. This time it’s the famous news://comp.os.minix.

Don’t know how long will this last, or even if I could finish it, but, well, let’s start.

Share This