Hacker News Reader

Comment by antics | Hacker News Reader

Linux is a monolithic kernel designed to operate on all sorts of hardware, in all sorts of environments. So it's complicated. In some cases it can be beneficial to see a simpler implementation, which is a task I think Minix [http://www.minix3.org/] is well suited for. Edit: Why? It's smaller, it's a micro-kernel, and there is a lot of documentation, both about the source, and about the theory of the source? And why is that, you ask?

For those who are just starting, the author (Tanenbaum) also wrote a book called Operating Systems: Design and Implementation, which is a great resource for learning the ins and outs of OSs. But it is a necessity to know C beforehand, and you should have a reasonable understanding of basic CS first, also.

Edit 2: Oh, also, Minix is in a lot of ways responsible for the genesis of Linux, for those who didn't know. [http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5...]

View on HN

I disagree: Don't wait to have an understanding of C or CS, just dive in.

Find something interesting and figure out how it works. The best learning happens when you get in over your head. Once you get sufficiently lost, go back and learn some C. You'll appreciate it more and have a context to apply what you learned.

I think there's a lot in what you say. It's more like the approach kids have to learning stuff when left to their own devices

Not exactly the same thing.

At the end you tend to re-invent the wheel if you learn that way. Learning about the existing wheels will save much time and correct a lot of errors that you might never even see when working that way.

And kids knowledge is generally supplemented by adults to complete the picture and sometimes we have to lie to introduce them to some concepts.

I disagree: That approach might work if either a) you are a genius or b) the problem is simple so background knowledge wont make a difference c) or you have loads of time to go back from all dead ends you'll get yourself into.

The kernel code is complicated. Learning C and some CS concepts before diving in will save you a lot of time and headaches. What you could do is learning C and CS while trying to understand some bits and bytes of the kernel, but for that I guess you would need someone else to guide you

I tried that when I started in the fall of '09 and it failed miserably. When I came back this summer after intensively studying C and computer systems in general, things went a LOT smoother.

If you want to learn that way, you have to be incredibly tenacious. Some people are, some people aren't, but I think my time was better served by learning all the dependencies and then breezing through it when I was in the right place. I mean, you could learn Organic Chemistry and just backtrack to learn Chemistry where applicable, but that's a very hard way of doing it.

I tried that when I started in the fall of '09 and it failed miserably. When I came back this summer after intensively studying C and computer systems in general, things went a LOT smoother.

I'm not doubting your story, but it's not a hard-and-fast rule. Con Kolivas, who has written some interesting/thought-provoking schedulers for the Linux kernel (and stirred up some politics along the way) had never touched C before jumping in. (http://apcmag.com/interview_with_con_kolivas_part_1_computin...)

I completely agree. There certainly are bright people out there. What I'm saying is, I consider myself to be about average intelligence, and so my example is probably more typical, although I do concede there are probably outliers.

I found the Minix source code to be quite terrible to follow through. If you want a simple implementation, I'd suggest looking at the xv6 source code. It's far more comprehensible, cleaner, and better architected, in my opinion. For the code in question, look through sysfile.c in the source code.

http://pdos.csail.mit.edu/6.828/xv6/

For a real-world example, I second the recommendation of BSD, combined with the book below.

linux was initially designed for just x86. that's the real reason it's complicated in this case: each architecture defines it's own system call table and dispatch, for example, instead of having a common one amongst architectures.

other kernels (like NetBSD) where designed with being portable across architectures in mind and so have much cleaner code paths (typically just one system call table and the bare minimum arch specific code to link it all together).

minix is okay but it's not really going to give you a grip on a real work kernel. "design and implementation of 4.4BSD-lite" is a really good book for this: most BSDs are very similar to this design still in a lot of ways, and many of the ideas described (e.g., VFS) are also used in linux.

First, actually Linux and Minix (and BSD as far as I know) are both POSIX compliant, so the syscall table will be more or less the same. The thing that changes between architecture is the instruction set, which is different, no matter what. That's actually the point of POSIX compliance: to define *nix-like systems in a way that is predictable.

Second, actually the more architectures you are compatible with, the more code is involved, and it tends to be more, not less, complicated. This is especially the case because all OSs have some assembly in them, and that assembly DOES change per your architecture.

Third, Minix is a "working" kernel. The main difference between Minix and BSD/Linux/whatever is that it is a microkernel, which is easily the best to learn on, on account of things like the permissions structure being MUCH simpler (arguably one of the most difficult things to grasp), but not the best in terms of (for example) security.

1. the system call table of linux and minix are very different. posix specifies the minimum interface (and i don't think it specifies what is and what is not a system call). linux has a lot more system calls than minix. the system call table itself changes between architectures under linux since...

2. linux duplicates the system call dispatch table for each architecture. check it out:

http://lxr.linux.no/linux+v2.6.35/arch/x86/ia32/ia32entry.S#...

http://lxr.linux.no/linux+v2.6.35/arch/avr32/kernel/syscall_...

whereas NetBSD has no such duplication. in fact, one complaint about the linux kernel is that it has too much per-architecture code.

3. who uses minix? the linux kernel is actually not too bad. ctags is your friend. i learnt on linux+netbsd, it's not really as bad as people make out.

Tanenbaum's book and Minix was what we used for our undergrad operating systems class ca. 1990. To put it in perspective, Minix was a compact but fairly usable unix-like OS that booted and ran from a 5.25" floppy disk.

The newer versions of the text features a more full featured microkernal Minix

Reply on news.ycombinator.com