Friday, May 21, 2004
Operating System Stress
A mystery was cleared up for me by Luke the other day.
I went to University to do Comp Sci in the mid eighties. Of course, one of the tools a comp sci undergraduate needs is a computer. At York we had a DEC VAX 11/750 for the entire undergraduate population (I was probably one of the last intakes where the norm was a single computer with lots of terminals hanging off it). The operating system of choice was UNIX - BSD 4.2 to be exact.
With my limited experience of microcomputers before colledge, I soon fell in love with the UNIX experience. It's user interface seemd elegence itself especially when compared to the clunkiness of a Commodore PET. Incidentally, by "user interface" I mean command line. GUIs were the future then.
One of the courses I took was "operating system design". In fact it is the course I enjoyed most for the whole time I was there. Operating systems are probably the most complex objects ever designed by humans and it was fantastic to be able to understand how they work. We learned about context switching and semaphores, virtual memory management, IO processing, file systems and many other things. Right at the end we talked about UNIX.
It was a disappointment.
You see we had been taught that a good operating system uses a layered approach. At the bottom layer you have the fundamental stuff which basically allows processes to run and switch the processor to other processes when the current one gets stuck or simply uses up too much time. You also have semaphores at this level which provide the low level process synchronisation. On top of this you put the memory management and scheduler and further layers provide IO and the file system and the user interface.
The UNIX approach turned out to be, well, agricultural. It had a big blob of code called the kernel. When a process used the kernel, the first thing that happened was that the interrupts were turned off and they weren't switched back on again until the kernel code had exited. In the jargon, UNIX has a monolithic kernel. I could not believe that something that seemed so elegant at the user level could be so crude underneath. In fact, at the time, this approach was an advantage. UNIX was designed to run on small minicomputers like the PDP 11. The PDP 11 has a 64Kbyte address space, so "sophisticated" was not an adjective you had the luxury of applying to your software. Its simplicity was also (in my opinion) a contribution to the fact that it ported to a lot of machine architectures. It was easy to port even if you didn't have access to the source code. That might sound strange, but UNIX isn't really an operating system, it's the definition of interface between the big blobby kernel and the user programs. I might write a blog that expands on that on another occasion.
Let's fast forward a few years. Linux is now the most popular variety of Unix like OS's at least on small computers. It's actually a prime example of what I mean about Unix being an interface definition. All the code on the kernel side of the interface was written by Linus Torvalds originally. Much of the code on the user side was contributed by various members of the GNU project. (This is why Richard Stallman insists on GNU/Linux being its proper name. In the context of this blog, all the GNU stuff is in userland - by Linux, I actually do mean the bit that LinusTorvalds wrote). Whatever SCO would have you believe, there is probably no UNIX source code in Linux, but it manages to be Unixy by having the same system calls.
Here's the mystery: one of the advantages of Linux in the educational environment is that you can get the source code. This means that, for an operating system course, you can actually dissect it to see what a real operating system actually does. At least that's what the Linuxheads say. In my course we didn't look at any real code: the principles of virtual memory management are easier to learn with a few good diagrams than 20,000 lines of poorly commented C code.
If you're going to dissect an OS for a comp sci course, Linux is a poor example because fundamentally, it still has the same big blobby agricultural kernel idea as the one I was so disappointed by in 1986. Linux is based on an operating system called Minix or so the legend goes. Minix was designed by a guy called Andrew Tanenbaum as a worked example for a book he wrote about operating system design. It's always been a mystery to me how people seem to revere him and his book which has almost acquired a classic status. After all the Unix architecture is wrong, surely. It's only good for telling you how not to write an operating system.
The link at the bottom of this blog entry is to the story of how Linus wrote Linux from Andrew Tanenbaum's perspective and it shows how I was wrong about Minix. In a fundamental way, Linux was a step backwards from Minix. The kernel side of the interface does not have to be one big blobby piece.
(This blog written on a Apple Powerbook with Mac OS X 3.3 which uses the Mach 3 microkernel (non-blobby), but "enhanced" to reblobify it - so I'm told).
Link
I went to University to do Comp Sci in the mid eighties. Of course, one of the tools a comp sci undergraduate needs is a computer. At York we had a DEC VAX 11/750 for the entire undergraduate population (I was probably one of the last intakes where the norm was a single computer with lots of terminals hanging off it). The operating system of choice was UNIX - BSD 4.2 to be exact.
With my limited experience of microcomputers before colledge, I soon fell in love with the UNIX experience. It's user interface seemd elegence itself especially when compared to the clunkiness of a Commodore PET. Incidentally, by "user interface" I mean command line. GUIs were the future then.
One of the courses I took was "operating system design". In fact it is the course I enjoyed most for the whole time I was there. Operating systems are probably the most complex objects ever designed by humans and it was fantastic to be able to understand how they work. We learned about context switching and semaphores, virtual memory management, IO processing, file systems and many other things. Right at the end we talked about UNIX.
It was a disappointment.
You see we had been taught that a good operating system uses a layered approach. At the bottom layer you have the fundamental stuff which basically allows processes to run and switch the processor to other processes when the current one gets stuck or simply uses up too much time. You also have semaphores at this level which provide the low level process synchronisation. On top of this you put the memory management and scheduler and further layers provide IO and the file system and the user interface.
The UNIX approach turned out to be, well, agricultural. It had a big blob of code called the kernel. When a process used the kernel, the first thing that happened was that the interrupts were turned off and they weren't switched back on again until the kernel code had exited. In the jargon, UNIX has a monolithic kernel. I could not believe that something that seemed so elegant at the user level could be so crude underneath. In fact, at the time, this approach was an advantage. UNIX was designed to run on small minicomputers like the PDP 11. The PDP 11 has a 64Kbyte address space, so "sophisticated" was not an adjective you had the luxury of applying to your software. Its simplicity was also (in my opinion) a contribution to the fact that it ported to a lot of machine architectures. It was easy to port even if you didn't have access to the source code. That might sound strange, but UNIX isn't really an operating system, it's the definition of interface between the big blobby kernel and the user programs. I might write a blog that expands on that on another occasion.
Let's fast forward a few years. Linux is now the most popular variety of Unix like OS's at least on small computers. It's actually a prime example of what I mean about Unix being an interface definition. All the code on the kernel side of the interface was written by Linus Torvalds originally. Much of the code on the user side was contributed by various members of the GNU project. (This is why Richard Stallman insists on GNU/Linux being its proper name. In the context of this blog, all the GNU stuff is in userland - by Linux, I actually do mean the bit that LinusTorvalds wrote). Whatever SCO would have you believe, there is probably no UNIX source code in Linux, but it manages to be Unixy by having the same system calls.
Here's the mystery: one of the advantages of Linux in the educational environment is that you can get the source code. This means that, for an operating system course, you can actually dissect it to see what a real operating system actually does. At least that's what the Linuxheads say. In my course we didn't look at any real code: the principles of virtual memory management are easier to learn with a few good diagrams than 20,000 lines of poorly commented C code.
If you're going to dissect an OS for a comp sci course, Linux is a poor example because fundamentally, it still has the same big blobby agricultural kernel idea as the one I was so disappointed by in 1986. Linux is based on an operating system called Minix or so the legend goes. Minix was designed by a guy called Andrew Tanenbaum as a worked example for a book he wrote about operating system design. It's always been a mystery to me how people seem to revere him and his book which has almost acquired a classic status. After all the Unix architecture is wrong, surely. It's only good for telling you how not to write an operating system.
The link at the bottom of this blog entry is to the story of how Linus wrote Linux from Andrew Tanenbaum's perspective and it shows how I was wrong about Minix. In a fundamental way, Linux was a step backwards from Minix. The kernel side of the interface does not have to be one big blobby piece.
(This blog written on a Apple Powerbook with Mac OS X 3.3 which uses the Mach 3 microkernel (non-blobby), but "enhanced" to reblobify it - so I'm told).
Link
# posted by JeremyP : 9:16 pm
