31–40 of 53 posts
Source available on GitHub: https://github.com/mit-pdos/xv6-public Unless I'm missing something, the entire codebase is just 102 files (including README and such), no subdirectories, and 12,000 lines. What a fantastic tool.
xv6 is an amazing teaching OS - it is very simple to dive into and play around with. A while ago I wanted to explore some filesystem/permissions stuff and use xv6 to play with some concepts (see http://sarahjamielewis.com/posts/file-system-permissions-and... - still lots I want to play around with there when I find some time) - If you are at all interested in OS dev it is a great gateway.
I'm interested, but where would you suggest to start?
The Linux kernel itself is really well documented. Between the docs you can pull, KernelNewbies.org, the IRC channel, and the O'Reilly text "Understanding the Linux Kernel, 3rd ed", you can get up to speed re: conventions and develop a pretty good top-down view.
Then use strace/ltrace excessively on everything to get a bottom-up view. Strace is a great skill to have in general to help identify bugs in live code by attaching to the PID. Way more granular than a standard GDB attach. It's got a learning curve about on par with reading pre-C++11 template error msgs, but after a few months you'll start to recognize patterns, just as in tmpl error msgs, to the point where you can just skim the last few hundred lines strace piped to stdout and you'll know what sort of bug to deal with.
I haven't played with FreeBSD in nearly a decade but I do remember their documentation was second to none, including the IBM Red Books. So if you want to see another approach to a POSIX implementation (obviously Tanenbaum talks about MINIX which is semi-POSIX, so yeah, read that supplementary text), going through the Handbook from an end-user perspective then the mailing lists + source will give you a real interesting view as to why certain engineering decisions were made. I.e., why ipfw was replaced, the gradual progression of standard file systems from UFS all the way up to modern day ZFS, etc. The list offers a rare view behind the curtain exploring engineering decisions that end-users aren't often privy to, and the caliber of conversation is ridiculously high
Earlier quoted context omitted.
> Wouldn't you want to choose a more "clear" language Are you implying that another language would be more clear? Quite the opposite, C doesn't hide anything from you. When you want to understand what the computer is doing you can tell directly from the C code. Unlike other languages where you need to understand what the language is doing first, and only then can you understand the computer. There are time where "hid…
> C doesn't hide anything from you. Yes, it does. C hides cache, SIMD, registers, the stack (no multiple return values for you!), the details of the heap (malloc() either succeeds or fails, and you can't know what it's going to do until you call it), SMP, instruction-level parallelism, and the details of atomicity, all of which are relevant to OS programming. C is a nice language. Don't pretend it's how the hardware…
C is a nice wrapper around assembly. In a few cases, you wish it were a bit better specified to control the actual assembly/ABI binding a bit better. The problem I see is a lack of contract enforcement which makes introducing hard to diagnose bugs really easy. Maybe Rust will fill the gap.
Is there a coursea or other MOOC that uses Xv6?
I took 828 and really enjoyed it. It was one of the best classes I took at MIT. The other OS for that class is JOS, which is the one you build through the labs. It's similarly simple to understand and not that long to build.
I took 828 and really enjoyed it. It was one of the best classes I took at MIT. The other OS for that class is JOS, which is the one you build through the labs. It's similarly simple to understand and not that long to build.
> I took 828 and really enjoyed it. It was one of the best classes I took at MIT. The other OS for that class is JOS, which is the one you build through the labs. It's similarly simple to understand and not that long to build. I'm not sure what I'm supposed to take away from your comment aside from "I went to MIT".
Earlier quoted context omitted.
So the ls and make and all those tools; where do they come from? Are they straight compiles using GNU gcc tools etc? I only ask because I have no idea how much is the kernel compared to everything else; and if it has its own custom compiler or whatever.
No, they are minimal versions written for the OS. Here is ls[0] and cat[1]. You can compile with GCC. [0] http://www.ccs.neu.edu/course/cs3650/unix-xv6/HTML/S/64.html [1] http://www.ccs.neu.edu/course/cs3650/unix-xv6/HTML/S/42.html
As useful as it is, especially outside of i386, QEMU has grown to be a massive program with many dependencies that requires GB of RAM/swap during compilation.
There's also OS161, which is Harvard's version of this. It comes with a very simple MIPS emulator, on top of which the actual operating system is built. It's a lot of fun!
Earlier quoted context omitted.
> Wouldn't you want to choose a more "clear" language Are you implying that another language would be more clear? Quite the opposite, C doesn't hide anything from you. When you want to understand what the computer is doing you can tell directly from the C code. Unlike other languages where you need to understand what the language is doing first, and only then can you understand the computer. There are time where "hid…
> C doesn't hide anything from you. Yes, it does. C hides cache, SIMD, registers, the stack (no multiple return values for you!), the details of the heap (malloc() either succeeds or fails, and you can't know what it's going to do until you call it), SMP, instruction-level parallelism, and the details of atomicity, all of which are relevant to OS programming. C is a nice language. Don't pretend it's how the hardware…